The Utopia of Dedicated Teams in Multi-Project Management

What I’m now observing all over the world is low project maturity that results in huge cost overruns and time delays. I turn on the news to see that the Betuwe railway line between Rotterdam and German border at Zevenaar-Emmerich is five years late and is already three times over budget. Even in the tech industry, projects fail with detrimental outcomes. Every third IT project in the UK is doomed to failure, according to a recent Axelos report. The list of delayed projects extends every day.

Blurred Visibility and Assumptions

Concentrating on the statistics for project failure, I’ve concluded that the vision of most project managers is exceptionally wrong. As a CEO, I always want to know when all our projects will be finished. But the dirty little secret of project managers, according to the Harvard Business Review, is that they have no earthly idea about the true end date. This is really interesting. How can we be sure that our projects won’t fail? I’ve found the answer in a book by one of my favorite writers:

Your assumptions are your windows into the world. Clean them regularly, otherwise the visibility could become blurred. – Isaac Asimov

Bingo. It all starts with our vision and assumptions. Take a look at different methodologies – Waterfall, Scrum, Kanban, CCPM. What are their basic assumptions? Employees are only working on one project at a time. They’re worthy of being called members of a dedicated team. If you really have one of these teams, you’re lucky. But in my experience, dedicated teams, at least in the Netherlands, don’t exist. If there’s a top developer working on a sprint, his or her help might also be needed in another project, perhaps for two days. The assumption that this developer is part of a dedicated team is wrong, because he or she has to split energy and attention between projects. It appears that the above-mentioned methodologies fail to see reality, and that the notion of dedicated teams is utopian. But there’s a difference between what we want to see and what’s just in front of us. Trying to automate tax collection, for example, Capgemini spent 200 million euros only to find itself in the severe condition of project failure.

The Reality of Multi-Teaming

The reality is that we’re required to work in a multi-project, multi-teaming environment – two current phenomena that work against the concept of dedicated teams. CEOs see the value of multi-teaming as greater efficiency; it’s a paradise for constant knowledge sharing and creates a space for cultivating skills and improving the quality of service. But the other side of the coin is how employees experience their responsibilities working in several teams and on different projects at the same time. For employees, multi-teaming creates a dynamic, fragmented, time-pressured, constantly changing, and ambiguous environment. By demanding that employees switch contexts and shift their thinking, project managers subject them to considerable stress.

What do project managers experience at the same time? The thought that “I’m lacking resources.” So while employees are multi-teaming, PM experts are losing visibility and wondering whether everybody is focusing on the right thing. Multi-project work then becomes a challenge for project professionals. And let’s not forget about CEOs, who simply want to know when their projects will be finished and are looking for salvation in modern tools.

Do the Tools Meet the Multi-Project Reality?

This is the most interesting part, as methodologies and tools that were supposed to cure PMs of planning headaches tend to have the opposite effect in multi-project environments. They are a direct route to chaos. Take a look at the negative effects of these commonly used tools:

Methodologies & Tools Solution Negative Effects
Agile (Jira, Redmine) Scrum of scrums Negotiation between scrum masters is extremely complex because of the constantly changing environment.
Waterfall (Primavera, MS Project) Gantt charts Prioritizes levels over projects (today project A, tomorrow project B); heavy maintenance (fill in all the possible parameters); shifting priorities in dynamic environments (replanning overhead); loss of visibility after leveling.
Critical Chain Project Management (Concerto, Exepron) Theory of constraints Levels within one project; stable constraint assumption; works only in a single project environment because a stable constraint does not exist in reality.

Table 1. PM methodologies, tools, and negative effects.

Again, Utopia. In reality, constraints and bottlenecks are changing all the time. All these project management systems work excellently in single-project environments, but when it comes to multi-teaming, their value is minimal.

 A Concept Born Out of Frustration

Albert Einstein used to say that you can’t solve a problem with the methodology that created the problem. You can complain, or you can decide to develop something else. Combining my experience with that of my colleagues, we decided to look at what was happening at the employee level. Not surprisingly, we found that when multi-teaming, teams eventually ended up overloaded because their workloads weren’t measured properly and they spent a lot of time on intuitive prioritization. In fact, intuitive prioritization is quite emotional, whereas prioritization should be objective. Could we do something to prevent our employees from overcommitting? Sure thing. We developed a new resource scheduling tool and three new assumptions:

  1. A multi-teaming environment
  2. Overloaded resources
  3. A lack of prioritization tactics

If you commit the capacity of four people to a workload for six, your output will suffer because of multi-tasking, disturbances, uncertainty, and so on ruining your productivity. Upon reducing the workload, you’ll actually increase your output. We’re trying to project what will happen in the future by looking from the employee’s point of view, and this approach works based on contemporary assumptions.

What about you? Are you still wearing those rose-tinted glasses?

Sources:

  1. WorldCargo. Betuwe Line – “third track” delay.
  2. The Register. One-third of Brit IT projects on track to fail (based on an Axelos report).
  3. Derk Stokmans. Geflopt ICT-project kostte Belastingdienst ruim 200 miljoen.
  4. Mark Mortensen and Heidi K. Gardner. The Overcommitted Organization.
  5. Joe Knight, Roger Thomas, and Brad Angus. The Dirty Little Secret of Project Management.
Jan Willem Tromp

Jan Willem Tromp

Jan Willem Tromp is a Dutch scientist with deep knowledge of project management based on more than 25 years of experience. He has contributed his research expertise to Epicflow, an online PM tool.

Leave a Reply