It is often argued that project management skills are generic and a good project manager can
manage any type of project.
While there is a grain of truth in this, in IT or other technical projects, it is important that a least some managers have to have an understanding of technical issues.
Is anyone surprised that Crossrail, for example, which is recruiting project planners for the construction of the new London Underground line, wants people with an engineering background?
This understanding is clearly important with estimating the effort needed to carry out development. Incorrect estimates are a common cause of overdue projects.
Experience is not enough
I have heard a project management luminary 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.
However, if I had been asked to explain how I had arrived at my estimate at the time I would have muttered something about experience. This stopped serious discussion of my estimate.
Commonsense approaches to estimating allow the developer and the project manager to have a proper discussion of estimates.
Box: Learn how to estimate IT project timescales
Download this chapter from Bob Hughes book Project Management for IT-related Projects for more tips on estimating project timescales.
Includes a 20% discount code for Computer Weekly readers on the full book.
Click here for more BCS books on Computer Weekly.
Estimating by analogy
The beauty of these approaches is that if challenged you have evidence to support your estimates
Firstly, analogy 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. If you are challenged about the project you can point to the previous project in support.
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 information systems development, the number of types of input, outputs and internal tables in a system might be a good indicator of development.
This last example is essentially the function point approach. If you’ve got enough old projects you can calculate the daily average number of function points of 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.
Dividing into sub-projects
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.
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.
Bob Hughes worked on IT projects in the telecommunications, energy and local government sectors before becoming a Principal Lecturer at the University of Brighton where he gained a PhD in software measurement. He is the author of a number of books and chief moderator of both the BCS Professional and Higher Education Qualifications in IT Project Management. He is the editor of Project Management for IT-related Projects.
This was first published in January 2013