Heartbeat

The only way to get this project agreed upon is to book all the resources in advance to make sure they’re available. Only then should we move forward. If we don’t plan ahead, we have no guarantee that this project is going to work!

So we will use our project management system, which will allow us to actually book capacity for the time we need it. That way, we know that people are available and that they have the capacity to work on the project.

The results?

A developer is booked for four hours in December 2016. That’s 14 months from now.

Ridiculous!

Believe me, this is a true story. Not only that, but this is the second time I’ve seen this happening in an organisation. The first time, I was part of the problem, but I look back now and I’m embarrassed to say that I used to believe in such planning.

What a complete and utter waste of time.

But hey, it appears on the face of it to make sense, right? At least we know the resources are available. Therefore, we’ve got some degree of confidence that this project is possible.

But we all know that plans change. Resources change, people go on holiday, people get sick. Priorities change. Everything is changing, and it’s happening faster than ever. So if, when you book that developer for four hours in December 2016, you think that you can be confident your project will succeed, you are kidding yourself.

Read that again: you are kidding yourself.

It gets worse! Developers in the organisation mentioned above are booked with a very high degree of automation. So much automation that, when there is a delay, the whole project is rescheduled, overnight. Overnight, every night! So that four hours in December 2016 will very quickly turn into January or February 2017. It may be an efficient allocation of resources, but it is totally ineffective in terms of delivering results.

Are you still confident that you’ll be able to deliver the project as originally planned?

It gets even worse! That developer is the only one who is working in December 2016. Where is the teamwork? When will the team ever get together to collaborate and, heaven forbid, do a stand-up?

The reason such things exist is historical. It’s the way we’ve done projects for years—even decades. It is clearly the way that engineering projects are run. But there’s a big difference between software projects and engineering projects. With engineering projects, we know what we need to do ahead of time. But with software projects, every line of code is new.

As a way of trying to gain control of our IT projects, organisations have introduced high levels of governance. One aspect is to make sure that the resources are available. How do we do that? We book them in a system. Sounds familiar, right?

Okay, okay—yes, we need to have some sort of governance for large organisations. But we also need to balance the fact that there are lots of changes. Clearly, booking so far in advance is wasteful. So what do we do?

Well, there has to be some sort of rhythm to the organisation. If you take a quick look at your scrum teams, you’ll see that they work in these two-week timeboxes, or ‘sprints’. The resources are fixed for these short periods of time.

Why are we not simply thinking bigger?

Concepts such as the Scaled Agile Framework (SAFe) have introduced release cycles. They typically last around three months. This means the resources need to be fixed for three months. But Dean Leffingwell, the creator of SAFe himself, says that SAFe is only effective in an environment where there is product flow.

So what about environments that don’t have a concept of flow? Think about all the large banks and insurance and pharmaceutical companies where project managers run projects. What can they do?

They still have a project plan. Luckily, the DSDM Agile Project Management Framework also has plans consisting of increments, which make it very similar to a SAFe release cycle. The DSDM project manager must simply organise his project to deliver increments that consist of a number of timeboxes.

Therefore, the project manager needs to secure resources on an incremental basis.

In other words, I believe we need to introduce a ‘heartbeat’ to the organisation that beats every three months. Based on this, we secure resourcing for work for the next three-month period.

What else does this allow?

Well, it allows the company to frequently check where it’s spending its resources. It can then decide to refocus and take advantage of new, attractive opportunities when they arise. It also provides a rhythm for when project proposals can be presented and started.

Not only that, it also presents the opportunity to stop long-running projects when they no longer make sense.

It also makes planning much simpler, allowing the organisation to begin to finance teams rather than people. They then become effective and entrepreneurial.

So how do you do this?

Understanding the project portfolio is essential. You need to know which projects you already have running. You also need to know which projects you want to start. It’s a question of priority!

Then, you begin to allocate your resources to the highest priority projects, but only for the next three-month cycle.

After considering a number of projects, lower-priority projects will find themselves with gaps in resourcing. When you have projects that lack sufficient resources, it is time for you to question the viability of those projects or finance them to find new resources (this is called investing).

Then, let the projects run. Remember, the projects must always be demonstrating that they are in control. They must be delivering frequently. The time and the cost is fixed for three months. What is variable, of course, is the scope.

In the third month you start to look at what’s going to happen in the next three months for each project. This is exactly the same time the detailed and refined user stories are produced. So it also makes sense to re-evaluate your resources at this time and compare the projects again.

Before you shout and cry that you’ll have to make so much effort again, you should know that it’s very likely the high priority projects will remain stable and the decision to proceed will be a no-brainer.

Yet as leaders, it is our responsibility to identify projects that can be re-evaluated and even stopped because they aren’t delivering or are delivering less than they should.

Don’t worry; people working on these projects also want to work on exciting new stuff. They don’t always want to be working on the same project for years. They may jump at the chance to start something new.

This requires, of course, getting away from the negative image that stopping projects has. Sometimes we have to stop projects early. We have to reallocate the resources where it makes the most sense, not only for the company, but also for customers and clients.

What results does all this cause?

Perhaps the most interesting effect of this kind of structure is that the organisation will be forced to develop T-shaped personal profiles. If the organisation has many I-shaped profiles, this change will be difficult. But it is surely worthwhile in the long run.

It will force project managers and the business itself to evaluate the value that they are delivering on a regular basis. This replaces the formal schedule, which evaluates right at the beginning when the business is trying to get the project up and running, but doesn’t leave room to stop for further evaluations.

This means we need to continually evaluate the viability of our work. It is only when we have a heartbeat that goes across the organisation that we can do this.

Both the DSDM Agile project management framework and SAFe provide this mechanism.

It’s up to you to implement it—if you want dynamic delivery, you need dynamic governance with a heart(beat).

And You? Have a Think about These Questions (Book 15 minutes if you want to discuss)

  • Do you need to secure all your resources in exact hours, days, or months in advance?
  • Are you stopping your project early?
  • Do you constantly re-evaluate the viability of your projects?
  • Is your organisation paralysed by I-shaped personal profiles, or are you gaining greater flexibility by adding more and more T-shaped profiles?