The Disempowered Project Manager

Soliant is in the business of building software for external clients. This means we work with a wide variety of organizations, and people within them. One of the things we’ve noticed over the years as a significant contributor to project success is simply this:

The more directly you work with the decision-makers, the more smoothly the project is likely to go.

By decision-makers, I mean the people empowered to decide three things:

1. What the software should do.
2. How much they are willing to spend on it.
3. In what timeframe they are willing to accept it.

When managing a software project, it’s essential to get clear information on all of these points. It also helps immensely if the client has leeway in how they allocate value across these variables. Project management, as we all know, involves trading these three value points against each other. A project manager can suggest tradeoffs, but only an informed and empowered client can accept them. Therefore an informed and empowered client is a key ingredient of project success.

Finding the Ideal Client

Unfortunately, one doesn’t always find this client so easily. Here’s a typical scenario with the ingredients of some trouble.

Hesperox Worldwide’s Creative Services business unit needs a new way to communicate with customers. They have some web-based software in mind, and they’d like it pretty soon. CS is led by Hazel Kearney, who likes to work at a high level, get things done quickly, and leave implementation details to her subordinates. CS is also full of a lot of bright, but contentious people. They often compete with one another for Hazel’s approval, and Hazel doesn’t do as much as she could to discourage this.

Starting the Project

After one staff meeting in which dissatisfaction with the current client site was widespread, Hazel makes a decision. CS is going to build a new client site. She settles on a budget of $80,000 and a timeline of six months because it just seems like it shouldn’t take longer or cost more for a relatively straightforward tool.

Now, how to organize the project? It will need a project manager, ideally someone with some web experience. Hazel doesn’t want to devote an extremely senior PM to what’s sort of a “utility” project, so eventually, she settles on Sami Shorwa. He’s relatively junior and somewhat new to the group. He has worked on websites in the past, and this would be a great project on which he could prove himself and get his sea legs in the department. Hazel likes to get things done, so she picks up the phone, calls Sami, and informs him of his new commission, timeline, and budget. She urges him to contact the key people in the department to get more details about requirements and suggests he get busy finding a vendor.

Building Requirements

Well, Sami does his best. He has some background as a business analyst, so he gathers some requirements. Quite a number, actually: it seems everyone has ideas about what the site should do. Some of them openly conflict with each other. Marshall thinks the site needs to have very strict security, with users unable to view resources unless an administrator specifically permits them. Shari thinks the site needs to emphasize openness, with users having broad privileges by default. Marshall and Shari are both senior to Sami, so he’s not sure what to do. A number of such examples crop up.

Vendor Selection

Sami also works diligently at vendor selection. Unsure how to resolve the requirements conflicts, he simply includes all the requirements in the RFP, in the hopes that the vendor can help sort it out. The responses aren’t terribly encouraging. Three vendors give estimates in excess of $200,000. Two more point out various intractable conflicts in the requirements and suggest Hesperox work them out. A sixth vendor gives an estimate of $75,000 but after seeing the other responses, Sami isn’t sure he believes this.

Addressing Concerns

Sami goes to Hazel and explains the problem. The team has come up with too many requirements, and they conflict. Firstly, they need a process to resolve identified conflicts. Secondly, a decision is needed about whether it makes sense to increase the budget or timeline. The fact that these issues tumble out in the passive voice is a sign of Sami’s dilemma.

“Sami,” says Hazel, in a clear, patient voice that says clearly that she doesn’t like the direction this is headed, “I’ve set a timeline and budget for you. Working all these other issues out is what I pay project managers for.”

Failing Through Disempowerment

Sami feels he doesn’t have much choice but to accept the $75,000 estimate, given Hazel’s rebuff. Those of you who’ve worked on software projects can predict how things will go from there. We will politely avert our eyes.

Sami’s problem should be clear: he is not, by virtue of his position, empowered to make essential decisions about how the project’s priorities should be managed. His boss, who is so empowered, views these issues as “project management problems,” which Sami ought to be able to solve.

Successful Project Management in Software Development

When developing software, make sure everyone on the project knows who can make the fundamental tradeoffs between features, time, and money. Look out for the really unfortunate soul known as the disempowered project manager: a middle-tier person responsible for delivering the project, but has not been vested with the authority to make the fundamental business tradeoffs. And if you are that person, be prepared to stand up and point out the gap. You might approach it like this:

“Hazel, you brought me on as a boat captain. And as a captain, I have wide leeway in how I plot a course, how I steer the ship, and what actions I take to protect the crew. I’ve signed up for all of that. But what I can’t do is decide what the boat should carry. I can’t decide what the profit margin on the voyage should be. And I can’t decide for you whether it’s better to arrive late with the whole cargo intact or jettison some cargo in order to make speed and arrive on time. I can tell you about your choices — in fact, I’m obligated to. But in the end, it’s you who has to actually make the decisions.”

Disempowerment seriously threatens project health. However, with these reflections, you can prepare yourself to spot and address the issue before allowing for too much damage.