Tools to Help Plan Your Collaboration: Planning Your Effort and Understanding Complexity
Planning out efforts for problems that are complex and ambiguous is tricky. The first place to start is by deciding just how complex and ambiguous your problem is. Have the team think through what they know, and what they’ve learned, about the problem and possible outcomes.
Here are some questions that can help you determine how complicated your challenges are:
Are there comparable problems/solutions that exist to use as a starting point?
Is the problem well understood, based on data, or are there only assumptions that need testing?
What’s the worst-case scenario if a solution goes wrong? What’s at stake?
Can effects and outcomes be scaled down and tested on a smaller population to reduce negative consequences while we learn what works?
This exercise can also be done periodically as you learn more, to help the team see how and if they are de-risking the situation with new information.
Example Plans to Manage Risks and Consequences
You can use the framework in Figure 5-5 to determine how many rounds you’ll need to diverge and converge with stakeholders to minimize risk, weed out uncertainty, and create trust. Depending on how complex your problem space is, you can set aside the time needed and communicate that to stakeholders as a matter of mitigating exposure to negative consequences, rather than meeting arbitrary deadlines.
Figure 5-5. Plan to de-risk and manage negative outcomes in your project by moving it from situations with higher risks and consequences to those with fewer risks and consequences
Being in the upper left or lower right means that you should budget two to three cycles to reduce risk or uncertainty and set expectations that the answer is unlikely to happen right away. Once you’ve worked through a few approaches, you can take a cycle to create something that you can test more thoroughly.
Now let’s look at a few example collaboration plans for different scenarios.
Low Risk, Low Consequences
Because this is a well-understood problem with little downside, you can do quick passes to develop ideas to then test with as real an audience as you can get (Figure 5-6). If you are in a position to run A/B tests, your collaboration simply becomes a bit of structure around an iterative development process; maybe you’re working in a “sprint ahead” mode where the exploration and testing is done ahead of when it is to be implemented.
Figure 5-6. An example for low-risk, low-consequence efforts
This might also apply to more organizational challenges like trying flexible seating arrangements or improving internal communications about an HR processes.
Low Risk, High Consequences
When you are in the top-left quadrant, dealing with something that’s pretty well understood but with big potential downsides, you’ll want to slow down the process to make sure you’re getting really sound information about the effects, intended and unintended, of your solution (Figure 5-7). In this case, you’ll want to make sure you’ve defined the context and objectives fully, giving the team time to understand and clearly articulate them. Then, you can explore and develop a few tests that you run for long enough to get a good trend from the data. This could apply to rolling out a new travel and expense policy, where you want to make sure you’ve worked out kinks before asking the whole company to use it. The goal of this type of effort is to drive down the negative consequences by optimizing what works with some protection.
Figure 5-7. An example for low-risk, high-consequence efforts
An example of a situation that’s relatively low risk but high consequence is changing a checkout flow for a highly trafficked ecommerce site, where the factors involved are well understood and there are other case studies to consult, but if a mistake happens it could have a big impact on revenues.
High Risk, Low Consequences
In this quadrant are efforts that don’t have a big downside to them but do have a lot of uncertainty about what will create the desired results. When you have a great idea but no sense of what it will take to pull it off, or if you want to innovate new ideas, it’s good to set aside a few cycles within the team’s whitespace to work through both wild and mundane ideas and shore up the team’s understanding of where the constraints really are (Figure 5-8). From there, testing the best ideas to get external input is useful. The goal of this engagement is to drive down the risk while keeping the consequences low.
Figure 5-8. An example for high-risk, low-consequence efforts
An example of such a situation might be developing a radical new offering for an audience where the team doesn’t have many points of reference to learn from, but their efforts won’t threaten existing revenues or customer loyalty. Launching new features that augment a product or service but don’t take away its current capabilities is worth experimenting with, since you won’t have to worry about killing your core offering.
High Risk, High Consequences
In this situation, your focus should be to either/both drive down the risk and uncertainty about what will work, or to drive down the consequences of a misstep. It is helpful to spend a sprint thoroughly defining the problem and sharing what everyone knows about the territory, but then it’s better to actually move into the territory and start exploring. You can then run single-sprint-long cycles that let you test ideas quickly (Figure 5-9). At any point you can stop and assess what you’ve learned. This type of work should be done outside the cadence of a shipping development team or operational team. This team needs to be able to share their findings with senior leaders and communicate clearly about how they are progressing in the face of a lot of risk and no tangible benefits.
Figure 5-9. An example plan for high-risk, high-consequence efforts
Making changes to the tax code is an example of where there isn’t a straight path to follow toward desired outcomes, and if something goes wrong it affects a lot of people.
Timeboxing Over Deadlines
One way to deal with the pressure to get to the answer quickly and short-circuit the process is timeboxing, or defining a set amount of time for an activity versus a specific outcome. This helps keep the momentum of the team going, and get them trying out ideas to gain feedback and data about what works to show progress instead of jumping to the end.
Years ago, a group of artist friends introduced me to figure drawing. They had set up a tableau and a model, and I was interested, but anxious. After all, I’m no artist! But as we got started, one of them described how this was going to work. We’d start out with three or four sketches of 10 seconds each. From there we’d move on to 30-second drawings and minute-long drawings until finally, at the end, we’d have a full 10 minutes to draw the model. I was instantly curious. Ten seconds?! That was barely enough time to pick up my pencil and make a line or two! So that’s what I did. The 10 seconds was the constraint I’d been given, so there was only so much detail and “quality” my drawing could have.
The same thing happens with teamwork. It can be tempting to hang back from making decisions, especially if the group isn’t in deep agreement, burning valuable time trying to satisfy a need for information or perfection that just isn’t possible. Vanessa Cho of Google Ventures is a big fan of “time chunking,” and she says it’s often saved her in situations where the time pressure feels overwhelming. By setting up shorter, more limited sections of time, you can often satisfy the need to keep things moving and show progress, without trying to solve for every unknown you face.
“You can’t just go on forever,” Cho says. “But I also want everyone involved to know that while we are moving forward, we aren’t done.” She points out that to be successful, timeboxing must be very explicit and made transparent to everyone. You may want to just timebox a stage in the process, or run the entire cycle as a single sprint, working fast and loose to see what gets unstuck. What’s key is that you don’t skip stages or squish them too far. And, when you reach the end of y
our timebox, you can always add “extra time” if you aren’t quite finished.
How Many Cycles Do I Need?
The question that most teams and their stakeholders ask themselves early and often is “How long is this going to take?” The answer to this question is, of course, the annoying “it depends,” but there are some ways to look at your problem to give yourself some guidelines. Obviously problems and environments will differ, so you should apply your own judgment to arrive at a final plan, but these exercises will give you some lenses to consider instead of making arbitrary guesses or engaging in wishful thinking.
The first assumption is that you are working in sprints, or defined cycles of effort that repeat. Even if you aren’t following Agile practices, it’s useful to frame your work in cycles so that you can communicate increments of progress outside the team while maintaining some whitespace for the core team to work in that feels safe.
You can choose whether your sprints are one or two weeks long, but for my purposes in this chapter I’ll assume you’re working in one-week sprints. The shortest time to set aside for a collaboration is one sprint. This is not to say you can’t do quick workshops in a day, or even do a whole cycle in a few days, but if you are working on a specific challenge with rigor, it’s sensible to give yourself a full sprint cycle at a minimum.
The flipside to this maxim is, don’t plan a collaboration that is longer than 12 sprints. That is, even if you need longer than three months to actually develop a solution, or are working in a context that requires much longer timeframes, it’s generally good to push the team to make one pass through the entire cycle in three months. This means you’re socializing ideas and testing them with some frequency to avoid team insularity from taking you too far off course without feedback. I’ve worked on complicated hardware products where it tooks 16+ weeks and a quarter-million dollars to prototype the full system, but we would still look to prototype and test pieces or low-fidelity solutions more quickly to mitigate risk and learn about our guesses.
So the basic range you should plan in is 1–12 one-week sprints. But that’s a lot of variation. How can you narrow this down? The sidebar “How Long Do I Need?” shows you specifically how to lead a team through estimating how long the entire effort might take, and what assumptions underlie that estimate. Again, it’s worth reminding yourself and the team that this isn’t about promising a deliverable, but about giving stakeholders some expectations about the complexity and approach the team thinks is best.
Tools to Help Plan Your Collaboration: How Long Do I Need?
If the team has prior experience, you likely already know the speed at which they work. If it’s a new group, you can estimate how many ideas they can generate and test in a cycle. For example, if you have a team of four software engineers, a designer, a researcher, and a product manager, you might be able to assume that you could make four tries a week in paper or low-fidelity clickthroughs. If higher fidelity is needed, it may be that only one or two efforts can happen in a week.
The framework from Figure 5-5 helps you think through your approach as follows. If you have a simple problem with few stakeholders, you are likely doing work that is closer to co-creation or cooperation than true collaboration. Remember that cooperation describes the kind of groupwork where the order and contents of the work are well understood and you can better predict both how people should work and what the answer is likely to be. This describes basic work on, say, a new feature for a sprint where all of the details of how it will work are unknown, but the team can easily decide them and test them with users to refine it.
If you have a relatively simple problem, but not a lot of trust from stakeholders about the solutions, you should focus on creating data to earn that trust. Running a sprint or several sprints just focused on demonstrating how the team solves such problems, and how they are thoughtful about stakeholder interests, will help you instill confidence.
With more complex problems you should plan to spend a few cycles learning where the unknowns lie, and working closely with experts and stakeholders until it becomes simpler and can be executed on.
Being in the upper-right quadrant is tricky and will take time. You should budget a few cycles to try to reduce the unknowns you face into something better understood—by both the team and the stakeholders—to earn trust and build up the team’s confidence. As you do, your secondary goal will be to use the trust you’ve built to gain some whitespace for the team to work under less (frequent) scrutiny.
Figure 5-10 shows an example of how you might plan out how long you need based on complexity.
Figure 5-10. Example timeframes for efforts of differing complexity
Your team’s speed and the specifics of your situation may change the number of cycles you need. What’s important is that you weigh the chances of making mistakes (risk) against what might happen if you do (consequences).
Share Plans to Set Expectations
Once you’ve created a plan, be sure to make it visible not just to the team, but to outsiders as well. Consider plans as you would work output, something that falls under the RACI roles you’ve hopefully established. Plans should be socialized widely—again, not as a promise, but as a guess about how the work will unfold. This helps everyone have a sense of what to expect, and where the group is headed. For those who aren’t dedicated full-time to the effort, it’s especially useful to remind them where the team has been and where it’s going.
Keeping track of your progress as you go doesn’t just help you set expectations with stakeholders, it keeps the team focused. It can be easy to forget things you’ve learned, or take assumptions for granted if they aren’t made explicit and visible. The sidebar “Keeping Track of Progress” offers tools for tracking and communicating your efforts.
Tools to Help Plan Your Collaboration: Keeping Track of Progress
Once you’ve planned out the work, it’s important to keep track of the team’s progress; otherwise, it’s easy for the team to lose sight of what’s happened and get lost in the current situation. It helps both team morale and communication with stakeholders when you can show how far you’ve come. You can use the template in Table 5-1 to track what work has been done, and what has been learned each time.
Table 5-1. A template for creating plans for your team and sharing with others Objective(s): # of experiments: Key insights:
Experiments per sprint: Assumptions changed/confirmed:
Assumptions tested: KPIs/KFIs:
The biggest thing to remember when creating this plan is that you are managing expectations within the team about being intentional in their explorations and critiques with each other. You’re also setting up external sessions to review the story of how the team is progressing. This worksheet can be your map of what you’ve tried and what you’ve shared, and will help keep continuity within the team.
Troubleshooting Planning
Issues that come up when you’re making a plan for your team can involve external pressures, such as imposed deadlines, or internal pressures from the team itself. This section offers some suggestions for working through these problems.
Working Against a Fixed Deadline
It’s not always possible to predict how long it will take a team to tackle a complex problem with a lot of unknowns, and there will be times when a critical deadline must be met. In this situation, I’ve seen teams try to argue against the deadline and ask for more time, and never seen it work. Or, teams agree to a deadline with unrealistic expectations, only to miss it and suffer the consequences. In the situation where there is a key date that must be met, but not enough information to know how to get there, you run the risk of putting the group in jeopardy if you don’t work to get more clarity.
So what can I do?
Define partial success
To avoid having the collaboration get crushed under the weight of unreasonable expectations, focus instead on how you can get part of the way there, expressed in business t
erms, not features. If “sign up 2,000 paying customers” is what keeps the company afloat in three months, think about what you can do to get some of those financial results, rather than listing partial capabilities. In Lean UX (O’Reilly), Jeff Gothelf and Josh Seiden do a great job of laying out how to think outside the box to get results without overly committing to work that won’t pay the full dividend in time.
Define the worst-case scenario
It can be hard to be the person who speaks the truth about an ugly outcome. Early in my career, I faced extreme pressure to “be flexible” and agree to a client’s demands even though they put their business at great risk. When the inevitable blow-up happened, it wasn’t just unpleasant—several of my clients lost their jobs and the company eventually folded. The bad outcome that most of my team were focused on was displeasing the client, when in fact the worst case was so much worse than that. If you feel you’ve been given an impossible mandate, you owe it to yourself and others to make sure everyone understands what happens if (even though you know it’s a “when”) the team’s efforts aren’t totally successful.
Mastering Collaboration Page 10
