Over at Scary Ideas” there is a brilliant cartoon about information technology projects and how they go wrong. The cartoon is funny but also a clear and concise commentary of project management. In ten separate panels, the artist describes how various people involved in an IT project can misunderstand the deliverables. What makes this cartoon brilliant is that it can be used to explain how to avoid such pitfalls.
In frame 1, we see “how the customer explained it.” A tree with a swing in it, but the swing inexplicably has three seats. In my experience it is common that customers do not know their own need, especially in relation to information technology. They are able express that they have a need, but not necessarily what the need is. That is, of course, why they hire consultants. But projects go wrong for many reasons, and the customer is not entirely to blame. This cartoon analogy rings true for me. Customers typically express their need in a rough way but tend to try to specify the solution as well, and they usually get that part wrong. In this case the customer knows they need a swing, but thinks the solution involves lots of seats on the swing. They don’t understand that the extra seats don’t solve their problem, and probably prevent it from working at all.
In frame 2, we see “how the project leader understood it.” The project leader figured out the swing should have just one seat but didn’t really understand the “swing” concept and has the swing attached to the tree in a way that would preclude “swinging.” This is worse in some ways than customer’s explanation. The customer at least captured their need. Hear the project leader “doesn’t get it” but manages to capture some of the characteristics the customer described. Project leaders make mistakes like this because they are responsible to the “project” and responsible for delegating work to team members. The focus is on the parts, not the whole.
Compare that to the perspective of the business consultant in frame 5. Business consultants interface with the customer directly but are motivated to make a sale. They have to communicate to the customer both that the customer’s need is understood and that the solution offered will be the best available. Sales people and consultants tend to over promise, setting up everyone else to under deliver. Over promising also sets up the premise for frame 8, where the customer is over billed. Customers will always feel over billed if you promise the moon and don’t deliver.
In frame 3 we see the perspective of the analyst. The analyst interfaces with the project leader. He “gets it” put takes an engineering approach to the problem. He works within the constraints of the problem that the project leader has proposed and comes up with a solution. In this case the swing will swing, but it is not a straight forward solution. The analyst is not solving the customer’s problem, the analyst is solving the problem invented and interpreted by someone who just didn’t get it. Worse yet, in frame 4 we see how the programmer delivers what the analyst asks for. All the parts the analyst described are there, but when put together they just don’t do the right thing. If you made up a checklist for the deliverables, the programmer has indeed done his job… all parts accounted for. But it doesn’t meet the customers need.
In frame 4 we a source heavily linked with all the other frames. The documentation describes a mere shadow of the customer’s need. If the documentation were written first, and resembled the business consultant’s view, then the analyst might have been able to pass on something better to the programmer. The lack of documentation probably explains frame 7 as well. Operations often does not install what is needed to meet the customer’s need. Operations is so far divorced from the customer that they don’t know what the deliverable is supposed to do. They don’t know what the parts are for or what is important and what is not.
In frame 9 we see what ultimately happens after an IT project goes wrong. Everyone stops taking the customers calls, and refers them to support. Support, has to figure out how to make the best of a bad situation and deliver something, anything, of value to the customer. Support people are emergency workers. They conduct triage on the deliverables and decide what is worth saving and what is a write-off. In frame 9, we the tree has been cut down. There is no swing, but there is a nice stump to sit on.
In frame 10 we see what ultimately would have suited the customer’s needs. A nice tire swing. Not what the customer described exactly, but pretty close. Not as elaborate as what the business consultant recommended, but roughly the same idea. It does the same thing the analyst designed, but is much less complicated.
There are some lessons to be learned here. Of all the view expressed, the business consultant’s was the closest to the customer’s need. But typically business consultants are involved at the beginning of the process and are removed from the project later on. Some methodologies require that the customer be involved at all stages. I’m not sure that is realistic in many cases. However, it is clear that IT projects need customer advocates. I believe that business consultants, as expensive as they are, should be those advocates. Business consultants should not be sales-people but expert generalists with development and management experience. They should not be the project manager but should work directly with the customer and the project leader. The role of the business consultant should be to create the documentation, understand the big picture and the details, and assist the project leader.
I think this poster assumes the project leader is a technical team-leader or manager and not a professional project manager. That is a fairly good assumption in most cases. The technical project leader’s job is to make sure that the right resources are allocated to the project, that the job is getting done. The leadership role involves keeping things on track; its a difficult balancing act. While the project leader needs to understand the big picture, we need to be realistic and assume he will not be given the opportunity to reflect on big picture aspects. The team leader is too busy worrying about details. That is why the business consultant/advocate needs to work with this type of leader.
Most development methodologies now emphasize artifact creation at all stages by different participants in the project. I think if the the business consultant’s job is act as the “big picture” thinker and to interface with both the project leader and customer, then it is the business consultants job to ensure that the right documentation has been created. At least three levels of documentation need to exist: A high-level documentation that the customer can understand that explains what problem is being solved; A technical specification that describes the various parts that must be created and how they fit together to create the solution. This would include step-by-step user documentation for each component of the system; and low-level documentation create by and for the analyst and programmers. The low-level documentation is meant so that the system can be installed by operations and so that it can be maintained. In the end support and operations will need all of this documentation and without it they cannot be expected to deliver what the everyone else built and expected.
I’m not optimistic that much can be done about the customer being over-billed. IT projects are expensive, however if we assume they will be expensive that gives us a constraint to work within and we can concentrate on building value within that constraint.
You can get the cartoon printed on a t-shirt at cafepress.com.
