The Battle For Control of Project

The concept of management by projects is a non-starter. The average company is not a project-driven company, and likely never will be. So why is this an idea that continues to be so prevalent? What problems — real or perceived — do it's proponents hope to address? And if the project-driven organization cannot exist, what business model will surface that will reasonably address these problems? This series takes an in depth look at these questions, and offers insightful and reasoned answers.

In a previous post, we explored the challenges that currently exist in finding an appropriate home for the project management function. In this post, we take that discussion one logical step further, in an attempt to understand just why there is such a conflict between factions over where the project management function belongs, and who does or should retain ownership over it.

For many organizations, particularly where project management is part of a centralized support department like information technology, the battle lines are very clearly and overtly drawn around the issue of control. Enormous turf battles are waged over who controls the projects, as well as who ‘own's the project managers and can therefore direct their activities. I have seen customer business units actually hire their own project managers and provide salary allocations to the IT department, solely so that they can ensure focus and full time attention to their projects.

As with so many inexplicable organizational behaviors, the first question that we need to ask in understanding this situation is ‘why?' What has led the organization to such a high level of dysfunction that managers and executives believe they must control the project manager in order to control the project results? Why do otherwise rational and sane individuals believe they need to engage in such extreme political behaviors? And what of the poor project manager stuck in the middle?

Where project management has become established in non-traditional industries such as information technology, the initial driver was very much to create control over the project outcomes. New systems were late, over budget and often just plain wrong. Changes were a normal part of the business landscape, and accepted without question or consequence. Risks abounded, and were reacted to as they arose as best the team could. And everyone thought that there must be a better way.

Project management introduced a greater degree of certainty around project outcomes. There was a better understanding of what was required, and the activities and estimates required to deliver the project results. Change management provided a means of defining and understanding the consequences of absorbing change, and risk management allowed for a more proactive means of managing project uncertainties. Project were still often late or over budget, however. Worse, customers were in many cases less satisfied with the results of the project and with the team that delivered it because a bureaucratic wall had been introduced between themselves and the project.

And so the stage was set for conflict. The IT organization wanted more definition, greater rigor, additional sign-offs and better documentation in order to continue to gain control over the project. The customer wanted closer access to the project teams, more flexibility and responsiveness to their needs, and had no desire to go back for more funding every time they identified an additional requirement for the project. Overarching all of this are mounting pressures from senior management to manage budgets, maintain delivery targets and -increasingly – demonstrate that the promised business case and project benefits are actually being realized.

What is important to recognize here is that the desire for control is, fundamentally, a knee jerk reaction. There is no nuance of understanding behind it, nor is there an appreciation of what greater control would provide. In fact, while each side grasps for control they aren't even trying to control the same things. The emphasis of the IT organization is on trying to optimize the efficiency and reliability of delivery. The customer's focus is primarily on ensuring the relevance and value of the business outcomes, and that the project is able to respond quickly to changes of understanding, new market pressures or emerging opportunities.

This drive for control is unfortunate, as regardless of who wins the turf war, projects will not and cannot improve while the issues are defined in these terms. The primary problem is not who controls the project, but how the project is approached overall. In traditional project environments where the requirements and design criteria can be fully and completely defined up front, it is perfectly appropriate and in fact necessary to strictly manage projects to much more narrowly defined targets and constraints. Where the requirements and even the results of the project are uncertain, it is impossible to rigidly define the process, budget and schedule that will be followed. Yet while customers demand flexibility and responsiveness, in all too many cases the project managers and their departments are being rigorously held to budgets and schedules that were defined too early with too little information.

What is needed, therefore, is a different way of approaching projects. We need a way of managing project that allows the service organizations like IT to ensure adherence to processes and guidelines, and allows them to ensure that the actual solutions are consistent with existing standards and approaches. We need a way of responding to shifting customer needs and expectations. We need a way of ensuring organizational budgets and constraints are managed, and that there is full disclosure and understanding of project progress and success. We need a new way of thinking about projects that walks path between all of these points. But arm-wrestling for control is not the answer.

We don't have to constantly be stuck in this cycle of competition and conflict. That we are is in many cases a product of “that's the way we we've always done things around here” combined with a management system that values fiefdoms and individual political agendas over what is appropriate for the organization. To break this cycle first requires a change in how the organization thinks about its projects – what they are, why they exist, and what the expectations of them should be. By consciously shifting our reference point away from the project and towards the organization's needs we are also able to change our actions and behaviors.