It is important for us to recognize when a project is starting to deviate from our product process. When this happens, we must manage it accordingly to prevent any issues with stakeholders and avoid delays in the project.
How to Recognize Process Deviation
Here at Nimble, we follow a clear product development process, from how we start projects, how we manage our sprints to how we do testing. Sometimes situations may arise where we are expected to deviate from our processes. These situations often lead to uncertainty in the project and can increase the level of risk.
The Product Manager is responsible for recognizing when a project is starting to deviate from our product process. The sooner we can identify a deviation, the faster we can address it and keep the project running smoothly.
Here are some visible examples that a project is deviating from our product process:
- Sprint rituals are not being upheld (i.e, sprint planning, end of sprint, sprint goals).
- A single point of contact cannot be identified.
- Changes in the scope of a feature or project that have not been explicitly agreed upon.
- Important communication and conversations that have not been explicitly written.
- Failure to document or maintain an up-to-date backlog.
- A lack of documentation for a feature or a technical requirement.
- Our product stack and project tracking tools being neglected.
How to Flag a Project
Once a deviation has been identified, it is the Product Manager’s responsibility to follow these steps:
- Go to the Deviations page in our Notion,
Create a new deviation document by clicking on
Newon the top right-hand side of the table and selecting
New Deviation(shown below),
- Configure the document as follows:
- Summary (one sentence summing up the flag)
- Flag type (
- Flag status (default
- Raised On
- Raised By
- Escalated To (optional)
- Escalated On (optional)
- Fill in the details (as much information as possible),
- Update the deviations column for the project in Mission Control.
|Yellow||A minor deviation from the Product Process that affects the Product Manager's workflow and/or the sprint goals||No Escalation||
|Orange||A moderate deviation from the Product Process that is occasionally impeding the Product Manager's ability to perform their duties and/or affects the project's scope||Escalate to direct manager||
|Red||A major deviation from the Product Process that is consistently impeding the Product Manager's ability to perform their duties and/or affects the project's delivery||Escalate to senior leadership||
|Black||A breakdown of the Product Processes that renders the Product Manager incapable of performing their duties and/or the project is no longer on track to be delivered||Escalate to senior leadership||
Managing Flags on a Project
Much as you would with a backlog, new flags should always be groomed by the Product Manager and communicated to the relevant stakeholders. Once there is a clear next step to solve the flag, the Product Manager should update the Action Needed column in the flag document. It is important that flags are communicated in writing so that there is transparency and traceability on the deviation.
When a flag needs to be escalated, the Product Manager must update the Escalated To and Escalated On in the deviation document and notify the escalated individuals via a traceable platform such as e-mail.
- Yellow flags do not require escalation. The Product Manager should be able to manage these deviations on their own. However, if the flag involves a stakeholder, the Product Manager should inform the stakeholder about the flag to ensure that the deviation does not occur again.
- Orange flags require escalation to the direct manager (in most cases, the Chief Product Officer). The Product Manager should work with the direct manager to manage the deviation.
- Red and Black flags must be immediately escalated to all senior leadership members (CPO, CEO and CTO). Red and Black flags are reserved for major deviations and require immediate attention.
When to Lower a Flag
By default, a new flag will always have a status of
Unresolved. A new flag should lead to either a new RFC or an action with the intention of solving the flag.
- Once the RFC or action has been successfully implemented, the Product Manager should update the Flag Status to
Resolvedadd the Resolution Date. They should also remove the flag from the project’s deviations column in Mission Control.
- In certain cases, the flag may no longer be relevant to the project. In these circumstances, the Flag Status should be updated to
Discardedand removed from the project’s deviations column in Mission Control.