Delays, Decisions, and Dependencies

The Three “Deadly Ds” that kill Projects

Delays, Decisions , and Dependencies

Delays kill projects. As delays occur you accrue more costs, your teams get frustrated, your customers lose confidence, and eventually your sponsors pull the plug.

Some delays are inevitable. Things will go wrong. Estimates will turn out to be optimistic. Your goals will shift. That’s all fine, and can be managed with a healthy culture of trust. As a delivery leader you can focus your efforts on solving the root causes and clearing the blockers.

Some delays are self-inflicted. Those are the ones that we should not allow to happen in the first place. In my practice I have repeatedly come across two main classes of self-inflicted delays, and have developed strategies to prevent them from occurring in the first place.

Healthy Delays

Some types of delay can actually be good. These happen when you realise you were solving the wrong problem, or you didn’t have the right solution. We don’t try to cause them, but then they happen, we should welcome them, because they stop us from becoming more wrong.

If you have strong feedback loops built into your project culture, you will see your mistakes early. 

“Thank you for showing us your work in progress. Unfortunately that won’t work for us.” Hearing that from a customer can save weeks of wasted effort. You hadn’t fully understood the problem. Now you can fix your assumptions, and use the customer feedback to fix it. Yes, it’s going to cause a delay, but it’s the sort of delay that makes you smarter and gets you to success sooner.

“We’re going to have to port this off MongoDB to something more robust. It worked as a proof-of-concept, but we need a stronger platform.” You had selected the wrong solution. Again, this is going to cause a delay, but now you know more about the problem, you have better success criteria, and you’ll build a better project. Overall, you’ll build a solution faster.

Good, tight feedback loops will help you bring this type of delay forward. You can have value-based conversations with your stakeholders, and they can actually help build confidence.

Self-Inflicted Delays

Decisions

Your team must be able to make the vast majority of necessary decisions without getting external permission. If the team can’t decide on what to build, how to build it, and when it’s going to happen, you will encounter unnecessary delays.

Some examples I’ve seen recently: 

• Changes to the DB schema must be signed off by the DBA group.
• Architectural design must be signed off before we allocate developers.
• Scope changes need SteerCo approval. The SteerCo meets once a month.

The common pattern is that a group outside the team has authority over the team’s decisions, but no accountability for getting the work done. When you see this pattern you need to fix it fast.

I am absolutely not advocating against architecture, or good design, or the value of a great steering committee. But governance bodies should be governing, not managing. If they are affecting your ability to manage your project, or your teams ability to make decisions, then you need to have a conversation. If you want to be involved in the delivery – that’s great. Get into the team and we’ll welcome you and your expertise. If your role has become one of telling the team they are wrong after the fact, then we have a problem that needs to be fixed.

The first step is to make a cultural change. It may take a while to become embedded, but you can start out with a simple declaration of intent: “Accountability means authority. Authority means accountability.”

If we make an individual or team accountable for an outcome – from creating a UI element to building a golf course on Mars – we need to give them explicit authority to make all the necessary decisions. There can be no external sign-off. The developers can hack together the UI without UX Team approval. They can build the DB schema that works for them. The Product Owner can make scope changes. If an architect wants their opinions noted, they can roll up their sleeves, join the team, and take accountability for the architecture.

In return for this authority, the team needs to be transparent. They should make their goals, plans, and problems visible. Get experts in to consult on UI look-and-feel, pull in a DBA to help normalise the ghastly mess you’ve hacked together, spend an hour with the architects, and listen to their advice. But take accountability and make decisions.

As a leader you need to back your team as they make decisions, especially when they turn out to be less-than-perfect. The autonomy that comes from accountability far outweighs the costs of outsourcing authority. Encourage the team to ask for help, but make it clear that the decisions are theirs to make.

By creating this link between accountability and authority at a cultural level, you can eliminate delays caused by external decisions.

Dependencies

When Microsoft acquired the Excel team, as part of integrating it into the Office family, they asked what C compiler they were using. “Our own. We don’t trust anyone else. They might screw us up by introducing a bug.” When it comes to eliminating external dependencies, writing your own C compiler is probably going to an extreme, but the instinct is correct.

Identify your external dependencies and work to minimise them.

As early as possible in Discovery Mode, identify your dependencies on other teams, vendors, regulators, another organisations. With each dependency ask what it would take to eliminate it – build the feature another way, defer the feature until later, or import the capability into your team.

Look for creative ways to minimise the effect of the dependency. Does it affect the whole feature, or only part of it? Can we break the feature down to the smallest piece that has that dependency?

Can we bring the dependency inside the team? Maybe we need to bring in an architect, or a lawyer, or an actuary, or whatever skill you need – bring them in as members of the team, and the relationship changes. It’s not a dependency any more – it’s just another piece of work for your team to manage.

Once you’ve eliminated all the dependencies you have, manage them as risks. What’s the likelihood of a delay? What’s the consequence of a delay? Do we have trusted access to the right people? Do they understand the importance of this? Do we have visibility of progress?

Work to minimise your dependencies. Manage the remaining few as risks. Track them aggressively. Report on them. Make them visible.

Summary

External decisions and dependencies can cause delays outside of your control. Identify them. Work to eliminate them. Actively manage both decisions and delays as risks. It’s always great fun to report to a SteerCo that they are the greatest risk to successful delivery. I promise it will change behaviour.

By assertively managing decisions and dependencies as risks, you can minimise unnecessary delays, and get back to managing the ones that can’t be avoided.

Charles Randles is a highly experienced Enterprise Delivery Professional. He has led, mentored and coached on programs up to the billion-dollar scale around the world. He believes in building a Culture of Trust that empowers people to be their best. You can contact him on 0430 0135 20 or at charles@charlesrandles.com.