The Wolf in BKPM's Three-Sided Table: “Get it straight buster, I’m not here to say please.”

In the movie Pulp Fiction, there is a scene that all PM’s should watch over and over and over again. And then, they should watch it again. We use this scene in our Bare Knuckled Project Management (BKPM) training as an example of how to take [extreme] control of projects. You can watch the annotated version on YouTube.

Most of the time BKPM’s do say “please.” In fact, in the three-sided table model, the BKPM is the honest broker, who is polite and gracious, but does not represent a particular interest. The BKPM owns only the plan and the process, but not the outcome and not the technical solution! The BKPM serves as the honest broker, negotiator, and arbitrator who makes the process work.

Strangely, if the project manager becomes too emotionally invested in the outcome, rather than the process, it hurts the three-sided table, and ultimately the project itself. The project manager becomes co-opted by the customer’s side, and no longer has the ability to balance outcome objectives with technical reality.

The other direction is equally problematic. If the project manager becomes too deeply allied with the implementation team, the need to deliver a technical solution can override the need for that solution to achieve the customer’s desired outcome. We’ve all seen projects where the implementation team points proudly to a solution (“It’s done!”) and yet the customer’s fundamental needs have not really been met.

While the project manager’s investment in one side or the other doesn’t itself cause the project to fail, it significantly increases the risk. As soon as the project manager stops being seen as an honest broker, communication begins to break down, and the needs and goals of the other two sides of the table naturally begin to drift apart.

While investing in the outcome doesn’t itself cause the project to fail, but it does increase the risk. We refer to this as co-opt risk.

That’s not to argue that emotional involvement on the part of the BKPM is wrong — quite the contrary. Emotional investment can be very positive, as long as it’s invested in the right direction. For the BKPM, that means emotional investment in having the best, most foolproof process; anticipating and managing all known risks; and solving the inevitable problems that crop up on even the best-run project are all wonderful goals.

The sponsor is responsible for articulating the desired outcome in sufficient detail to allow the solution team to craft a solution within the boundaries of the Triple Constraints — time, cost, and performance criteria.

By definition, the customer/sponsor owns the outcome of the project. The customer naturally has the clearest insight and understanding of the potential impacts of success or failure. The customer/sponsor also has the best understanding of the level of scope change that the organization can bear in order to realize the benefits of the project. Only the outcome owner can make certain project decisions related to the organization as a whole.

Many times, the outcome owner cannot or does not explain all of the impact, the politics, and the relationship of the project to the overall organizational strategy or tactical deployment. For that reason, other project participants might think that the outcome owner is making terrible decisions, but they have no way of knowing all customer actions or understanding of the ultimate outcome of the project.

The implementation team is responsible for crafting the solution to reach the outcome desired by the customer or sponsor, within the boundaries of the Triple Constraint: how can we achieve the outcome within an acceptable time frame and at an acceptable cost?

It’s the solution team, not the BKPM, who has this responsibility. It’s the job of the BKPM to force the solution team to define what can be done, how long it will take, and how much it will cost.

What if the outcome can’t be achieved within the boundaries of time and cost? That’s certainly a problem, but if that’s the reality, it’s always better to know it up front, before the project begins. The same thing is true if the solution is risky — it’s something we haven’t done before, or we’re taking on a challenge at the very edge of our capabilities.

Sometimes it’s necessary to negotiate between the customer and the implementation team, and that’s another reason it’s so critical to have the BKPM in a position to serve as the honest broker.

Serving as honest broker, negotiator, and arbitrator is an essential part of the job of the BKPM. As an independent part of the three-sided table, the BKPM remains at arm’s length from the other two sides to ensure that everyone involved does his or her job. Risk evaluation, assessment, and mitigation are an active part of this process.

The BKPM can’t afford to take ownership of matching customer requirements to team deliverables. If the customer or sponsor hasn’t yet made it clear what the desired outcome is, the BKPM can’t permit the partner/team to end up with responsibility for managing a muddle.

Similarly, the BKPM has to make sure that the potential solution is properly validated. Is the process reasonable? Is the focus on achieving the outcome? Are the assumptions of the implementation team appropriate and realistic?

In this process, the BKPM works with both of the other sides of the three-sided table. There is often some back-and-forth before all parties get on the same page with a solution that works. Sometimes one side or another has to give a little bit. Sometimes, the goals and project parameters have to be revised.

But all of this must take place before the work of the project begins.

Being the Wolf and Forcing the Customer and Sponsor

The BKPM’s job in this relationship is to force the sponsor/customer, who is usually senior to the BKPM in the organization, or is a client of the BKPM’s own organization, to own the clear articulation of the desired outcome.

And yes, forcing is often the right word. Just because a sponsor or customer wants something, it doesn’t mean that he or she truly understands it well enough to articulate it.

Sometimes, the sponsor or customer resists being clear about the desired outcome as a way to avoid responsibility if things go wrong. If the project manager accepts this, and doesn’t force a clear and definitive articulation, the project is in deep trouble — and usually, the project manager ends up being blamed. The BKPM never allows this to happen. If the sponsor or customer won’t go on the record about the goal, the project stops right there.

Of course, that’s never the goal anyone wants. Instead, the BKPM leads a process of forced clarification.

It takes courage — and usually risk — for a BKPM to take this responsibility, but think of the alternative. If you don’t know where you’re going in the first place, it’s not realistic to expect to find a way to get there.

The customer or sponsor must own the outcome. That’s their fundamental role. Most of the time, a sponsor likes the idea of being crystal clear, and will agree to that as a requirement process requirement. This is key for the BKPM. Sponsors do not always understand how difficult it can be to achieve clarity, but because they have already committed to it, they are forced to be clear in order for the project to proceed. In other words, force is applied by agreement, not by confrontation.

The most important step in forced clarification is the focus on why. A project is not an end in itself, but rather a means to an end. The more you can clarify the desired end state (the “why” of the project), the easier it becomes to define the “what” (objectives) and “how” (methodology). To do that, the BKPM asks tons of probing questions.

Additionally, the implementation team defines the lack of clarity. The implementation team is used as a lever to judge the level of clarity needed in order to be successful. In order to scope a project successfully, the implementation team must create deliverables that it can achieve and it must properly define and limit those deliverables.

Furthermore, the outcome owner must agree to the deliverables and to the limits put upon them. Failure to reach agreement keeps the project from progressing. The BKPM facilitates this process until both opposing seats of the table are satisfied.

The BKPM participates in this process by exposing risks that must be addressed by both other parties. The BKPM also participates by measuring and portraying the level of risk being assumed by the project caused by any less-than-clear deliverables or specifications and develops acceptable mitigation plans to deal with them if/when they are encountered.

Here’s another advantage of keeping the BKPM separate from this process. First, if the solution team has to go back to tell the customer that he or she can’t have the outcome within the cost and time constraints, there’s usually pushback. If the BKPM is part of the process, the BKPM can’t be an honest broker. But an honest broker is exactly what’s necessary when this happens.

Because the BKPM owns the process, we can insert gates in the plan that make it impossible to proceed without a sufficient level of clarity in the deliverables being committed to by the solution team. This gate is usually all of the force that is needed to compel the solution team to provide the level of detail necessary and level of commitment necessary to the project deliverables. Deliverables are not the same as outcome. Often time, deliverables can change and still satisfy the outcome owners. There is usually more than one way to skin that cat.

Payoffs from the Three-Sided Table

When the project manager is considered part of the team itself, rather than an independent part of the three-sided table approach, the project manager is part of management when deciding about the goals and objectives, and part of the team when advocating a technical solution. That creates a tendency for the project manager to become an advocate, not an analyst, for the two sides. This isn’t optimal.

There’s often a conflict between what the customer wants and the team says they can deliver, and someone has to decide. If it’s the customer, the team can be forced into an impossible situation. If it’s the team, the customer may be paying a lot more than needed to solve the problem. You need an honest broker, someone who stands outside the conflict, to make it happen. Sometimes you even need Winston Wolf. That’s the BKPM.

Managers aren’t always the subject matter experts about the type of work being done in the project. Many people who need IT solutions aren’t IT professionals, for example. If you push the team into an impossible project, nobody’s going to win.

What you want is the truth.

Teams don’t always understand the wider context. Some requirements on a project may be flexible, but others are absolute, and which is which depends on the circumstances. Those circumstances aren’t always obvious to outsiders. Just because you tell the team the requirement is absolute doesn’t mean it really is, or that they believe you. What they need, as much as you, is the truth, whatever it might be.

The BKPM holds everyone’s feet to the fire. The BKPM challenges the assumptions and ideas that the customer or sponsor puts forward. Is the objective clear and specific enough to allow the team to work effectively? Are the triple constraints of time, cost, and essential performance reasonable? Is risk within bounds?

The BKPM challenges the proposed technical solutions and approaches that the team comes up with. Are they reasonable approaches to achieving the project within the triple constraint? What’s the level of risk?

As process owner, the BKPM is the escalation point for most project issues, freeing the senior executives on the customer side from dealing with any but the most serious and far-reaching issues. The BKPM pulls in executives only when necessary — letting them sleep at night.

Finally, the BKPM is the person who needs to stop the project and hold the right people accountable if the goals and the solution can’t be brought together.

Because the BKPM owns the process, the BKPM has P&L accountability for the project’s success or failure. The BKPM won’t let the project go forward until there’s a reasonable prospect of success. That’s in everybody’s best interest.

What do you think?  There is a growing body of evidence that this approach and its corresponding tools (BKPM Pocket Guide) substantially removes risk from all projects.  Do you model Winston Wolf in your projects? Let us know.

[This was largely excerpted from Bare Knuckled Project Management; how to succeed at every project (Gruebl, Welch & Dobson, Gameplan Press, 2013) available for download from Smashwords or Amazon. Feel free to call Jeff Welch or me at Think at 410.235.3600 to schedule a discussion of how you can use BKPM to succeed in every project.]