Skip to content

Project Estimating: A Practical Approach

Project Estimating: A Practical Approach

Estimating how much a project will cost and how long it will take to complete in advance is a big challenge!

My objective in this article is to describe how a project estimate could be made in a practical way.

First of all a project is unique so you can not copy another project and execute the new project like the previous project in practice. Even when the project is executed in the same organisation there are differences (circumstances, environment, etc.).

However, you can and must learn from previous projects! The famous lessons learned …

How many Project Managers do actually share their lessons learned with their colleagues? Is there a kind of senior Project Manager who keeps track of sharing knowledge and experience? Is there a kind of database where lessons learned are stored for future reference? Is there feedback after the project has been finished with the people who made the initial project estimate? How well is Change Management applied?

These are just a few questions in this context.

A project estimate is according to me a composition of many small pieces (work breakdown structure) and ‘some additional stuff’. My assumption is that you have received a ‘request for proposal’ which describes what the client actually wants. This process can also be applied for internal projects. Internal projects must, according to me, be treated as seriously as external projects (in this context external projects are projects executed on behalf of clients outside your own company).

What are the steps that can be taken to end up with a project estimate (duration and costs)?

  1. Collect lessons learned of similar projects.
  1. Contact colleagues who have been involved in these kind of projects.
  1. Get the right specialists onboard. Not only people of the project organisation but also of the organisation that will manage the project products after delivery.
  1. Organise an interactive workshop with a projector and a tool such as mindmapping. Compose together a mindmap of what needs to be delivered (product oriented by using ISO 21500 International Standard on Project Management).
    The main branches of the mindmap could be the products to be made. The sub-branches are the activities to be performed to compose the product. Determine the amount of hours required per activity. Don’t add contigency at this stage (otherwise you will have contingency over contingency later on resulting in huge costs and extra long duration).
  1. At the end of the workshop make a spreadsheet with the most left column the product name, the second column the activities needed, the third column the hours needed per activity. The fourth column the hourly rate per activity. The fifth column contains the multiplication of the hours times hourly rate.
    Make a subtotal of hours per product and an overall (hours and costs) view.
  1. Generic remarks:
  • Do not add risk contingency per activity. This will be done at the end based on parameters such as type of contract (fixed price, time & materials), quality of requirements, new technology, etc.
  • Add a risk budget. This should be based on experience and/or a percentage of the total costs.
  • Add a change budget to prevent that you need to go the the Steering Committee for every change (this applies to small changes normally which have no impact on eg. the scope or contract).
  • Add Project Management on average 15% of the total amount of hours.
  • Add for Quality Assurance on average 5% of the total amount of hours.
  • Regarding communication special attention needs to be paid as well. in case of large projects the communication might be outsourced to an external organisation which could generate additional costs. The question is if the project will take these costs or not.
  • For large projects you need project support to perform eg. administrative tasks. This needs to be in the project budget normally.
    In large organisations ‘shared project office support’ might be available at lower costs.
  • Don’t forget to add a very important activity: transfer of the project products to ‘business as usual’ (management of the products during normal operation).
  • Each project also requires facilities, not human resource related, such as office space, hardware, software licenses, e-collaboration tooling, etc. This costs should also be taken into account.
  • Add the required profit eg. 30%.
  • Use a standard Project Management framework such as ISO 21500 International Standard and a matching Project Management tooling environment. Prevent the use of all kind of local ‘stuff’ made by individuals. I’ve seen examples of huge complex spreadsheets which contained errors, consuming a lot of time to maintain and only one person knew how this works. This is a major project risk! Tools must be person independent and non-proprietary in my view.
  • An option might be to use the ISO 21500 International Standard on Project Management approach which means in this context plan and budget per phase. At the end of each phase the Steering Committee needs to approve the next phase or terminate the project. However, a total project overview regarding duration and costs is not easy to produce. The bandwidth will increase towards the end of the project and will become smaller during the course of the project.
  • An option might be to apply the Agile approach which gives great flexilibilty and quick results. However, just like in the previous item, a total project overview regarding duration and costs is not easy to produce. The Waterfall model in ICT land is outdated in my opinion. The short time to market requires quick results and flexibibility. This doesn’t mean that you don’t need to apply Change Management!