I thought this issue was resolved years ago, but apparently not….
Recently, a fellow consultant mentioned to me a project he was called in to fix. It was the usual—did not work right, never worked right, poor workmanship, client was not happy. He was also told it could not be resolved by the integrator (design-build). So, the client looked to an outside source instead.
The consultant did mention the name of the integrator (which I am withholding), and he said one of the issues was the control system not functioning properly. However, the client did not have the uncompiled code that would enable him to make the necessary adjustments to the program (rather than starting all over).
Coincidentally, a longtime friend and associate had just started working at the integrator. Immediately, I volunteered to try to help. I would reach out to my friend, see what he knew and see if he could help get the code. I didn’t feel bad about reaching out, because my friend always calls me for help—sometimes design, sometimes pricing, sometimes for a second opinion—and I always help him out (mostly just because I can). I thought it would be no issue. As you’ll see, I was so wrong!
Anyway, as I said, I figured he could help…that it was just a misunderstanding I definitely had some questions, though. For example, why was the system not being serviced? After all, the system was only nine months old! I thought to myself, “Isn’t a one-year parts-and-labor warranty standard on installations?” I have always given a one-year warranty on parts and labor on projects I have sold and installed.
My friend and I met for lunch to discuss the situation. It had been a while, and I got the dirt on why he had left where he was working and gone to this company. In addition, he was looking to get some leads on possible upcoming projects on which he might be able to bid. And you know what? Before I knew it, I was driving back to work—and we never discussed the issue at hand!
So, I gave him a call a few days later. My friend was not familiar with the job, but he said he would ask about it and get back to me, which he did. He verified that the project was done about nine months ago, but he claimed no one knew about any difficulties with the project. The integrator was paid in full and all was well, he told me! The information source was the account manager who’d sold the job, and who’d been working there for many years. But the thing is, I knew with absolute certainty (from my consultant friend on site) that the system was not working!
And here’s another wrinkle: The integrator only gives a 90-day warranty. After that, you have to pay—or you have to purchase an extended warranty to complete the first year (and/or add more years). I was flabbergasted! Ninety days?! Are you kidding me?!
However, my friend said to me that, nowadays, that is common. Frankly, there is still a race to the bottom in our industry, and, my friend said, because they are lucky to get 18 points on a project, they just can’t afford more than that.
OK, so the picture was becoming clearer, but I still had some questions. My friend on site had told me the integrator was unresponsive to service calls, but he might not have been given all the information. It sounded more like the integrator wanted to charge the client an arm and a leg to come back, because the project was out of warranty!
The next call I made to my integrator friend, I finally had to ask the real question: Did they/would they provide the original programming code to the client? The answer? A big, fat no! And why should they? It’s the company’s intellectual property. So, if the client wants some work done, it has to call that integrator. And why not? The integrator did the original job, and the client is its customer now! If they chose not to come back, they’d just have to pay for the system again. Ouch! I couldn’t believe what I was hearing. But my friend just fell back on, “We don’t make enough money to do that,” when I asked him about broader, longer-lasting coverage.
Of course, I disputed that point of view to no end. First, no matter how much—or how little—the integrator makes, the client is paying for that firm to write the code and install it in its space. Why should the client have to pay for it again? “Intellectual property,” my friend replied. He really believed that the client was not entitled to use the programming code as it saw fit…that it should be locked up—unless the client arranged in advance for transparency and paid for it.
Ultimately, he said, this was someone else’s job and he could not help. Alternatively, he suggested having the client get in touch and request a service call. Although that conversation ended my involvement—I told my consultant friend I could not help to obtain the code—it really irked me. I mean, how many people know to ask upfront to have the programming code included in the required close-out documentation? I would say almost none!
I called around to find out what others are doing, and I will follow up with a future article about this. In fact, I want to involve all the integrators reading this, so I can find out what you’re doing. Please answer this two-part question: Do you provide the uncompiled programming code at project close-out? Why or why not? I will select a few of the responses and highlight them.
Contest time! All integrators who respond will be entered into a drawing. The lucky winner will receive a can of Virginia Diner Peanuts! Contact me at dkleeger@testa.com.