I am a professional services practice manager with current accreditations in project, programme, and portfolio management. I have experience of delivering software and consulting services to international ports, climate change sector, transportation, and the public sector in New Zealand and the United States. Several of those deliveries have won international accolades.
I have a Bachelors degree in computing and am currently pursuing an Executive MBA, am a member of the Project Management Institute, and a committee member of the Prince2 User Group. I share my professional views with my peers through my blog Project Management in Practice, and twitter.
I went to the New Zealand PRINCE2 User Group Wellington Chapter meeting on Tuesday night. As usual the calibre of speakers were excellent. Conrad McDonnell and Barry Calvert spoke on various aspects of estimation. It was quite interesting perspective, one from an IT/vendor angle and another a construction angle.
Importance of a shared vision is not something that I had previously connected to a good estimate. Conrad was quite persuasive on his argument on the need to understand the vision as a pre-requisite in this respect. It is amazing how many projects I have worked on that has started with not all stakeholders having clarity on what what success looks like. Here I do not mean success delivering to a set of agreed deliverables, but something that would advance a measurable business outcome. I can see his point of view. He gave the example of the NASA programme to land on the moon and the vision that John F. Kennedy outlined in his speech.
He talked about the vision in the context of a progressive estimate with increasing level of certainty. The key to any good vision is to not assume it is understood by everyone. It must be communicated with a feedback loop. Before the programme or project begins, high level planning must occur. The key to estimation at this stage is to understand your levels of uncertainty and recording your risks. It is key to remember there will always be different levels of certainty at all stages in your project or programme. In an IT context, you may have near certainty about cost of hardware, but little clarity on required design effort. As you execute, you must continually plan, execute and re-plan. Expect to take a few detours on your journey. This is where clarity of vision will help.
Barry talked from a construction point of view and had an analogy of a pancake. It only has four ingredients – flour, eggs, baking powder and milk. Flour is the one that determines the size – what is required, by whom, when – the basic facts. That sets your base criteria for estimate. Eggs are what sets your environmental conditions and is complementary to your flour – what environment is it being delivered, the intended use, slope of the land, other influencers. Baking powder is what gives it the fluff – the nice to haves – types of finishing, flooring, fittings etc. Milk is what gives it the consistency – this is your repeatable methodology and constant refinement of it. Even though he gave the example from a different industry, I like the principle of it. I have a feeling I will re-use it.
One thing that was clear from both speakers was the folly of trying to go back to the customer with a number too early in the piece. Whatever you do, customers forever remember the first number or date.
There is nothing called a perfect estimate. You can only ever get reasonably good at it.
Good estimates must be based on a good understanding of the scope of the project. If the scope is only poorly defined (which sometimes is the case at the beginning of many projects), at best the estimate can only be poor.
Good estimates also need to communicate their degree of "goodness". Ranges are better than single point estimates.
Very interesting. Thank you for sharing. I totally agree with Kenneth and Harlan, particularly with regulatory compliance projects. The government authorities have the tendency to "adjust" requirements whenever they have difficulties in delivering their solution interface..