A GM, a Sponsor, and an Architect Walk Into a Meeting… Who’s Really in Charge?

You have your Steering Committee in a week and you're just starting to put the pack together. One of the sections is for decisions required from the group. How do you decide what to put in here?

There are similar questions at other points in a typical week. A GM decided that he didn't want something to be in scope. Your sponsor decided that they wanted something additional to be in scope. One of the architects decided on a solution design change.

What I observe often, is that these changes are accepted. Often with little conversation. After all, these people have either authority over you, or have expert opinion.

Is this the way it should be?

The problem with some decisions

For many of us, getting an organisation to make decisions can be a hard and lengthy process, so when these quick decisions are made, we appreciate the clarity without the effort.

Except, the effort has been engineered into the system for a reason.

The reason behind the decision is not always clear. Nor is the consequence.

What's the reason behind the decision?

When the reason behind a decision is not clear, it's not possible to evaluate the efficacy of the decision. Decisions are not always made for the benefit of the project. People make decisions for personal gain and to avoid personal pain. If there's no scrutiny put over the decision, how do you know that you're not in this situation?

Even if decisions are being made with the right intent, for many of us our organisations are so large that we can only know a slice of it. And probably understand even less. So even if we think we are making the right decision, we have multiple blind spots and we just don't know. Relying on this sort of decision for your project is fraught.

What's the consequence of the decision?

The impact of a decision is often complicated. Lets take a simple decision to remove something from scope.

This can change the resourcing profile of the project. You no longer need Sally because she was delivering this one scope item which is now removed. This can mean Sally, who was going to be used on another scope item is no longer available.

This can change the value delivered to the organisation. Maybe the scope doesn't add value to your project, so you removed it. But maybe it's a dependency for another project that you're not aware of.

This can change the timing of the project. Maybe this scope item, made two future scope items quicker and easier. Without the base being set, the costs increase.

These consequences may not be intentional. But they are still consequences.

A decision authority guide can be helpful in these situations.

The decision authority guide

The decision authority guide is a simple guide that lists who has authority to make a certain class of decisions.

I like to split decisions into classes. A solution decision often needs a different treatment than a cost decision, or a risk decision.

I like to split authorities into thresholds. Any decision that affects cost up to $10k (a threshold) cam be made by person X, but any decision over $1M (another threshold) must by made by committee Y.

I like to think about when an individual should make a decision (low consequence, within their knowledge base) and when the decision should be discussed at committee instead.

Codifying these behaviors, these decision authorities, makes it clear to all how decisions are made and who can make which decisions. It can turn a project from the Wild West to a little more structured, ordered and thoughtful.

Many organisations have these processes as unwritten rules. Writing them down, making them explicit, often stops a little bit of the chaos on projects.