Disciplined Agile

Develop Common Vision

This Inception process goal describes how we will come to, and communicate, a common vision as to the purpose of the team. An initial vision for this team was very likely developed by our product management team (if we have one) and prioritized by our portfolio management team (if we have one) long before our team started. This initial vision is a starting point for us, effectively forming a high-level promise to our stakeholders that was sufficiently compelling for them to provide the funds required to initiate, or bring new work to, our team. Now we need to explore and evolve this vision in sufficient detail. 

To be effective, we need to consider several important questions:

  • What strategy will we follow to develop the vision?
  • How will we capture the vision (if at all)?
  • How much detail must we capture?
  • What level of agreement must we come to with our stakeholders before we can move on into Construction?
  • What level of formality must we get for this agreement?
  • How will we communicate the vision with our stakeholders?
2021 Project Management Institute Develop Common Vision v5.2 Vision Strategy Collaborative Stakeholder driven Sponsor driven Team driven Capture the Vision Expected outcomes Business canvas Vision statement Business case Project/team charter Level of Detail of the Vision Lightweight Detailed Level of Agreement General agreement Consensus Dictated Formality of Vision Statement of intent Formal agreement - lightweight Formal agreement - detailed Contract Communicate the Vision Kickoff meeting Information radiators Milestone review Review/walkthrough Documentation

Figure 1. The Develop Common Vision process goal diagram (click to enlarge)

You can use the DA Browser to learn more about the options in the goal diagram of Figure 1. 

Why This is Important

There are several reasons why this is important:

  1. Our stakeholders want to know what they’re going to get. Chances are very good your stakeholders will want to know what you’re going to do, how you’re going to do it, how much it will cost, and how long it will take. You will need to provide them with plausible answers to those questions if you hope to have Construction funded.
  2. We want to set success criteria early in the journey. We need to identify how our stakeholders will determine whether we have failed, succeeded, or exceeded expectations.
  3. Our team should have purpose. In Drive: The Surprising Truth About What Motivates Us, Daniel Pink argues that autonomy, mastery, and purpose are what motivates people. One aim of this process goal is to come to an agreement about what we hope to achieve as a team. Furthermore, the Coordinate Activities process goal captures strategies for enabling autonomy and the Grow Team Members process goal provides opportunities for gaining mastery. 
  4. Our team should agree on how we’re going to proceed. As a team we should agree on what we’re supposed to be producing and how we’re going to do so. This is particularly important when people are working from different locations or when the team is large and organized into subteams.
  5. We want to capture key decisions. Early in the lifecycle we often make important promises about the projected business benefits, the payback period, the scope, and even the technologies to be used or supported. We should strive to fulfill the promises that we make, and disciplined teams (and stakeholders for that matter) will track progress against them.
  6. We want to stay on track. Having a vision in place, particularly one that is sufficiently captured/documented, provides the team with something to check against during Construction. When you allow the requirements to evolve over time, when the design evolves in step, and when your plan similarly evolves it is easy to get off track and start going in a different direction. Throughout Construction the team should ask itself if they’re still heading in the direction they said they would, and if not their either adjust the direction or the vision accordingly.
  7. Supports appropriate governance. As you can see in Figure 2, there is an explicit Stakeholder Vision milestone built into the DA project lifecycles to verify that your stakeholders agree with the vision for your initiative before you proceed to Construction. Risk-based milestones are an important part of DA’s lean governance strategy. 
Risk Value

Figure 2. Decreasing risk and increasing value throughout a disciplined agile project (click diagram to expand)

Key Points

  • We may wish to capture our findings in Inception and review them with our stakeholders to obtain agreement on the vision.
  • A vision statement typically includes traditional elements of a project charter, albeit in lightweight fashion, such as scope, schedule, budget, risks, and other supporting information.
  • A vision statement as a summary of our Inception work can be an extremely effective way to get all stakeholders on the same page regarding the expected outcome(s) of our initiative.