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…
Jeremy Saunders
Technical Architect | DevOps Evangelist | Software Developer | Microsoft, NVIDIA, Citrix and Desktop Virtualisation (VDI) Specialist/Expert | Rapper | Improvisor | Comedian | Property Investor | Kayaking enthusiast at J House Consulting
Jeremy Saunders is the Problem Terminator. He is a highly respected IT Professional with over 35 years’ experience in the industry. Using his exceptional design and problem solving skills with precise methodologies applied at both technical and business levels he is always focused on achieving the best business outcomes. He worked as an independent consultant until September 2017, when he took up a full time role at BHP, one of the largest and most innovative global mining companies. With a diverse skill set, high ethical standards, and attention to detail, coupled with a friendly nature and great sense of humour, Jeremy aligns to industry and vendor best practices, which puts him amongst the leaders of his field. He is intensely passionate about solving technology problems for his organisation, their customers and the tech community, to improve the user experience, reliability and operational support. Views and IP shared on this site belong to Jeremy.
Latest posts by Jeremy Saunders (see all)
- Best Practice for the Active Setup StubPath value - September 25, 2023
- User Profile Migration Strategy and PowerShell Script with a User Interface - August 28, 2023
- Cold Starting and/or Hydrating Your Applications To Improve Their Startup Times - June 27, 2023