Project Management(PM)
How long should it take?
Observations on the practice of estimation
I had heard this story long time back. There was this gentleman visiting a historical fort situated in a small village. He was walking his way to the fort but unaware of how far the place was. On the way, he saw an old man sitting on the steps of his house soaking the morning sun and asked him “Baba (loose translation: the revered), how long will it take to reach the fort?” The old man remained silent. Assuming the old man to be hard of hearing, the visitor continued his walk. In about two minutes, the old man called him back and told that it might take him forty minutes. Looking at the nonplussed and almost angry expression on the visitor’s face, the old man added “Son, unless I know your pace, how would I be sure of the time you would take?”
I wish the many of us in the project management community had the same patience and wisdom which the old man had in this story, when it comes to estimating and scheduling.
Through this blog I wanted to bring out some prevalent mistakes in estimation and scheduling.
Fill It, Shut It, Forget It
Long before Hrithik Roshan[1] became their brand ambassador and set hearts “Dhak, Dhak, Go”, Hero Honda used to run an advertising campaign – “Fill it, shut it, forget it”. They were referring to the fuel economy of their bike which was claimed as 80 kilometres per litre. That’s why the line “Fill it …”
This popular ad-line popped up in my mind from nowhere, when a close colleague remarked that his project just goes on and on and on. I began to wonder if the Hero Honda tag line “Fill it …” applied to project management too. I see more people looking at project management as a template filling game. The biggest and most talked about template we fill up is the risk management template. Fill it, save and close it and forget it seems to the practice of risk management.
My observation has been that using standard checklist people do prepare a list of risk or a risk register as described in PMBOK. But the question is, do we move beyond risk identification and manage risks at all? So in-spite of all the great intent with which register and plans are prepared, projects continue to fail. In my view this is perhaps due to two problems
Delivering IT Projects from a Business Perspective
The maturity of business organizations when it comes to management of IT projects is an area of concern for many CIOs. CIOs lack the visibility they need into project performance, and do not know the magnitude of project delays or the reasons for these delays. Most IT projects fail or are abandoned half-way not due to technical reasons, but largely because of management issues which start from the project selection process itself. There is a need for all to understand that management of IT projects as a service provider (an IT consulting and services company) is very different from managing an IT project as a business organization.
One of the key differences is the approach towards management of IT projects. While the user organization focuses more on the project’s outcome, the service provider’s focus is on project delivery to specifications. The distinction between these two from a project management perspective is not clear, nor is it clarified by industry associations or proponents of project management.
There is a need to look at the entire project lifecycle from a business perspective for effective management of IT projects. Aligning the project to business objectives and defining the project’s success criteria early in the lifecycle is a critical aspect. You should look at the success criteria beyond just the efficiency metrics of being on time and within budget. In fact, these are success criteria for the consulting, vendor and contractor community. The user organization should focus more on the business benefits, and not on efficiency of project execution. We are not suggesting that efficiency metrics be ignored, but that they are the responsibility of the contractor (or consultant), and that their impact on the business needs to be measured and controlled.
There is a clear need to distinguish between the various approaches adopted by business organizations or user organizations of IT when it comes to management of IT projects. Moving to a program management process approach could perhaps assist the CIOs and IT managers to appreciate this difference and improve success. Given that most projects have a business case, once the implementation is done, it is important to check whether you have achieved the business objectives. This approach is generally not followed by Indian organizations, so CIOs need to focus on this.
IT project management has moved from being a tactical discipline, and now involves the integrated discipline of program and portfolio management. There is a need to make the IT leaders, the CIOs, aware about this. The use of the traditional development lifecycles (such as SDLC) approach to the management of IT projects needs to change, at least for the user organization.
