Project Estimation and Prioritization Techniques from Engineering Leader's perspective

My initial journey after taking up the Engineering Leader job had never been easy due to a lack of cognizance required for this particular role. The support from the senior leaders, rigorous self-learning, and an ability to imbibe others' professional expertise put me in a position to operate independently and efficiently. One of the eminent challenges was being part of project estimation and planning according to the overall prioritization. In fact, Project prioritization and planning are primarily the Product Manager's responsibility, whereas the Engineering leader's responsibility is to assist them from the technical point of view. Several stakeholders are also involved in this practice, although overall awareness is essential for contributing to the process. I read through many articles, listened to podcasts, watched relevant videos over the internet, and took guidance from senior leaders to elevate my proficiencies. After spending 2.5+ years in the same role, I think I'm allowed to pat myself a little on the back as the self-assessment seems rewarding. It made me ponder disseminating some of the knowledge I gained to help aspirant leaders within my LinkedIn networks. However, any mid/experienced Product Manager can provide more contexts, but this articulation is based on my limited knowledge only that enabled me to thrive in my role. 

"Tell me and I forget, teach me and I may remember, involve me and I learn" - Benjamin Franklin

I created a diagram to put every aspect of the project estimation together. Let me explain this elaboratively.

Project Estimation Constraints

There are many constraints, but a few primary ones are as follows - Time, Cost, Scope, Risk, Resources, and Quality.

• Project time (how long it will take to deliver) is a vital measure of project success. So our task is to estimate the project time as accurately as possible. It requires a blend of research and experience.
• Cost is another apparent variable. The goal is to follow the proposed budget closely while keeping an open mind about changes that may affect costs. 
• Scope means promised deliverables. Although it lacks a direct impact, any unplanned addition of the scopes may cause a forced revision of other constraints like cost and time.
• Risks are inevitable yet sometimes foreseeable. That's why a contingency plan should be there to counter the risks involved.
• Resources could be people, software/tools, materials, etc. It's all about utilizing the resources efficiently to meet the delivery goals. A resource management plan should be prepared to address unforeseen hiccups in the execution, sudden unavailability of people, etc.
• Quality focuses on how well the project deliverables are completed by following the quality regulations. However, this predetermined aspect is also correlated with the other constraints mentioned above.

Project Estimation Techniques

Still, there are many theoretical techniques. However, the effectiveness depends on picking the right one and executing the same efficiently. Let me illustrate the six prominent practices followed in the industry. 

Top-down estimate

This way, the overall time for the project gets broken down into discrete phases, work, and tasks. Work breakdown structure (WBS) should be prepared for thorough estimation and planning. However, this is one of the least accurate techniques. This is mainly used to estimate cost and time.

When to apply:

1. The project timeline, cost, duration, and somewhat involved resources are predetermined and fixed, or there is little chance of deviation from the original plan.
2. The project is monolithic, and related dependencies are clear enough to start with.
3. The project follows the waterfall methodology.

Bottom-up estimate

This technique is the reverse of the top-down. It starts with identifying the granular level of tasks and then keeps summing up to get the overall project estimate. This technique produces a more accurate estimation than top-down, comparative, or parametric techniques. However, this is also a time-consuming process.

When to apply:

1. Team members are proficient enough to translate the apparent requirements well and estimate accordingly. 
2. The project has a monolithic structure, and the process follows the waterfall methodology.
3. The project is not cost/time bound at the initial phase at least. 

Expert judgment

This is the most commonly used and popular technique as it tends to be quicker and easier. It relies on the experience, sometimes data points, and the gut feeling of the experts to estimate the project. This technique generally gets paired with other techniques for further evaluation as this is partly data and intuition-driven. The accuracy level of this technique depends on the persons involved in the estimation process.

When to apply: 

1. Experts have already worked on similar projects and be able to leverage their past experiences
2. The project is primarily time and cost-bound. 

Comparative or Analogous estimation

This technique uses past project data combined with a top-down approach to estimate project time/duration first. Then the tasks are broken down, resources are allocated, and risks are analyzed to meet the goal within the estimated timeframe. However, this is also one of the least accurate techniques. This is mainly used to estimate cost and time.

When to apply:

1. The project has managed to get a few experts who could do a comparative study to estimate similar projects.
2. The project is either time, cost, or resource-bound. 

Parametric estimation

This technique also uses past project data yet tries to adjust the same data points according to the disparities identified in the new project. This is something like you know how to handcraft a wooden window and estimate for the machine-crafted PVC/Vinyl door. This is a bit better technique than the comparative and top-down techniques but the evaluation process is time-consuming.

When to apply:

1. The project has managed to get a few experts who could do a comparative study to estimate similar projects.
2. The new project has already collected enough data points for the parametric study with the older project(s) data. 

Three-point estimation

This is a data-driven, advanced technique to follow. Sometimes bottom-up estimation technique partially uses this. The PERT (Program Evaluation and Review Technique) method also uses the same. Rather than keeping any assumptions, a weighted average gets calculated based on the following 3 parameters (POM) - Pessimistic, Optimistic, and Most likely. Based on the calculated values, a PERT chart is likely to be prepared for tracking the delivery goals. I can attach a sample PERT diagram as follows. Anyways, this technique is one of the most accurate but can not be used for resource estimation.

PERT formula: (O + (4*M) + P) / 6

When to apply:

1. When project constraints are not clear enough. Especially the risks involved and dependencies. 
2. The project is likely to follow the Agile methodology. 

Project Prioritization Techniques

Project estimation is a critical aspect of meeting the delivery goal successfully. There are numerous prioritization techniques to follow but due to limited scope, I would like to illustrate 4 major and commonly used techniques as follows.

RICE Model

The RICE scoring model is a prioritization framework designed to determine which products, features, and other initiatives to put on their roadmaps by scoring these items according to four factors. These factors, which form the acronym RICE, are Reach, Impact, Confidence, and Effort. We can refer to the following diagram to get to understand the significance of each variable.

RICE score gets calculated this way: (R x I x C) / E

A RICE score isn’t some kind of mathematical alchemy instead this is just an exercise to organize the multiple initiatives according to the delivery goal.

Kano Model

The Kano model helps product teams prioritize their work according to which features are most likely to delight customers. The team will rank each initiative according to its likelihood to please customers as well as its implementation cost. You can also think of the Kano Model as the “Customer Delight vs. Implementation Investment” approach which is basically expectation and analysis-driven. The following illustration is self-explanatory.

The problem with this method is misinterpretation. The product team may find a feature exciting but that might not excite the userbase that much. Still, this is a useful strategy for feature prioritization with a quick turnaround time.

Moscow Method

The MoSCoW prioritization framework helps teams manage requirements and is commonly used to help stakeholders understand the importance of initiatives in a specific release. Group initiatives into four categories, which make up the acronym: Must-have, Should-have, Could-have (or nice-to-have initiatives), and Won't have (lower priority).

This is also a useful technique where priorities can be ordered based on the team's skillset, bandwidth, and time/cost/resource constraints. Still, it has got a few pitfalls such as the team's baiseness for/against any features, and the lack of presence of all stakeholders in the review process may cause inconsistency in the delivery quality. That's why this technique is best suited for smaller teams or with limited dependencies.

The Value vs Complexity method

Value vs. complexity is another framework that allows a product team to evaluate each initiative according to how much value the initiative will bring, and how difficult or complex it will be to implement. Initiatives are then plotted on a quadrant and prioritized accordingly. It is a popular method indeed to allocate time and resources to initiatives based on their perceived or potential benefit.

This methodology is very straightforward to draw a graph or prioritization matrix as the following diagram. The team needs to evaluate each initiative and plot them on the graph based on the anticipated importance and required effort.

This is a very popular and faster method, particularly for prioritizing the features of any new product. Also, it takes features, bugs, enhancements, and all possible development aspects into consideration during the prioritization process.

This is not the END!

As I said at the beginning, there are multiple techniques to follow. There is no the best way! The success of any technique depends on choosing the right technique and efficient execution. Let me name a few more popular prioritization frameworks just for your self-exploration - Eisenhower Matrix, Affinity Grouping, Dynamic Systems Development Method (DSDM), DACI, HEART frameworks, etc.