Why Project Managers Can't Manage Projects

Years ago, I worked on a project intending to build a financial management system using tiny message switching computers. One of the engineers assigned to reach this doomed destination confided to me that in theory the concept could work. “It’s like pulling a stagecoach with chickens, though,” he concluded. “You can do it, but the reins management will kill you.”

The reins management ended up killing the effort.

In theory, though, the concept was brilliant. We could add power by just harnessing up another chicken. Goodbye mainframe!

Modern server farms have figured out the reins management at levels of complexity our project could only dread. They’ve worked out some protocols we didn’t have. They employ some hardware we could only dream about. Somehow, the whole thing works. Even though some percentage of the individual computing units are broken at any point in time, the whole machine keeps crunching away in eternal conversation.

Marvelous!

I concluded from that early experience that projects are unmanagable. The chickens are always in charge. This observation led me to reject most of the techniques commonly embraced to control projects. Not only do they not work, they quite provably couldn’t work.

My early insight has had little influence on the now burgeoning industry cranking out project pseudo-control mechanisms. Nor has it dissuaded many from buying any placebo.

Yet we see strong evidence that project managers can’t manage projects. It’s clear from the front page of any newspaper. Companies continue to hire project managers, anyway, and project managers disappoint their employers with such regularity that dissatisfaction is expected. Project managers and their employers seem to be hardwired to do the same things and expect different results, even though the reins management seems to be killing them.

The reason why project managers can’t manage projects is answered by an under-respected law called Ashby’s Law of Requisite Variety. Ross Ashby, a scientist who worked in the little-understood control theory field, concluded that control depends upon the controller having at least as much “variety” as the system he tries to control. Variety is one of those scientific terms with a very specific meaning, but let’s distill the convoluted definition down to say that the controller has to have enough hands to hold onto the reins.

All complex systems have more reins than their controllers have hands to hold those reins. Everyone’s familiar with trying to herd cats or control teenagers. Three strategies for dealing with this deficit have evolved through generations of practice.

The first strategy dumbs down the system—allowing no more reins than the limited number of hands. This approach can leave many chickens uncontrolled or take away so many chickens that the remaining birds can no longer pull the coach. Alternatively, it can require so many people to hold reins that the chickens can no longer pull the stage or shrink the stagecoach to where it can no longer carry anyone to hold the reins. If you’re stuck on pulling a stage with chickens, this strategy doesn’t really help much.

The second strategy calls for training the chickens so that they don’t need anyone controlling their reins. Chickens are relatively easy to train, and this strategy doesn’t seem completely absurd on the face of it, at least until the sponsor comes sniffing around wondering why the stagecoach isn’t moving yet. This strategy can transform the effort into more training than stagecoaching.

The third strategy entails accepting the unmanagability of the situation. This strategy doesn’t look very much like managing, and is, in my experience, the least acceptable of the three.

Yet it is the only workable strategy among them.

Who Controls the Controller?

We approached that system development project as if it were a system development project, when it was actually two systems developing each other. The chickens were in charge most of the time because we believed that we were always in charge. We’d initiate some grand plan and follow it, surprised when the fates denied us success. And it seemed to us as though we were just unlucky rather than unenlightened. We’d plan, track, and control only to find the effort out of control again and again.

Our strategy for resolving every roadblock was to do even more of the same stuff that wasn’t working. Eventually, the chickens prevailed and the project was canceled.

We might have succeeded, I reflected later, had we been more adaptable. Had we accepted that, because they could generate more variety than we could ever produce, the chickens were in charge, we might have learned from them how to succeed on something other than our terms. But this seemed bass-ackwards. After all, I was the project manager. My staff and I were supposed to be in charge of controlling the project.

Yet we could not be.

Had we copped to our fundamental inability, we might have managed to succeed. But we couldn’t talk about that. We’d been chartered, just as generations of project managers before us and a generation of them since were chartered, to manage the project. Not to be managed by it.

There’s a circularity about control. A give and take. Even a relatively simple controller, like a thermostat, relies upon feedback to determine its commands. In my house, there are several people with different ideas about how to control the thermostat. I like to turn the danged thing off when I go to bed, but my wife likes to leave it on. One of us invariably decides to turn the temperature setting up or down, hoping to violate the second law of thermodynamics by speeding up the process of heating or cooling the house. Our control of the controller complicates its job. Left alone to sense the temperature, it’s capable of maintaining a steady temperature without ignoring the second law of thermodynamics. It listens and it responds.

The thermostat doesn’t know that the granddaughter has left the back door open again. Or that I want it colder than my wife wants it. Given clear intentions and steady feedback, it manages fine. Given all of the variety it was never designed to sense, it fails frequently.

Any of this sound familiar?

Projects As Conversations

The chickens are always in charge because they can generate more variety than any single controller. The chickens cannot be trained to operate autonomously from the controller without some unrealistically detailed foreseeing, training, and choreography beforehand. We can find resolution for this eternal dilemma in conversation, and the recognition that everyone, both the chickens and the poor fool tapped to handle the reins, have important things to say about the stagecoach.

When it comes to managing complex systems, the most we can say is that no one knows and everyone could be learning. Whether they learn or not seems to depend upon everyone more fully acknowledging that they don’t yet know. Control emerges not from the driver or the chickens. Control, if it is to be achieved, will appear in the space between the system and its so-called controller. In the relationship. In the moments of recognition and insight.

Feed this space between with conversation or starve it with all you cannot say. Control of any complex system looks so different than the commanding control of a simple system, that those only experienced with simple controls—planning, tracking, etc—look right through their real point of leverage. And we’ve all been altogether too well trained on simple controls. So well trained that we instinctively shrink from our real points of leverage and label them too chaotic to consider.

Projects are conversations. Not scripted performances. Their purpose shifts, depending upon the meanings we make in conversation and the significances we acknowledge between us. When we can speak our truth—what’s true for us—without insisting that it be true for others, and when we can hear another’s truth without insisting that it must agree with ours, we are having a conversation. It’s not a conversation and it’s really not control unless we are prepared to be changed by whatever we hear. Ask the thermostat.

The reason project managers can’t manage projects is because projects are unmanagable. The project manager’s responsibilities, as written, describe a fool’s mission. Provably unachievable.

The few who succeed resolve this eternal dilemma by more fully acknowledging it. They accept that, while their project is unmanagable, it might be capable of controlling itself. Not, however, by management command and pseudo control, but through conversation. I believe that most every project is capable of learning how to control itself, and that every element, every contributor, has something to provide to that conversation. Even, especially, the chickens.

The project managers who can’t create successful results don’t acknowledge that their projects are unmanagable. This acknowledgement could take them out of the driver’s seat and open the possibility for surprising, even delightful results. The alternative seems to be a stagecoach that eternally intends to, but rarely actually does, arrive on time, on budget, and on spec.

Blame it on the damned chickens!

©2006 by David A. Schmaltz all rights reserved


blog comments powered by Disqus