The picture below should be put into a frame and put onto the desk of everyone in the IT industry.
By day, I am a consultant, so I have quite a few stories that relate to this picture.
Obviously the picture shows that, at every step in a project there are misunderstandings. In most instances, this is not intentionally, but simply a result of people not understanding where the other party is coming from and heading to.
Making sure that information is conveyed precisely requires a lot of effort. Unfortunally the time it takes to undergo this conveying process is left out of the project, either because the involved parties don’t think its nessecary or because it would mean less profit for one or more parties.
These misunderstandings are a cause of aggrevation and frustration for everyone involved. Everyone in the chain must fix or redo a portion of their work in order to satisfy the end-customer.
An example of a simple project will demonstrate this.
A customer wants a certain service, so he calls Acme up and asks for a meeting. A sales-rep goes to meet with the customer, trying to understand the customer’s needs and taking notes as best as he/she can. Unless the sales-rep makes an extra effort to ask questions that the customer might not have thought of and questions that will really nail down what it is that the customer wants, this is the first step that might go wrong, leading to erroneous data to begin with.
After the meeting, this sales-rep goes back to Acme’s technical team and asks how the problem he/she has described and understood can be rectified and what the solution might be.
This will be the next step where things can go wrong. Assuming that the description of the problem is correct (which is just as doubtful), the technical team might want to push a solution down the throat of the customer because it makes the most technical sense but not nessecarily the most business sense (for the customer).
Assuming the customer understands the implications of the solution and signs off on it, the people implementing the solution might have gotten a written description on what should be done and how. Unless this document is very specific, some assumptions on the part of the author might not be apparent to the implementer and hence not being carried out.
If the delivered solution does not fullfill the customers real needs, the customer will (rightfully or not) complain to either the Acme support people or the original Acme sales-rep/account-manager.
This person will in turn most likely accuse and blame the technical team for not coming up with the right solution.
And so the blame-ball rolls further and further down a waste-slope. Now imagine a larger project where even more parties and departments would be involved.
If this was an isolated case, then it wouldn’t be a huge problem, but unfortunally I see this very often. Even though the company I currently work for, has a focus on this, it still happens way to often.
Instead, if attention and more importantly time will be allocated to avoid this and improve communication, I am very confident that future projects would end up costing everyone less money and frustration.
In the end, this would be good for all parties as trust would be established and more projects would be able to get “cleared”.
So save the image and put it as your background. You will thank me in the end!