What Is The Context Leadership Model
The Context Leadership Model, created by Todd Little, was introduced in Stand Back and Deliver as a tool for determining the appropriate leadership style given a product’s uncertainty and complexity. The Context Leadership Model can also be used to understand the risks inherent in a product and determine how to approach analysis and documentation in a way that will address those risks. Todd chose to represent each quadrant with an animal whose characteristics mirror those of the products that fit into that quadrant.
The Context Leadership Model
The Complexity Attributes table shows a sample set of attributes and scoring model described in Stand Back and Deliver that you can use to determine where your project fits on the complexity scale.
The Uncertainty Attributes table presents a sample set of attributes and scoring model described in Stand Back and Deliver that you can use to determine where your project fits on the uncertainty scale.
The Quadrants Explained section provides additional explanations of each quadrant.
Scoring the Attributes
Complexity Attributes
Team size
Low Complexity (1): 2
Medium Complexity (3): 15
High Complexity (9): 100
Mission critical
Low Complexity (1): Speculative
Medium Complexity (3): Establish market
High Complexity (9): Safety critical or significant monetary exposure
Team location
Low Complexity (1): Same room
Medium Complexity (3): Within same building
High Complexity (9): Multisite, worldwide
Team maturity
Low Complexity (1): Established team of experts
Medium Complexity (3): Mixed team of experts and novices
High Complexity (9): New team of mostly novices
Domain knowledge gaps
Low Complexity (1): Delivery team knows the domain as well as SME
Medium Complexity (3): Delivery team requires some domain assistance
High Complexity (9): Delivery team has no idea about the domain
Dependencies
Low Complexity (1): No dependencies
Medium Complexity (3): Some dependencies
High Complexity (9): Tight integration with several products
Uncertainty Attributes
Market Uncertainty
Low Uncertainty (1): Known deliverable, possibly defined contractual obligation
Medium Uncertainty (3): Initial market target is likely to require steering.
High Uncertainty (9): New market that is unknown and untested
Technical Uncertainty
Low Uncertainty (1): Enhancements to existing architecture
Medium Uncertainty (3): We’re not quite sure if we know how to build it.
High Uncertainty (9): New technology, new architecture, some research may be required
Number of customers
Low Uncertainty (1): Internal customer or one well-defined customer
Medium Uncertainty (3): Multiple internal or small number of defined customers
High Uncertainty (9): B2C, SaaS, or Shrink-wrapped software
Initiative duration (time between releases)
Low Uncertainty (1): 0–3 months
Medium Uncertainty (3): 3–12 months
High Uncertainty (9): >12 months
Approach to change
Low Uncertainty (1): Significant change control
Medium Uncertainty (3): Moderate control over change
High Uncertainty (9): Embrace or create change
The Quadrants Explained
Sheepdog
Characteristics: Simple project with low uncertainty
Description: Activities the organization does on a regular basis, such as annual updates, maintenance, small revisions to an existing system
Nature of project team: Small, most likely colocated
Useful approaches: Build a shared understanding on the team, then stand back and let the team deliver. Kanban can be useful in this setting.
Nature of analysis: Resolve known unknowns; Build shared understanding with team and stakeholders.
Impact on documentation: As requested by stakeholders; Minimum needed to aid project delivery
Analysis expertise helpful: Domain knowledge
Colt Explained
Characteristics: Simple project with high uncertainty
Description: Solutions that introduce new products or services or support new business processes. Little to no impact on existing systems or teams.
Nature of project team: Small, most likely colocated
Useful approaches: Customer development techniques and agile development techniques
Nature of analysis: Iteratively discover unknown unknowns; Resolve known unknowns; Build shared understanding with team and stakeholders.
Impact on documentation: As requested by stakeholders; Minimum needed to aid project delivery
Analysis expertise helpful: Familiarity with area of uncertainty
Cow Explained
Characteristics: Complex project with low uncertainty
Description: Revisions to existing, often legacy systems that may impact other systems and teams
Nature of project team: Large, dislocated, may involve multiple teams
Useful approaches: Agile development techniques combined with additional practices to ensure proper communication among multiple teams and impacted stakeholders
Nature of analysis: Resolve known unknowns; Build shared understanding with team and stakeholders.
Impact on documentation: As requested by stakeholders; Sufficient to communicate intent to dislocated team members; As needed to aid shared understanding with dependent teams (published interfaces)
Analysis expertise helpful: Familiarity with impacted stakeholders; Domain knowledge
Bull Explained
Characteristics: Complex project with high uncertainty
Description: Introduction of new product or business process that relies heavily on existing systems or substantial changes to/replacement of systems that support existing products/processes
Nature of project team: Large, dislocated, may involve multiple teams
Useful approaches: Approaches that allow for iterative techniques at the team level and coordination among multiple teams. Customer development techniques may be helpful in these situations but you may need longer learning cycles.
Nature of analysis: Iteratively discover unknown unknowns; Resolve known unknowns; Build shared understanding with team and stakeholders.
Impact on documentation: As requested by stakeholders; Sufficient to communicate intent to dislocated team members (more detailed specifications); As needed to aid shared understanding with dependent teams (published interfaces)
Analysis expertise helpful: Familiarity with area of uncertainty; Familiarity with impacted stakeholders; Domain knowledge
An Example
The following figure shows the Context Leadership Model reflecting where the four case studies from Beyond Requirements fit.
Context Leadership Model for case studies
When to Use The Context Leadership Model
The Context Leadership Model can be helpful for the following:
- Performing an initial risk assessment of a project and determining the best way to approach analysis
- Identifying potential opportunities to restructure a project so as to lower risk
- Examining the entire portfolio to get a sense of the aggregate risks faced by an organization in its portfolio
When starting a project, complexity and uncertainty analysis can help the team determine its initial risk profile. Subsequent reevaluations of the risk profile can be helpful for deciding whether existing risks have been addressed and new ones have arisen.
Why Use the Context Leadership Model
The Context Leadership Model is a quick way to assess a project in relation to common risks that all projects face and determine appropriate process and analysis approaches to address those risks.
How to Use the Context Leadership Model
Follow these steps to implement uncertainty and complexity management:
- Identify the attributes and the scoring that you will use for complexity and for uncertainty. A sample set of attributes and scoring model are summarized in the Complexity Attributes and Uncertainty Attributes tables.
- Score the project and compute the average scores for complexity and uncertainty.
Identify the quadrant in which the project falls. Is it a sheepdog, colt, cow, or bull? - Determine appropriate analysis approaches based on the suggestions in The Quadrants Explained section.
- Look at the individual attributes to determine if any represent a significant risk that you need to address in your project. Look for some suggestions for how to address those risks in the Addressing Risks section below.
Addressing Risks
Addressing Complexity Risks
Team Size
Reduce Risk: Split teams into smaller cohesive groups.
Mitigate Risk: Make sure teams have a shared understanding of their purpose and the overall project success criteria. Bring teams together at regular intervals. Define, communicate, test, and manage project interfaces.
Mission critical
Reduce Risk: Not easy to reduce
Mitigate Risk: Make critical decisions and overall project status visible to all stakeholders. Ensure that stakeholders understand the consequences of key decisions.
Team location
Reduce Risk: Colocate the team if possible.
Mitigate Risk: Bring team members into face-to-face contact often. Invest in high- bandwidth communication and collaboration tools.
Team maturity
Reduce Risk: Keep experienced teams whole, and leverage them from one release to the next. Integrate new members into
the team early.
Mitigate Risk: Make sure that time is allocated for mentoring of new team members, and invest in training and improvement for the entire team.
Domain gaps
Reduce Risk: Staff the team with members who have strong domain knowledge and use them to mentor other team members. Ensure that customer needs are constantly represented.
Mitigate Risk: Educate and expose team members to the domain. Have team members sit with users and experience how they use the product.
Dependencies
Reduce Risk: Eliminate dependencies of work with static versions of dependencies. Build automated tests to check dependencies.
Mitigate Risk: Invest in communication with teams that depend on you. Understand their needs and be clear about your progress.
Addressing Uncertainty Risks
Market uncertainty
Reduce Risk: Target a specific market segment that is better understood.
Mitigate Risk: Deliver iteratively, use prototypes, and elicit customer feedback on a regular basis.
Technical uncertainty
Reduce Risk: Accept proven technologies.
Mitigate Risk: Design flexibility into situations to enable decisions to be made in the future. Delay decisions where the uncertainty will resolve itself. Conduct experiments that will provide information to help resolve the uncertainty.
Number of customers
Reduce Risk: Target a specific customer segment or group of customers.
Mitigate Risk: Use a product champion to solicit multiple customer voices and move them in a unified direction. Use the Purpose-Based Alignment Model and decision filters to help you determine which customers to focus on.
Project duration
Reduce Risk: Shorten the duration or deliver functionality in incremental releases.
Mitigate Risk: Deliver incrementally and maintain high quality throughout the project.
Change
Reduce Risk: Exert control over change where it has the biggest impact. Delay decisions so changes can be made without major impact.
Mitigate Risk: Use incremental delivery and feedback to enable change to be absorbed into the project. Avoid committing to too much detail early.
Caveats and Considerations
While colt projects are ideally suited for agile approaches, that should not be taken to mean that agile approaches do not apply elsewhere. Even the lightly prescriptive agile approaches would most often be overkill for sheepdog projects; as long as the team has a clear picture of what they are trying to accomplish and a simple way to stay coordinated, that is probably all the process ceremony needed.
Cow projects can use agile approaches, but those approaches need to be supplemented by additional coordination activities between impacted teams and stakeholders. Agile can also be used for bull projects, but since the best way to address those projects is to split them into colts and cows, the thoughts for each of those projects apply.
Sheepdogs can use agile approaches, but many of the agile approaches are too complicated for these types of projects. Use only the techniques that you need to use, and resist the urge to make them any more complicated than necessary. As Todd Little suggests, “Sheepdogs are fine as agile projects, but just feed them dog food. And make sure you empower the dog to bite the project manager if they ever try to make it too complex.”
It is possible for projects to move from one quadrant to another based on changes in their risk profile. Colts become bulls when the organization cannot properly control scope and ends up involving other projects and systems in what should have been a fairly isolated effort. Cows become bulls when the product owner cannot make decisions at the appropriate time, thereby adding excessive uncertainty.
Additional Resource
Pixton, Pollyanna, Niel Nickolaisen, Todd Little, and Kent McDonald. Stand Back and Deliver: Accelerating Business Agility. Addison-Wesley, 2009.
Want to know more?
If you learn better with video rather than reading, you may want to check out Analysis Techniques for Product Owners Live Lessons, a set of video training sessions that show you how to apply analysis techniques to product ownership. Lesson 3.3 focuses on the context leadership model.
Analysis Techniques for Product Owners is available on Safari – O’Reilly’s online learning platform. Sign up for a 10-day free trial to view the video lessons.