The 2020 PMI Pulse of the Profession® presents results from the questionnaire among 3 060 project professionals globally.
Based on the answers, 59% of projects were completed within budget, 53% on time, while 35% experienced scope creep.
Many factors impact project outcomes, but in this article, we will focus on our experience from the project estimation process and share tips for software projects.
In future articles, we will share our experience on project budgeting and cost calculation, which are crucial steps after the project is estimated.
Do you remember when you started with the project estimation process? Once the estimation got completed and the project got formal approval, you kicked-off the development.
The beginning of the project was very successful, but after some time, you realized that the development takes more time than planned. You discuss it with your team, but this trend continues, and the only answer left is: We underestimated the project.
If you’re the Project Manager, you know that it’s not the best time in the project, but unfortunately, those situations may happen. You have probably asked yourself a question: Is there anything we can do to prevent us from similar cases in the future?
This article will share several models, techniques, and concepts that will help you with your next estimation. In conclusion, we will come back to that question and share our recommendations.
Speed of change
Michele Sliger in the article “Goodbye, scope creep--hello, agile!” defines the speed of change for project scope, which is much faster nowadays than it used to be in the past. Before agile methods were defined, projects followed cascade concepts with detailed planning, estimations, development, testing, and release. According to Michele Sliger article, this approach was fine as the products were developed before customers could change their mind. However, with inventions that increased the speed of communication, knowledge, and change, customers may change their minds in a relatively short time; hence it’s important to keep the time to market at a manageable level.
Before you start working on project estimation, it’s important to consider the framework in which the project will be executed. There are two most typical types of projects in the project management world - waterfall (also called cascade) and agile. Each type has frameworks and methodologies, such as Prince2 (waterfall), Scrum (agile), Extreme Programming (agile), and more.
The below graph presents the percentage of the projects used the following types of approaches according to the PMI 2020 Pulse of the Profession.
Secondly, it’s important to consider the environmental factors that will impact the customer and the project. For example, you may work on the project with a client, who will need almost 100% precise estimation, because even one day of project delay will cause a high cost.
On the other hand, there may be a client who prefers to estimate the phases of a project. In such a scenario, you may focus on detailed estimation for the next phase and ROM estimation for future phases.
To provide a precise project estimation cost, the team needs detailed information and time for analysis. The project estimation process in such a situation will take more time and be more expensive, but more precise.
The below graph shows how estimation accuracy grows with the time and detailed information available.
• Start with a meeting - try to understand client motivation for a project, environmental factors that may impact the project and business case. It’ll help you to choose the best project estimation methods for the project.
• Understand the timeline - there are projects with predefined deadlines, e.g. planned events. It’s important to discuss it with the client and consider project estimation techniques.
• New products - if the goal of a project is to create a new product on the market, it may be worth starting with a high-level estimation. That kind of estimation at the early stage of a project has a risk factor and is not precise, however, it may help verify if the business case is valid and if the return on investment will be as expected.
There are several methods and techniques that you may use when performing project estimation.
It’s used for projects at the initial stage, where the team does not have lots of details about the project. It’s less time consuming than bottom-up but provides high-level estimation.
The bottom-up estimation method, which requires in-deep knowledge of the project’s details, is adequate for mature projects. The project’s scope needs to be described at a low level with all the details, and those small components of work are then estimated. Work Breakdown Structure may be used to present the detailed scope of the project.
It’s usually very precise, but at the same time, there may be no buffer in the estimation for scope changes.
Bottom-up estimation should not be used for immature projects, where there are no details. Otherwise, when using this method for immature projects, assumptions will need to be made.
It’s more time-consuming than the top-down method and provides a more precise estimation.
Three figures are defined in this method - most reasonable estimation, pessimistic estimation, and optimistic estimation. Pessimistic estimation considers negative risks that may occur in the project, while optimistic estimation includes positive risk.
• Beta (PERT) Distribution
Includes weight in the estimation formula
Estimation = (p + 4m + o) / 6
P - pessimistic
O - optimistic
M - most likely
• Triangular Distribution
Estimation = (p + m + o) / 3
P - pessimistic
O - optimistic
M - most likely
This method might be used by the project team if there were similar projects delivered in the past. Usually, it’s used as the first/initial estimation of the project and it provides ROM (Rough Order of Magnitude) estimation.
• Absolute or One-point estimation
The team will pick the most similar project from the past and use it as an estimation for the new project. For example, a mobile application with the same features has been developed by the team in the past, so they will use it when estimating similar applications.
• Estimate Range
If the project team developed a couple of similar projects in the past, then they may estimate the new project as a range based on experience.
Agile teams are using Planning Poker to estimate project backlog. It’s called planning poker as the team uses cards, similarly to poker, while they estimate.
Each item in the backlog is being estimated by team members using the cards. After the Product Product Owner describes the items, each team member thinks about estimation and prepares the card. At the same time, all members show their cards, and they start a discussion. The session ends when the team reaches the consensus.
Agile teams usually use it to estimate work in story points. Even for virtual teams, it’s possible to use this technique, thanks to tools available on the market.
The benefits of using this technique are that every team member thinks about the estimation and at the same time, everybody shows their cards. Thanks to that, team members are not influenced by other colleagues.
The involvement of experts in the project estimation process is very crucial for project success. Experts have vast experience in similar projects, and they may use it for more accurate project estimation cost. Moreover, they will highlight risks that may occur in the project.
The Project Team may involve experts by introducing interviews, brainstorming, or Delphi Method.
Rolling wave planning
Rolling wave planning is a progressive elaboration technique that adds more details to project requirements on an ongoing basis. This concept focuses on defining detailed requirements for the nearest future, e.g. for the next phase while leaving at the high-level future requirements. As the project progresses, the requirements from future phases are decomposed into smaller parts, and details are being added. This allows us to continuously work on the scope and define it instead of detailed planning made before the project.
The project team may use the rolling wave planning concept and use different project estimation methods—for example, bottom-up for the next phases and top-down for future requirements.
This is a technique in which participants, who are invited, try to reach a consensus on a specific question/subject. A facilitator shares the question and then gathers the answers, consolidates it, and sends another question that is more detailed or narrowed into a specific topic. This process continues until the consensus is reached.
Participants are working separately on answers, hence there is no risk of being influenced by another person’s opinion. Also, the facilitator analyzes responses and when sending the next question he/she removes the unnecessary details.
The estimation process is a crucial factor for project success, as based on estimates, you need to determine the project budget and project schedule. As a Project Manager, you need to be well prepared to start the estimates.
7 Tips to estimate your software project:
1. Check if your company has similar projects in the portfolio. This gives you a chance to use experts from those projects as well as analogous estimation techniques.
2. Invite experts to support the estimation process and risk identification.
3. Do not forget to involve all the project roles in the estimation process.
4. Define artifacts that should be produced at the end of the estimation phase. This will help your team to focus on expected deliverables.
5. Standards and project estimation templates will bring professionalism to the project, reduce the number of potential mistakes, and will speed up the estimation process.
6. If you spend more time on project preparation and project estimation, you will have more precise estimates. The process is time-consuming; however, it may be essential for your project. Ensure that you discuss it with the client before you will start.
7. Be transparent and clear in communicating the approach and results. Everyone must be on the same page.
Need a professional project team? Contact us!
Author: Marta Maciaszek