Document assumptions and risk modifiers

Risk modifiers are conditions that are known to have an adverse impact on the execution of projects. Identify all known risk modifiers and assumptions in the estimate and proposal documents and leverage both throughout delivery.

Review risks and assumptions during the refinement session of each sprint and make sure that a change hasn’t been introduced. Change is welcome, but be wary of conditions that may affect our ability to deliver promised results within the given budget. Always communicate any shifts to the primary stakeholder as soon as they arise. The following are some common risk modifiers to look out for:

• Extremely large scope and long build duration
• Heavy integration requirements
• Blended team structure
• Limited stakeholder availability
• Taking over an existing project
• Taking over existing requirements

Risk 1: Large scope and long duration of effort

A healthy amount of work to estimate (and plan detailed roadmap for) is up to six months. Anything above and beyond entails some guesswork—market conditions change, scope changes, and requirements shift. While establishing the product roadmap beyond the initial three- or six-month release target is needed and welcome, urge the client to prioritize scope that can be shipped in smaller increments.

Here’s how to counter this risk:

• Break down scope into smaller deliverables that can be conveyed in three months or less. Use these as milestones in the relationship; course-correct together with sponsors/stakeholders.
• Set expectations that a reworkshopping exercise will need to take place every quarter or so.

Risk 2: Heavy integration requirements

The delivery of the product depends on more than one API, some of which are not available and will be delivered in parallel to our workstream.

Here’s how to counter this risk:

• Propose to take ownership of the API build process—a risk we own we can control.
• Establish milestones in the assumptions document for API delivery and leverage them to issue change requests when dates are missed. Identify size of CR ahead of time.
• Consider the reintegration effort once APIs become available—include this in the estimate.
• Establish mocks for APIs early in the process.

Risk 3: Blended team

Large enterprise initiatives require working in cross-functional teams and partnering closely with client-employees and/or third-party vendors. While this is often beneficial to process change and adoption of best practices in the enterprise, a larger and more complex team creates a burden on delivery speed and efficiency. People are generally reluctant to change and will become detractors from the delivery model.

Here’s how to counter this risk:

• Isolate a workstream that is Devbridge only so that it could be used as an example and catalyst for change.
• Call out the complexity in the assumption documentation for the client.
• Establish a cohesive communication process for the team and the overhead necessary for implementation.
• Identify who from the client team owns code reviews and pull request approvals; then associate a premium with said requirement.
• Actively review the impact of the complex team on delivery model during each sprint retrospective.

Risk 4: Limited stakeholder availability

Getting a group of stakeholders together on a recurring basis from various departments is challenging. This modifier can introduce one of the greatest risks because it almost always requires the commitment of the client to mitigate. For example, making functional and workflow decisions with one large financial institution was close to impossible because stakeholders were absent from demos and would avoid committing to decisions, and the primary stakeholder did not have the bandwidth nor the clout to force these decisions.

Here’s how to counter this risk:

• Establish a dedicated senior stakeholder in the client’s organization to corral the group.
• Clearly identify the time and role requirements for the stakeholders up front.
• If violations occur for two sprints in a row, alert the managing director and recommend a hard stop on the project. If agreed, escalate to the client sponsor. Beware: If stakeholders aren’t managed effectively, delivery fails and the accounts are ultimately lost.

Risk 5: Taking over an existing project

Saving a project in trouble is one of the most effective ways to build trust with clients, deliver value, and exponentially grow accounts. There are many risks—technical debt, design debt, frustrated stakeholders demanding results, conceptual fallacies—associated with trying to fix something that’s broken.

Here’s how to counter this risk:

• Mandate a technical deep dive with source code access to evaluate the current state.
• Generate a report evaluating current code quality, architecture, data model, unit test coverage, best practices, etc., and note shifts.
• Start with the initial goal of stabilizing and reducing the technical debt. Establish milestones and objectives as well as a timeline connected to this effort.
• Establish a reworkshopping of the delivery effort once confident with the initial fixes.

Risk 6: Taking over existing requirements (Backlog)

Inheriting identified requirements risk including bias and/or lack of stakeholder alignment. Even if requirements exist, consider running a condensed workshop exercise to get our team up to speed and identify gaps in client assumptions.

Here’s how to counter this risk:

• Leverage prototyping and user testing to validate the backlog and business assumptions. Include an assumption and estimate for this effort in the proposal.
• Lay the foundation for a reworkshopping effort once initial MVP delivery is finished in two to three months.