Process Deviation

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:

1. Go to the Deviations page in our Notion,

2. Create a new deviation document by clicking on New on the top right-hand side of the table and selecting New Deviation (shown below),

   

3. Configure the document as follows:
   • Summary (one sentence summing up the flag)
   • Project
   • Flag type (Yellow, Orange, Red, Black)
   • Flag status (default Unresolved),
   • Raised On
   • Raised By
   • Escalated To (optional)
   • Escalated On (optional)
4. Fill in the details (as much information as possible),
5. Update the deviations column for the project in Mission Control.

Flag Definitions

Flag Type	Identification	Escalation	Examples
Yellow	A minor deviation from the Product Process that affects the Product Manager's workflow and/or the sprint goals	No Escalation	Sprint goal that requires more story points than the team can achieve A delay in receiving documentation in order to plan a sprint Important information is being communicated via chat groups and not in writing
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	Inadequate Product Management tools that impedes the Product Process An unclear single point of contact A lot of ambiguity on a product document or feature requirement
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	A lack of documentation for an API that needs to be integrated A feature requirement that was not explicitly communicated both verbally and in writing No single point of contact or decision maker for the stakeholder
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	No clear documentation or feature requirement No dependable point of contact No regard for the sprint ritual and development process

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.

Flag Escalation

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 (the Product Manager’s Lead Product Manager or 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 Resolved add 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 Discarded and removed from the project’s deviations column in Mission Control.