At most companies that I’ve worked, estimates for LOE (level of effort) of various components of a project have been common, but rarely have I seen attempts to estimate the risks involved. When planning for a project teams should quantify the risk of tasks and prioritize the riskiest tasks first.

Example

Let’s say we are working on an enterprise project which needs two sub-systems:

• ETL: provides a way to import files and bulk create users, where we need to support multiple file types (csv, excel, etc)
• Login: support a variety of different login flows (LDAP, SAML, etc)

We might have different teams with parallel streams of work to build each of these features. The riskiest aspect of the project might be the integration of these two systems:

• If there is a misunderstanding of the API contract between the two teams, extensive re-work might be involved
• The integration point between two systems tends to be where bugs cluster

Based on this estimate of the risk, each team should prioritize integrating with each other as rapidly as possible and just build the base level of functionality needed to facilitate that process.

In this case, it might be decided that the Login team just support normal user registration and the ETL team just support csv files to start. Our integration test (manual or automated) would be to create users by ingesting a csv file and making sure those users can login to our system.

After the integration has been completed and tested, the teams can continue on their respective work streams, but the riskiest phase of the project is completed which removes a huge psychological burden.

Considerations

Where is the most potential for bugs?

Which subsystem of our project is the most complex? Which do we expect to be the hardest to get right? By tackling our hardest tasks first we de-risk the entire project.

What will require the most re-work if incorrect?

We should think about which parts of the system will require the most extensive re-work if they are incorrect. These are usually API contracts and integration points between teams and systems.

Which features can we punt on?

Every project I’ve worked on has had features the engineering team considers trivial to implement or can be safely layered onto the project later. These features are prime candidates to be deferred until later in the project’s timeline. The design of the systems that support these features can be left murky.

Typically, the least risky features are also the least intertwined with other parts of the system. This has the added benefit of de-prioritizing features that aren’t as likely to block release of the project.

Pros

More confidence in our estimates

Our confidence in our estimates of the state of the project increases the longer development continues. This better informs business decisions and can help inform the product manager about which features would have the biggest impact on the project’s success by being cut (if the project is lagging).

Possible mitigation

By explicitly quantifying our estimates of the risks involved, we have justification that we can use to ask for increased resources to mitigate the risk.

Less stress and burnout

In my opinion, projects have two unknowns that are sources of stress:

• Whether the deadline is going to be met
• What and how many bugs are undiscovered

LOE estimates reduce the uncertainty of the first and risk estimates reduce the uncertainty of the second. People like predictability and by reducing this uncertainty we reduce the stress of our teams.