“Happy ‘projects’ are all alike; every unhappy ‘project’ is unhappy in its own way. “
You might recognize this quote as a play on words with the first line of Tolstoy’s Anna Karenina - although the words ‘families’ and ‘projects’ are interchanged, they should never be considered interchangeable. However, one might see the sad truth in both cases.
Working on projects in the “Complex-Chaotic” quadrant intersection of the Cynefin diagram, where today’s projects are mostly found, can be quite challenging. Trying to gather every valuable input, feedback, and requirement from a stakeholder group that is large and dispersed, lacking in communication and collaboration between its representatives, product or feature owners, and not having a single point of decision making, can easily discourage and demotivate.
However, there is a simple structure, process, and approach that has been proven effective time and time again, categorized under different names and found in many certification programs. It follows four phases to build a prioritized delivery plan - a roadmap on an “epic” level of abstraction.
The approach
The goal behind this holistic approach is to clarify the path one needs to take in building a detailed, prioritized, and approved delivery plan. Certain steps are one-off, meaning one needs to make it only once before continuing on to the next one, such are the elicitation and approval phases, where the requirements are broad and highly abstracted. These two phases are later approved in the same state; conversely, some are iterative and incremental, such as the estimation and prioritization phase. The delivery plan is kept up to date and on track with any affecting changes.
This approach also incorporates adding buffers once at the highest level of abstraction for each item, carefully adjusting the delivery rate to follow the cadence of the team as it is averaged out after some successful iterations. Therefore, the importance of iterative and incremental adjustments in the estimation and delivery can be naturally seen here.
Bringing value to the product is the main objective of creating any delivery plan and its careful prioritization. A large portion of this approach concentrates on the faster return of investment, and I emphasized one best practice, i.e. Karl Wieger’s relative benefit and penalty, that has been proven useful in many projects in referenced literature, as well as in real-life experiences. The statement that high-value and high-risk items should be developed first while low-value and high-risk items should be avoided completely will be analyzed in greater detail.
Wrapping things up by committing to the proposed delivery plan with the theory of setting up delivery date ranges that we can follow with 50% to 90% certainty will create a delivery plan that the stakeholders can approve and follow closely with the delivery managers, making only small adjustments inside the proposed and agreed upon limitations.
Elicitation of stakeholder requirements
The aim of this step is to get feedback from every stakeholder in terms of new features and existing functionality improvements that have been identified by their teams, either coming from end users using the system or a suggestion shared by the clients.
In this phase, an invitation is sent to all stakeholders, but engagement by the chief decision makers is crucial; they would advise everyone to elicit feedback from the teams and provide a list of suggested improvements in the format: title, description, key benefits, and requester/owner (see Table 1.1). Note: The owner can be later changed to the one responsible for timely decision-making.
When collecting feedback, many techniques can be found in the BABOK guide (Business Analysis Body of Knowledge). The most challenging step in the collection of feedback from dispersed stakeholders is to gather them in one place at one time and ask for a few hours of their time. The streamlined version of this process proposes sending a document in the type of “Survey or Questionnaire.”
Initially, each group of stakeholders can produce separate backlog documents that will include the template table. At a later stage, these documents should be merged and diffed to create a single proposal for a backlog that will later be used in succeeding phases to be built upon, before creating the final document.
Note: There should be a time limit on waiting for the response from the stakeholders. The typical duration should not exceed 2 weeks. This time limit should be communicated, and it should be clear to everyone that after this period, any request will not be considered valid until the next time this process is restarted.
Estimation and prioritization
Once the first phase is completed and the information is collected from all stakeholders, the next step is to schedule a short session (depending on the size of the backlog, it can usually vary between 30 minutes and 2 hours; anything longer than that should be split between multiple sessions) with the key decision makers to define the business value of each feature and to prioritize by their desirability.
Prior to this meeting, we will go through the process of collating feedback from different stakeholders and identify any overlaps so that we can refine the final list of features to be reviewed in this session. Prioritization would be based on estimated business value, risk, and desirability.
The next step is the affected projects developer leads, supported by the Product Architect. The leads will estimate the effort for every requirement starting from the top of the backlog, which will provide us with the total score and rank.
Estimation is a topic in its own right, but some main guidelines can be followed when estimating large undertakings with ambiguous details. One of the simplest epics can be analyzed in greater depth by everyone, perhaps roughly broken down into its sub-components and estimated as usually done during Sprint planning or Refinement ceremonies. After the estimation of all sub-components, their effort should be summed up as estimated and be given a buffer only at its highest level (giving a buffer on each component can result in overestimating). More about buffering will be mentioned in later phases, but as a rule of thumb, the following values can be used.
Certainty is the percentage likelihood that a task will be completed on time. The 100% certainty implies that similar tasks are always completed on time. If only one in every two tasks tends to be completed on time, then the certainty would be 50%. Certainty is the gut feeling of the developers who are on the spot. If they feel confident, they may estimate 90% certainty. If they’ve never seen something before and have no idea how to do it, they are more likely to estimate <50% certainty. For example, if a developer estimates a job will last for 1 month, with a 40% certainty of completion, then the estimate should ideally be inflated by 2 to 3 months.
After better understanding what estimation points mean, relative to the epic estimated in greater depth, estimations should be given to other items in the backlog. Many stakeholders struggle with the story point estimation system, and usually, they might ask for a team-day or team-months translation. When providing these values, historical values can be helpful if the teams have previously worked on a project together, but even among teams under the same program, the story points scale can vary. Therefore, another (but not additional) buffer can be introduced here, and the delivery date is given as a range instead of a single date. The range can follow the buffer given for the epic, the earliest date as the original story point estimation, and the latest date as the buffered one.
Prioritization on business value and risk
We often look at four factors that determine the value of the business decision:
The financial value of having features
How much money will the organization make or save by having the new features included in the product? Often, an ideal way to determine the value of a feature is to estimate its financial impact over a period—usually the next few months, quarters, or possibly years. This usually involves estimating the number of new sales, the average value of a sale (including follow-on sales and maintenance agreements), the timing of sales increases, and so on.
The cost of developing (and supporting) the new features
The duration of fully implementing each feature directly reflects its cost. The longer one feature takes, the more man-hours would need to be invested. The cost rises as more experienced Engineers, and Subject Matter Experts are engaged in its specification and development. The best way to reduce the cost of a change is to implement a feature as late as possible—effectively when there is no more time for a change.
Learning and the knowledge gained by developing the features
On many projects, much of the overall effort is spent in the pursuit of new knowledge. It is important that this effort be acknowledged and considered fundamental to the project. The flip side of acquiring knowledge is reducing uncertainty. At the start of a project, there is some uncertainty about what features the new product should contain. There is also uncertainty about how we will build the product. We can also split this knowledge into two categories.
- Project knowledge is the knowledge about how the product will be created. Examples include knowledge about the technologies that will be used, the developer skills, how well the team functions together, and so on
- Product knowledge is knowledge about what will be developed. It is knowledge about the features that will be included and those that will not. The more product knowledge a team has, the better they will be in making decisions about the nature and features of the product
The amount of risk removed by developing the features
Almost all projects contain tremendous amounts of risk. A risk is anything that has not yet happened but might, and that would jeopardize or limit the success of the project. There are many different types of risk on projects, including schedule, cost, functionality, technology, and business risks. Prioritization to reduce or mitigate risks is reviewed in greater detail later in this post.
Consider the figures in the table, which map the relationship between the risk and value of a feature into four quadrants. At the top right are high-risk, high-value features. These features are highly desirable to the customer but possess significant development risk. At the bottom right are features that are equally desirable but that are less risky. Whereas features in the right half of the figure are highly desirable, features falling in the left half are of lower value.
The high-value, high-risk features should be developed first. These features deliver the most value, and working on them eliminates significant risks. Next are the high-value, low-risk features. These features offer as much value as the first set, but they are less risky. Therefore, they can be done later in the schedule. Next are the low-value, low-risk features. These are sequenced third because they will have less impact on the total value of the product if dropped and because they are low risk. Finally, features that deliver low value, but are high risk, are best avoided. Defer work on all low-value features, especially those that are also high risk.
Here ends part 1 of this article. Part 2 will go into greater detail about the prioritization process and one very well-accepted approach. Later, we will continue with Phase 3 and Phase 4 of ‘The Approach’, i.e. Delivery Timetable and Final Review and Approval.
About the author
Borjan Petreski is a Service Delivery Manager working in the engineering hub in Skopje.
Borjan is a versatile Service Delivery Manager and Scrum Master who has experience working within different agile frameworks, such as Scrum, Kanban, or "Scrumfall." Borjan managed multiple projects and products simultaneously with varying stakeholders and SMEs from various fields.
