Bob Hughes is an editor and co-author, who handles project management for IT projects in the telecommunications, energy and local government sectors. He is an academic at the University of Brighton where he gained a PhD in software measurement.
How, over time, do your bosses (and/or clients) rate you as a project leader? What influences that judgement? A big influence will be the regularity with which your team delivers on time. High quality software is great, but high quality software delivered when it is needed is much better. A history of late delivery will do you no good at all.
So, the next question is how do you make sure that your team completes on time? In the last two posts we looked at what we might rather sternly call project discipline, but perhaps the biggest cause of late delivery is getting the estimate of time and effort needed wrong in the first place. You can be a great project leader with a great team, but if the original estimate is wrong, you could be basically stuffed.
I have heard a project management guru argue that even if you do not understand a technical area, you can always tell when someone is lying about it. But when I was a programmer, it sometimes took me longer to do a task than I originally told my boss. I really believed my estimate was correct at the time. I was not deliberately lying.
A commonsense approach to estimating
If I had been asked to explain how I had arrived at my estimate at the time, however, I would have muttered something about experience. This stopped serious discussion of my estimate. As we show in our book, Product Quality: The Project Leader’s Key Concern), some commonsense approaches to estimating allows the developers and managers to have a proper discussion of estimates.
When we think about estimate effort, there are actually three different things we need to consider. There is question of how big the job is that needs to be done. Then there is the matter of what resources – and here we are talking mainly about developers – we have and how productive they are. Finally, there are things that could go wrong; these are the risks. Making allowance for risk is crucial, but this would need a post dedicated to it. The key point here is that this needs to be done separately to the process of establishing the normally expected effort.
Approach with analogy
The most common estimating approach is analogy, which means you look for a previous task similar to the current one. The actual effort for the past project becomes the basis for the estimate for the new project. Some adjustments can take account of differences between the two projects. For example, the previous project may have been undertaken by some top notch coders who in the intervening time may have moved on. You now have a team of enthusiastic but inexperienced programmers, and you need to make allowances for this. If you are challenged about this estimate you can point to the previous project in support, plus, of course, the reason for your adjustment.
A productivity-based approach
Alternatively, if there are details of enough old projects of a similar type you can use a productivity-based approach. You identify one or more types of units of work, the number of which governs the amount of work in a task. For example, if you were a brick-layer then it would be the number of bricks. In software development, the work unit might be lines of code. In many computer systems, the number of types of input and outputs, including reads and writes from and to data storage, might be a good indicator of development. This is essentially the function point approach. If you have enough old projects you can calculate the daily average number of function points of software functionality created. Say this was 20 – if you count 200 function points in a new project, then the effort needed is likely to be around 10 days.
Where there are no convenient past projects, you will have to resort to creating a really detailed work breakdown structure, dividing each task into its component subtasks, then breaking them down into lower level components until you get to ones you feel can be completed in one or two weeks. You can then add these up to get an overall effort.
Can you explain your estimation decisions?
The beauty of these approaches is that if challenged you have evidence to support your estimates. Other people can spot flaws in your estimates. For example, perhaps you have missed an important difference between the project you are using as your analogy and the current project, and you need to make an adjustment to take account of this. All this may seem obvious, but it is surprising how often estimators cannot explain their decisions.
The way you become a trusted leader of projects is by acquiring increasing knowledge over time about how long tasks actually take, based on completed projects. It would be really nice if you and your sister and brother project leaders could pool this information. If this is not possible then you need to keep your own records: over time these will become an increasingly valuable asset.
Watch productivity levels
One word of warning: one thing you might want to keep is a note of the performance of individual developers. Clearly this could be very sensitive. A practical problem is that you may find that your more skilled team members may appear to be less productive. But of course, if you know they are better skilled, you will give them the nastiest jobs – like amending a legacy system that needs to interface with your new code – and it should be no surprise that these can take up more time.
I hope you have enjoyed these three posts, and that they can help you as you become an ever more experienced project leader.
For more details about project management, see the resources below from Safari Books Online.
Not a subscriber? Sign up for a free trial.
Safari Books Online has the content you need
|Project Management for IT-Related Projects is the only textbook written specifically for the BCS, The Chartered Institute for IT, syllabus. Key areas covered include project planning, monitoring and control, quality control, risk and communications.|
|Shortcuts to success – Project management in the real world presents over 250 years of professional project management experience in a highly accessible format, thus helping project managers get up to speed quickly with good practice, avoid pitfalls and deliver business value. This fully updated edition reflects changes to working practices such as the use of social media and collaboration tools.|
|Project Management Bibliography is used to master Project Management, from basic, iterative and advanced Project Management techniques to the required tools to use to certification prep to useful toolkits and more through the use of Safari Books Online.|