Summary: Knowing the goals won't help your team. Everyone has to stay aligned to the project goals and leverage the goals when making decisions. Aligning your team to the same goals is the key to working in more agile and lean ways.
When eliciting goals from a project team or group of stakeholders, it's not unusual to end up with a list of more than ten goals. That's great. That means the process is working. You're helping stakeholders articulate, share, and discuss goals with one another. That's the first step.
Once the goals have been articulated, shared, and discussed, now begins the work of aligning the team to a singular understanding of how the project will measure success. You have to mold the goals you’ve gathered into a focused, prioritized framework for making decisions and communicating value.
There’s a process you can follow:
"Focused" is the key word. If you collected ten goals, you have too many goals to focus on, so you have to identify a smaller number of goals. To reduce the number of goals, place the goals together into 3-5 groups based on similarity. Once you've grouped the goals together, give each group a name.
For example, in a recent client engagement for an digital marketing website, our client identified nine separate goals they wanted to accomplish with the website.
Nine goals is too many goals for a project team to understand and stay focused on, so we placed the goals into three groups based on similarity.
You’ll notice we grouped some of the goals together while others were left alone. There's no magic number. I like three because three goals is an easy number to communicate and remember. More than five, and you almost always have too many to work with.
Once you’ve identified the project's 3-5 goals, you’ve identified a framework you can use to validate every decision you make. Ask yourself, is the decision in line with the project, department, and organizational goals you identified?
Eventually, however, you will need to decide between two courses of action, each of which supports a different goal. How do you break the tie? By understanding what goal is more important than the other.
You have to prioritize your list of three to five goals from most important to least important. Knowing which goal is most important helps you balance the competing priorities that exist in every project.
There are two ways to prioritize goals:
- Stack ranking
- Pyramid ranking
1. Stack ranking
Stack ranking requires you sort your goals by priority, one after the other. Goal one is more important than all the other goals. Goal two is less important than goal 1 and more important than all the other goals.
You’ll notice this example shows one overarching goal that stretches across each level. This isn’t ideal, but it demonstrates some of the compromises you have to make while working through this exercise collaboratively with your client.
There is no right answer. There is the answer everyone shares and agrees on.
2. Pyramid ranking
Pyramid ranking requires you to choose one goal that is most important, but lets you indicate when other goals are "tied". When working with clients, we always start with stack ranking. While it’s pretty easy to get workshop groups to choose one goal that is more important than all the others, it’s not uncommon for groups to insist that some goals are equally important.
If you ever have to choose between courses of action that support different goals, you can use the prioritization to help make the decision.
Communicate goals to the entire organization
Once you’ve identified a focused list of prioritized goals, you have the opportunity to make sure the team stays aligned with the shared vision and also to share that vision with the rest of the organization.
It works like this: list the goals everywhere. At the beginning of every meeting, show the goals to remind everyone of the framework you will use to make decisions. When you share deliverables, include the goals at the beginning and specify that you developed the decisions in the deliverable based on the prioritized list of goals. Make sure you evaluate every decision against the prioritized goals.
In my engagements at Avanade, I tell clients that we will show them the goals again and again, until they’re tired of them, and then we’ll keep showing them.
Evolve goals over the course of the project
Some clients worry about whether or not they can identify the right goals in a two hour workshop at the outset of a project. This is fair. Over the course of a project, the team’s understanding about the project and its goals will grow by leaps and bounds. The assumptions you have at the beginning of a project will change.
Continuously sharing and reviewing the goals has the advantage of giving the team a gut check on the goals every time they see them.
With one client, a few weeks in, we changed the priority of our goals, moving one goal up and de-prioritizing another. A few weeks of additional understanding revealed more nuances about what we were trying to accomplish.
Align goals to business value
By clarifying goals as project, departmental, and organizational, you’ve mapped how the business values your work. Whenever evaluating a strategic, design, or technical decision, you can point to the specific project, departmental, and organizational goals the decision supports.
Tying your decisions to goals has two benefits:
- You communicate the project’s value to the organization
- You communicate the project’s value to the department
Even if you cannot or have not quantified the results of a given decision, aligning to the organization’s goals allows the team members and stakeholders to understand the quality of the value the project provides.
The cynic might dismiss the idea of qualifying the value of everything you do. However, if you’re not adding value, then you’re not doing design. What the fuck are you doing?
Shared goals are critical for agile and lean teams
Six blog posts and a bunch of workshop activities is a lot of work and process for something so ephemeral. Being one of the laziest people you will ever meet, it’s fair to wonder why I would drag myself and my team and my clients though so much fuzzy, abstract, stickies-on-the-wall, design bullshit.
The key to making teams more agile and more lean isn’t the process, but the amount of understanding the team’s share. Shared, focused, prioritized goals lay the foundational understanding that allows teams to be more agile and lean.
As a designer, I don’t have to specify exactly how an interaction should work because both I and the developer share the same understanding about what the project is supposed to accomplish. I can trust the engineer to develop the interaction because I trust he’s making decisions with the same framework I’m using. As a product owner, I don’t need to document every requirement, because my team shares my goals.
I’ve mentioned before how deliverables are not about documents. The deliverable is always understanding. The more understanding you share, the fewer deliverables you need to share. Shared goals and priorities represent your team’s definition of success. And your team’s definition of success is the foundational understanding your team needs to be successful.
Sign up for email updates
Did you find this post useful? Enter your email address in the form to the right, and I can send you a message whenever I publish a new post.
Or, add the RSS feed to your reader. (I use Feedly.)
Expand your knowledge
I'm a huge fan of the way a book can explore a topic in depth. If you'd like to learn more, try one of these books. (As a bonus, this site earns a modest pittance when you do.)