Project Politics

One of my technical leads has just walked into my office, excited about a new idea he has for transforming a customer problem into a development project. His plan certainly addresses a need; the project has huge implications for improving the flow of vital information throughout the organization. The project would help automate several processes that are currently duplicated and even triplicated.

But there are some hard realities to consider. To do the project "right" would mean addressing all areas at the same time and finding a common architecture that supports all areas. We know that the project’s functions, while critical to some areas, have limited priority to other areas. And in order to get financing to develop the system at all, we will have to present our case carefully (typical of working for a state organization where the taxpayers, via legislators, hold you accountable for every penny).

My technical lead looks a little deflated. He knows what I say is true, even though he wants me to be wrong—a good idea should, in an ideal world, stand on its own merits with or without a public relations plan. But we accept reality and strategize the best way to make sure we get to work on the project. We identify which business areas are likely to champion the effort. Some areas are financed with grants; other areas have internal budgets; the more development monies we can allocate to budgets funded by grants, the more likely we are to get permission to move forward. We talk about strategies to get their support when we ask for the resources the project will require.

My lead is learning for the first time the politics of software development. He is already a keen developer. The quality of his software far exceeds that of most development efforts in the organization. I admire his commitment to "doing the job right." Now I am showing him another way to "do the job right." I am teaching him about the varied perspectives that I as software project manager must juggle when starting a new project. Each perspective brings a slightly different view of what it means to be successful. Slowly, I am helping him develop as a software project manager—even though we both hate this compromise that software developers must all too often make.

With all this in mind, I send him back to his office to draft a plan for selling his project.

I had learned these lessons some time ago. I discovered early as a software developer that my personal ideas about creating software had little or no impact on the decision-makers.

I needed software tools. "Maybe next quarter." I needed training. "No money left in the budget." I didn't have enough people to do the job. "I'm sure you'll make it work...And oh, by the way, did I tell you we're shipping that software next month?"

Then, I moved into software management. I started working with Marketing and with customers. For the first time, I actually heard those promises Marketing made in order to cinch a deal! My developers had no idea how to make it happen, but yes, we would still deliver it in six months. This was only mildly palatable to me, and only because I saw firsthand the frustration the customers felt when the new software lacked the features they hoped to get.

Later, I moved to the Marketing department. As soon as I had settled into my new office, I caught myself making the same pie-in-the-sky promises!

So what changed? Had I sunk to the depths of pond scum when I