Following on from my previous article titled “How to pick a good Consultant/Integrator to Partner with?“, I believe that this project cartoon describes the challenges of communicating and executing customer requirements, and is very relevant to what I see a lot of in the IT & T industry.
Then I found a funny explanation of it written by Phil Hord. Even though it’s written from a software developer’s point of view, it can sadly be related to all other areas of the industry.
- How the customer explained it. The customer usually has no clue what he really needs. He thinks he does, but he can also think of extra features he’ll never use. He’ll demand them up front, because he’s afraid he won’t get them added later.
- How the project leader understood it. The guy in charge of the project usually gets some critical detail wrong. It’s often wrong in a way that makes it useless, but it snowballs from there into comedy.
- How the analyst designed it. The analyst has to decide how to fix the leader’s misunderstanding of the project. A common “fix” is to break something else to work with our existing design.
- How the programmer wrote it. Programmers are notorious for not understanding the essential features of a project. They implement things quite literally, sometimes.
- How the business consultant described it. Marketing folks are the engineers’ nightmares. They sell the customer on the glowing, cushy features of this project, paying no attention to the truth or practicality of the situation.
- How the project was documented. Documentation is usually an afterthought, or an I-thought. As in, I thought someone else was writing it.
- What operations installed. Sometimes we spend months getting certain features to work, only to find out later that those features were never installed at the customer site because A) they didn’t work, B) the installer didn’t understand how it worked, or C) someone was afraid the fixes were no good.
- How the customer was billed. Yeah, software is expensive. We get to charge for all our clueless machinations.
- How it was supported. “Is this feature causing the customer to call tech support? Perhaps we should remove it.” Eventually, you end up with the basic stub of the project.
- What the customer really needed. It would be so much easier if we could ever get to this simple starting point. But we never do…