Risk Up Front: Managing Projects in a Complex World

by Adam Josephs

The definition meeting is designed to be long, messy, and expensive. For projects with fewer than a dozen team members, a definition meeting generally takes four hours (with appropriate breaks). Larger project teams should budget a full workday. The length is intentional—it is designed to slow down and focus the team away from the problems they know they know and onto discovering problems in their blind spot. In fact, don’t be discouraged if your first definition meeting does not get through the entire project statement. The most useful measure of success for these meetings is the list of action items they generate as issues and risks are identified.

High-performance teams are comfortable constantly assuming that they have yet to uncover the biggest risks on their projects. They look for new opportunities to take corrective action early in the pursuit of ensuring success.

The purpose of the WAM is to cause 100 percent complete in the coming week.

Risk transparency: Go around the room and have each team member answer the precise question, “What are the top two risks that you believe will cause the project to fail?”

Your team may set a ground rule saying, for example, that deliverable owners must give their done/not-done status to the project leader by the end of the day prior to each WAM.

Newbies will sometimes accompany their written top risk answer with long explanations of why they picked that risk, stories about why it is important, and so on. The facilitator will gently interrupt, then ask them to read what they wrote. This has two beneficial effects. First, they are on notice that their written words need to be clear and precise enough to stand on their own (later, readers of the risk action plan won’t have the luxury of hearing any accompanying oral explanations). Second, the WAM won’t take as long.

Regardless, for projects large and small, on top of whatever documents your project requires, RUF projects develop and center their work on four simple documents: the project statement, the team list with individual accountabilities, the weekly schedule, and the risk action plan. We’ve used this simple approach on projects ranging from the simple and small to complex projects involving hundreds of team members spread in subteams around the world. We will talk about some ways of adapting these tools to large projects in part 3, but for many projects, this may be all the organizational scaffolding your project needs.

Get used to the fact that documents get printed out, passed around, forwarded among managers and others outside the team, and so on. Get in the habit of marking your documents loudly at the top to identify what state they are in so readers don’t get confused as to whether the claims in the document represent guesses or decisions. This is a good practice for any document on your project (e.g., specs, plans, etc.). It is important to share drafts, but do not mislead readers into thinking they represent decisions until they do.

The description of the target customer should start with, “Who is paying the bill?” but you may need to include the end users. You must understand who these users are and how their satisfaction contributes to your customer’s satisfaction. For example, suppose you are creating a gaming technology you will license to Nintendo for inclusion in one of its products. In this example, Nintendo may be the paying customer, but the end user may be, say, “Males in the United States and China aged twelve to seventeen.” If those users are not satisfied, Nintendo will not be satisfied. It is perfectly appropriate to record this understanding in the target customer section.

The customer does not and should not care, for the most part, what you build into the car to get it to deliver 40 MPG. In fact, we intentionally separate the conversations regarding “what the results need to achieve to satisfy the target customer” from “what you decide to build.” The point, obviously, is to give the team maximum flexibility in choosing what to design and build, so long as they satisfy the customer measures of success. This is an important consideration to keep in mind, especially for the sales team, product management, and senior management: don’t overspecify before involving the engineers. Give them as much design freedom as you can during the commitment phase.

As your team reads through the customer measures of success, take the opportunity to notice if some key area has been left out, particularly one that could impact customer satisfaction. That is a common mistake. Take advantage of the breadth of your project team to identify those missing measures. For example, ask yourself, “What do we need to deliver to the customer beyond the device itself?” Nontechnical issues that impact customer satisfaction are often overlooked. Did you remember to include success criteria related to customer service? Warranty coverage? Installation experience? Sales process? Remember, your goal is not to build a widget but to satisfy a customer—these issues are integral to your project’s success. Manage them with the same rigor you use for engineering.

The list of components should be necessary and sufficient to deliver precisely the customer measures that were specified. Because the customer measures cover all aspects of the project results that impact customer satisfaction, the components list will similarly cover all those aspects. For example: A warranty contract A user manual A dealership repair manual It is often interesting to explicitly name vendor product choices for components. For example:

As you debate and settle each section, your team proceeds down this hierarchy of context, from customer to need to solution to value. But be aware that every step down this hierarchy creates an opening for mistranslation and loss of fidelity. For example, you might accidentally ascribe a need incorrectly to the customer or select an inappropriate solution in the face of an ambiguous or nonexistent need. Therefore, it is critical to deploy your resources up front, deliberately, expensively, and proactively to minimize the risk of getting this wrong. The job of your team and commitment phase is to inspect, question, and experiment in the name of reducing the translation error. This is the soul of the Risk Up Front commitment phase.

It is a good idea to establish clearly who is the team member who knows most about the target customer, who owns the customer relationship, and is best positioned to be accountable for ensuring the customer will be satisfied by the results of this project. It might be the team member from Marketing or perhaps the one from Sales. They can be charged with crafting the initial draft language for the project statement’s target customer and customer measures of success. Such a draft will, at least, contain placeholders for likely measures, identifying what areas might need to be covered. There will likely also be draft language about what, approximately, the business measures should be. The project leader can incorporate these into the project statement prior to the first definition meeting.

Check: The business measures include a credible projection of what profit you anticipate by delivering the capabilities described by the given customer measures of success to the given target customer. They include a credible projection of your costs to build, deploy, and deliver those capabilities. You are satisfied that this profit is sufficiently valuable, that the project is worth doing given this cost. The organization is committed to tracking the business measures over the period that these profits and costs are accruing.

“Time to profit” is the best way to think about a project schedule.

For each member of the project team, the team list indicates whether that person is on the core team or the extended team. It also indicates which track they belong to, and whether they are the track leader.