Recently I happened to read a funny but insightful anecdote about routine work of a project manager in the IT sphere.
The project was to develop a 3D model of an elephant.
PM says “We will use a programming approach to implement a modular solution.”
So, the programmer takes a hippopotamus and adds a trunk and ears to it in order to make the hippo look like an elephant.
The client is not happy, “ Why is the trunk in the a….. (you know it) on the back ? Why do the ears fall on the eyes making it blindfolded ?”
PM agrees and orders the programmer to correct it. The programmer removes the trunk from the back and changes ears right to left.
Client complains again, “You have removed the trunk from the back together with the tail. Please fix the tail on the back. And one more problem. After your redesign of the ears, the elephant hears only from 8 am to 1o in the morning. The programmer insists the details were not given in the specifications.
Anyway, the PM makes the programmer to do it once more. .
Programmer makes the changes.
Now, the client is satisfied about the elephant but he has a second thought, “Now everything is ok. But I think it would have been better if you had taken a giraffe instead of a hippopotamus. Anyway, we can think about it in our next version. And .. can’t you add a pouch on the stomach and remove the trunk. So it will look like a kangaroo. I think it would be great.
Programmer is a bit cross and says, “ It was not in the specifications. I will not do it.”
PM does not want to lose the client, so he asks Programmer, “How long will it take you to do it ?” He answers, “two days”.
PM speaks to the client, “We can make a kangaroo from an elephant in 4 days and for additional 1000$.
The client says, “OK. Is it possible to add horns too?”
The story continues.
If you are an experienced project manager, I think, you have already got the bottom line. It is possible to continue it without an end. Though it is not very real, reality in project management is not so far from it… !
According reliable statistics, IT projects are the most difficult to control though risks are usually known from the beginning. Most of the bottlenecks are described in books and articles about project management. But knowledge helps to prevent and solve bottlenecks only partly because every project manager learns most lessons from their own mistakes.
My experience in project management comes mainly from IT projects. I have involved in managing software development and system integration projects. Most bottlenecks, that I had to deal with were in communication… !
You may start your marriage without listening to your partner and talking a little. In marriage, to talk a lot may ruin all the prospects. You might as well start the journey half blind. You will find the way anyhow as it comes. The truth is that we never start a family with so much of destination in mind.
Can we apply the same as project managers ?
I need to confess here. I am not very satisfied as a project manager. I am still trying to make myself better. You may not believe the extent to which projects were delayed and under-delivered due to mere lack of proper communication with my clients. Specially during the initial stages of projects, if there is not properly planned object oriented detailed communication with the clients, projects will suffer enormously. My dissatisfaction and constant desire to improve has helped me develop a precisely detailed, comprehensively formulated protocol for communication strategy.
There is one particular project that I would relate here to highlight how poor communication affected a project I managed. The project was to automate the workflow for a pension administration company that managed activity of several private pension funds. Our team included several programmers, their supervisor , a system analyst, a business analyst and a project manager (me). The team I worked with had already delivered projects of similar nature before. So, we were a bit too overconfident about our experience.
The problems started from the very beginning because heads of funds had their own vision about the expected software. They could not confirm their requirements and the negotiation took too much time and were not very successful.
Finally specifications were completed after much effort. But it contained a lot of “water” and poor details. Everyone continued to believe that the specifications were just a document and what mattered really was the results.
Now, with experience, I can identify this situation as a sign of a bottleneck. But that time I was not able to do it. So we all continued to think that everything was OK and during the project we would confirm requirements.
During the project customer changed the requirements thousand times and it was one more sign that indicated the presence of a bottleneck. The situation was getting serious. Programmers complained that they could not work in these circumstances. One programmer who played a very important role in developing left the project and nobody could replace him. So we realized that this module we could not complete without help and after long discussions decided to hire a subcontractor. Finally, the project was delayed and brought no returns as expected.
Many project managers tend to leave doomed projects at the first signs of a failure before others in the team realize it. No one wants failed project to tarnish their portfolio.
My bitter experience in the said project made me understand how important it is to identify a bottleneck well in advance and start to overcome it before the situation will be critical. Effective communication at the beginning of the project will ensure that the project will not be a failure.
If you have tools to estimate risks and mechanisms to overcome bottlenecks, the project can be saved and successfully completed.
Most project managers dealing with software development projects have major challenges in gathering relevant information and formulating requirements. Often the situation is such that the client can’t precisely formulate the requirements in enough practical details without dedication and commitment of the project manager. As a result, either most critical information is lacking or irrelevant, non-specific and incorrect information is available.
Project manager’s hands on experience counts. If project manager is experienced enough, he (she) is poised to understand the importance of proper communication with the client and the necessity to discuss all relevant details without leaving room for misunderstanding and potential frustrations. It is imperative that the project manager has a protocol for communication with the client. A properly developed protocol will help the PM delineate functional requirements of the client. Further, systematic communication will help the client see beyond his limited span at times and realize full potential.
I firmly hold that the project manager has an additional duty of educating his client. This education will help the client see the practical limits of the project as it is most often the case. In certain situations, the client is also made to realize better and wider perspectives than he originally thought. It is not rare to see clients who change their whole outlook towards project outputs after proper deliberation.
Project manager has to reason with the client and reason against him too. He needs to see beyond the limits of the project. He should try to get a full picture of client’s business and see how his project fits into that bigger picture. Unfortunately, you will see project managers making unnecessarily complicated long drawn projects full of too many functions for which their clients are burdened with heavy costs.
Waiting is not alway bad. Wait till your client becomes enlightened. Communicate well. Over communication will do no harm. Never have an opinion until the last moment. Educate the client. Let the educated and enlightened client paint it in his color. You need to follow.
[Source]
No comments:
Post a Comment