Project Estimation and Planning
Why do development teams fail to deliver a product?
Uncertainty levels. Non-functional requirements. Defining priorities. Meet our approach to estimation and planning that helps our clients to succeed.
22/12/2021
Uncertainty levels. Non-functional requirements. Defining priorities. Meet our approach to estimation and planning that helps our clients to succeed.
22/12/2021
What are Estimation and Planning?
Goals and Challenges
Cost estimation and planning are essential parts of any project and product development, right? Everyone acknowledges the importance of managing budgets, scope and schedule. But why do development teams fail to deliver a product within approved time frames, budgets and with decent quality?
Based on our experience, projects that fail do so from a very early stage of the development on. In most cases, customers and developers miscommunicate about product goals and do not spend enough time to gather all the requirements and provide better plans. This leads to even worse situations when development teams do not update the plans, fail to be agile in terms of scope and mechanically work on tasks set in stone.
This leads us to the vital role cost estimations and project planning play in the successful delivery of projects. We believe that good estimations and planning allow to achieve the following goals:
All these steps allow us to make better decisions from project kick-off up to project delivery. We use the gathered data to make our development process more agile, and empower our clients:
Based on our experience, projects that fail do so from a very early stage of the development on. In most cases, customers and developers miscommunicate about product goals and do not spend enough time to gather all the requirements and provide better plans. This leads to even worse situations when development teams do not update the plans, fail to be agile in terms of scope and mechanically work on tasks set in stone.
This leads us to the vital role cost estimations and project planning play in the successful delivery of projects. We believe that good estimations and planning allow to achieve the following goals:
- Reveal and reduce risks
- Reduce uncertainty
- Create conditions for making better decisions
- Foster trust and engagement
- Spread information better
All these steps allow us to make better decisions from project kick-off up to project delivery. We use the gathered data to make our development process more agile, and empower our clients:
- To know what they can get, when exactly and for what cost.
- To change decisions, functionality and priorities along the way
- To stay informed regarding timeline, budget and project scope changes in order to make proper decisions.
Uncertainty Levels
"When will the project be finalized?", "Can we have functionality X for the exhibition in June?"
Even rough cost estimation and planning is critically important since these two things have a dramatic effect on the decision making process. Customers recognizing that the project cost estimation exceeds their budget and time expectations sometimes leads to customers not pursuing such projects at all.
Planning is hard and plans are rarely fulfilled. Development teams tend to make one of the two decisions:
Both of these approaches are doomed to fail. Teams of the first kind can't answer simple questions, like "When will the project be finalized?", "Can we have functionality X for the exhibition in June?". On the other hand, teams that follow the second approach are vulnerable to unexpected events and can't be agile in terms of changes in project scope and timeframes.
Roonyx does things differently. Our pragmatic approach is based on the level of uncertainty the project faces. Uncertainty is something that we can manage as our estimation and planning process allows us to reduce the level of uncertainty and increase estimation accuracy by introducing an actionable process. But how does uncertainty level affect cost estimations in the first place?
Barry Boehm introduced an uncertainty concept, which later on was renamed as "cone of uncertainty" by Steve McConnel.
Planning is hard and plans are rarely fulfilled. Development teams tend to make one of the two decisions:
- Refuse to estimate costs and plan their work, because they think planning is useless.
- Invest too much efforts in estimating costs and planning the project ultimately believing that the plan is perfect.
Both of these approaches are doomed to fail. Teams of the first kind can't answer simple questions, like "When will the project be finalized?", "Can we have functionality X for the exhibition in June?". On the other hand, teams that follow the second approach are vulnerable to unexpected events and can't be agile in terms of changes in project scope and timeframes.
Roonyx does things differently. Our pragmatic approach is based on the level of uncertainty the project faces. Uncertainty is something that we can manage as our estimation and planning process allows us to reduce the level of uncertainty and increase estimation accuracy by introducing an actionable process. But how does uncertainty level affect cost estimations in the first place?
Barry Boehm introduced an uncertainty concept, which later on was renamed as "cone of uncertainty" by Steve McConnel.
Figure 1. Cone of Uncertainty.
Figure one shows our project schedule and how estimations directly depend on the level of uncertainty which can be increased while working on product design, specifications and gathering more data. The cone of uncertainty recognizes that the underlying risks decrease over time as closer the project gets to its finalization. By facilitating data-driven decision making methodologies, our teams are able to reduce uncertainties based on similar projects and project-unique characteristics, eventually drawing on our entire experience. This, ultimately, reduces the level of uncertainty in planning and cost estimation for our clients.
Process Overview
By combining agile principles and methodologies with our expertise, we can deliver better outcomes even at very early project stages like project cost estimation and planning. It is achieved through a combination of teamwork, best practices and our expertise covering multiple industries and environments. For instance, our past experience in developing marketplace platforms enables us to predict the risks associated with building similar products.
While many believe that the outcome is more important than the beginning, we strongly emphasis the crucial importance of every project planning phase. By carefully planning, we force our client to go through a concrete funnel of processes which help identify required functionalities, yet untapped business opportunities and current constraints. As a result, we can introduce a unique concept, apply a suitable type of project kick-off (PoC, MVP, etc.) and base our cost estimation on the decisions made together with the client.
To streamline our processes, we formulated our guiding principles as follows:
Cost estimation and planning steps to be undertaken:
Results anticipated (depending on a client's needs):
Process Overview
By combining agile principles and methodologies with our expertise, we can deliver better outcomes even at very early project stages like project cost estimation and planning. It is achieved through a combination of teamwork, best practices and our expertise covering multiple industries and environments. For instance, our past experience in developing marketplace platforms enables us to predict the risks associated with building similar products.
While many believe that the outcome is more important than the beginning, we strongly emphasis the crucial importance of every project planning phase. By carefully planning, we force our client to go through a concrete funnel of processes which help identify required functionalities, yet untapped business opportunities and current constraints. As a result, we can introduce a unique concept, apply a suitable type of project kick-off (PoC, MVP, etc.) and base our cost estimation on the decisions made together with the client.
To streamline our processes, we formulated our guiding principles as follows:
Cost estimation and planning steps to be undertaken:
- Gathering data and requirements.
- Requirements analysis and synthesis.
- Estimation and planning.
Results anticipated (depending on a client's needs):
- List of prioritized requirements in the form of epics and user stories.
- List of tasks required to implement specific user stories with coherent cost estimation.
- Full project cost estimation based on the level of uncertainty and available buffers
- List of non-functional requirements and risks which were taken into account during the estimation process.
Gathering Data and Requirements
Every Piece of Information is Valuable
We want to know everything about the product, target audience, goals, business values, competitors, stakeholders, and future plans. Any of these items help us to provide a better estimation and development plan.
While creating a business proposal for our client, we tend to gather as much information as possible, to achieve an understanding of the business behind the desired solution. Later on, it will help us to propose better ideas, make better decisions and deliver estimates that work for specific projects.
While we emphasize the importance of estimating costs and planning the project thoroughly, we are also aware that project briefs frequently change. That is why we limit our time spent on these two tasks to the minimum required. However, every piece of information gathered during the process allows us to overcome uncertainty. Moreover, the time spent at the beginning to gather essential information will positively contribute to the first stages of project development - you will not spend additional time as everything will already be prepared and ready to be transformed into actions. Therefore, it would be wrong to regard the time spent at the beginning as lost or unproductive.
While creating a business proposal for our client, we tend to gather as much information as possible, to achieve an understanding of the business behind the desired solution. Later on, it will help us to propose better ideas, make better decisions and deliver estimates that work for specific projects.
While we emphasize the importance of estimating costs and planning the project thoroughly, we are also aware that project briefs frequently change. That is why we limit our time spent on these two tasks to the minimum required. However, every piece of information gathered during the process allows us to overcome uncertainty. Moreover, the time spent at the beginning to gather essential information will positively contribute to the first stages of project development - you will not spend additional time as everything will already be prepared and ready to be transformed into actions. Therefore, it would be wrong to regard the time spent at the beginning as lost or unproductive.
Non-functional Requirements
Some development teams tend to skip the non-functional requirements specification stage. In most cases, it leads to dramatical deviations from given cost estimations. Missing non-functional requirements can postpone the project release date since critical parts of the project are not implemented as intended.
For example, missing requirements related to the number of users the system must be able to handle simultaneously may lead to not being able to reach the target audience due to devastating outages .
That is why we are using the following groups of non-functional requirements for every project:
For example, missing requirements related to the number of users the system must be able to handle simultaneously may lead to not being able to reach the target audience due to devastating outages .
That is why we are using the following groups of non-functional requirements for every project:
- Performance
- Security
- Availability
- Environment
- Maintainability
- Quality
- Usability
Requirements Analysis and Synthesis
User Stories and Epics
Have you ever been frustrated with the lack of transparency when it comes to task-level cost estimation? Without knowing the impact of a single task on the wider system, prioritizing tasks in an economic way becomes impossible.
Development teams in general tend to use technical tasks and terms in order to describe how to implement the system. It's helpful at some point, but it leads to miscommunication and increasing overheads. Seems like you need some kind of translator, right?
Not necessarily. We are using best practices to describe functional requirements through User Stories. It's a simple yet powerful instrument which allows everyone on the project to speak the same language.
The concept behind User Stories is simple – each requirement is described in the following format: "As a <role> I can <capability>, so that <receive benefit>". This way, a simple sentence yields a ton of valuable information:
A bunch of User Stories can be combined into an epic – whole parts of a system targeted to specific goals.
This approach allows us to have a single communication point between different stakeholders – developers, designers, analysts, customers and users.
We are using different techniques to break down the final product into pieces and provide user stories, such as:
Development teams in general tend to use technical tasks and terms in order to describe how to implement the system. It's helpful at some point, but it leads to miscommunication and increasing overheads. Seems like you need some kind of translator, right?
Not necessarily. We are using best practices to describe functional requirements through User Stories. It's a simple yet powerful instrument which allows everyone on the project to speak the same language.
The concept behind User Stories is simple – each requirement is described in the following format: "As a <role> I can <capability>, so that <receive benefit>". This way, a simple sentence yields a ton of valuable information:
- Who is our user?
- What should they be able to do?
- Which benefits does it bring to them?
A bunch of User Stories can be combined into an epic – whole parts of a system targeted to specific goals.
This approach allows us to have a single communication point between different stakeholders – developers, designers, analysts, customers and users.
We are using different techniques to break down the final product into pieces and provide user stories, such as:
- Top-down \ bottom-up design with user story definition
- User Story Mapping
- UML Use Case Diagrams
- UML Activity Diagrams
- Mind Mapping
- Impact Mappin
- Business Process Model and Notation (BPMN)
Task Decomposition
We know that a good plan can't be prepared without indicating single tasks and who is responsible for it to be fulfilled. Without these granular tasks, we may miss dependencies between user stories and different project activities. Further, as a result, we may lose the ability to optimize processes or timelines appropriately.
For the detailed estimation, we split every User Story into specific tasks and try to think about dependencies at the very beginning of a project.
As a bonus, when working this way, we have a project backlog ready for development from the first day on.
For the detailed estimation, we split every User Story into specific tasks and try to think about dependencies at the very beginning of a project.
As a bonus, when working this way, we have a project backlog ready for development from the first day on.
Estimation and Planning
Efforts Estimation
It can be extremely difficult to estimate user stories directly without decomposing them into smaller tasks. But we can estimate them in an abstract manner using story points or t-shirt sizes. This is called effort estimation and it allows us to:
It can be extremely difficult to estimate user stories directly without decomposing them into smaller tasks. But we can estimate them in an abstract manner using story points or t-shirt sizes. This is called effort estimation and it allows us to:
- Compare different stories based on their relative size.
- Provide better understanding of specific feature sizes at the very beginning of the cost estimation process.
- Extrapolate cost estimations.
Priorities
Priorities are a key part of the cost estimation and project planning process. What matters most and what can be omitted during the implementation? What is the critical user flow of the product?
These questions are extremely important when developing a Proof of Concept or Minimal Valuable Product. Priorities allow us to manage the development process properly in order to deliver key features to customers. This way, we reduce time-to-market and increase the possibility to deliver products faster than competitors.
Priorities also allow us to prepare project buffers based on features that are nice to have but do not necessarily bring a lot of value to customers.
We are using various sets of methods for defining priorities, such as:
Priorities are a key part of the cost estimation and project planning process. What matters most and what can be omitted during the implementation? What is the critical user flow of the product?
These questions are extremely important when developing a Proof of Concept or Minimal Valuable Product. Priorities allow us to manage the development process properly in order to deliver key features to customers. This way, we reduce time-to-market and increase the possibility to deliver products faster than competitors.
Priorities also allow us to prepare project buffers based on features that are nice to have but do not necessarily bring a lot of value to customers.
We are using various sets of methods for defining priorities, such as:
- MoSCoW
- Critical Path Method
- Kano model
- Relative weighting (Karl Wiegers)
- Risk \ Cost MatrixNPV, IRR, ROI
Estimation in Real Numbers
When all the data has been gathered, user stories and epics have been formulated, estimated and prioritized, we then finally have a comprehensive overview of the project and the team has a shared understanding of the end goal. It means that we are ready to estimate the project in actual hours. While the final estimation can be done on the user story level, we prefer estimating the costs of single tasks to further limit the uncertainties and increase the accuracy of the estimation.
We are using a three-point estimation and PERT at this point. These methods are industry standards and prove to provide better results because all the risks and possibilities are taken into account.
Our estimations are then finalized by applying a workload factor and coefficients based on uncertainty levels. The load factor is based on the availability of team members and the expected workload. Uncertainty level and corresponding coefficients are based on the knowledge that we obtained throughout the estimation process.
When all the data has been gathered, user stories and epics have been formulated, estimated and prioritized, we then finally have a comprehensive overview of the project and the team has a shared understanding of the end goal. It means that we are ready to estimate the project in actual hours. While the final estimation can be done on the user story level, we prefer estimating the costs of single tasks to further limit the uncertainties and increase the accuracy of the estimation.
We are using a three-point estimation and PERT at this point. These methods are industry standards and prove to provide better results because all the risks and possibilities are taken into account.
Our estimations are then finalized by applying a workload factor and coefficients based on uncertainty levels. The load factor is based on the availability of team members and the expected workload. Uncertainty level and corresponding coefficients are based on the knowledge that we obtained throughout the estimation process.
What our customer gets as the result
- Detailed estimation of a project based on user stories and tasks.
- Time range and budget estimation.
- List of non-functional requirements.
- List of possible risks.
- Initial project backlog and a team ready to roll
See also