Project Management Blog

There is an old saying in software development about how the only bug free line of code is the one you don't write. While this may sound pessimistic, the motivation is to curb a developer's urge to over engineer a solution. When it comes to Project Management, do we have a corollary to this wisdom?

I believe we do, and it is this: The unnecessary meeting that is cancelled retains productivity. (Or at least, it has the potential whereas the meeting would have certainly doomed the group to wasting an hour)

Meetings are a necessary evil. This is so because good software requires communication between developers and stake holders, but meetings should ultimately be seen as overhead. If five people are in a meeting for an hour, this represents five person-hours not spent on features or fixing bugs. Scott Berkun, in The Art of Project Management, goes a bit further and warns against recurring meetings, which often outlive their usefulness.

There are several ways for a Project Manager to keep developers out of meetings:

• Sit down with developers and stake holders separately and confirm if all expectations are met. A five minute discussion with both parties separately may save everyone from a longer project review session.
• Start eliminating recurring meetings, or convert them to opt-in meetings, decided by the Project Manager
• Structure the order of events in a meeting so that some persons may leave early. Don't make developers suffer through a budget discussion if all they need to do their job is clarification on the software requirements.

Before you get too slash-happy, do keep in mind that effective meetings can add value. A Project Manager should enable developers to produce software. If the meeting doesn't serve this goal, adopt some meeting elimination tips from this article.

This weekend, I picked up my issue of the IEEE Spectrum which they've devoted to software failures and started reading the fascinating article: Who Killed the Virtual Case File? It details the FBI's failed Virtual Case File System from its start to its mind-numbing $170M collapse into a steaming pile of unusable code, 800 pages of recommendations, and quite a few destroyed careers. It's absolutely stunning with respect to poor project management, so I'm going to focus on this article for a couple days to lay out where some of their biggest mistakes were and potential ways the risks could have been mitigated.

About halfway through the article, this quote floored me:
Mueller blamed himself for the delay, because he'd asked for an accelerated schedule. But Higgins blamed Mueller's staff for not being straight with him about his agency's ability to deliver what he wanted.

"Did somebody come to you and say, okay, Mr. Director, sir, you can have it sooner, but it's going to cost you this much more money or you're going to have to do without something?" Higgins remembered asking Mueller. "And he said, 'No, nobody ever told me that.' And I said, 'Well, lesson No. 1: faster, cheaper, better. Pick two, but you can't have all three.'

Wow.

Yesterday, I offered some points about What Project Management is Not and I promised to tell you what Project Management Is... and away we go:

Project Management is a seatbelt.

Just like a seatbelt, a good set of Project Management practices and a good plan won't do much if you're caught in a catastrophic situation. For the minor fender-benders and even bigger problems, it will definitely assist, and potentially provide some safety measures and even an escape route or two.

Project Management is a sign of something more.

Going back to the seatbelt analogy, if you put on your seatbelt as soon as you get in the car, I *believe* (no quantitative data to back this up) that you are more likely to be a safer driver. If you habitually perform good project management practices, you will be more likely to detect problems early and have a response plan in place.

Project Management is required.

For any project that involves more than a few hours of effort, some sort of planning is needed. The planning required is directly proportional to the size of the project. If the project consists of writing a new report this afternoon, the "planning" might be 5-10 minutes to think about it. If the project is version of your system, the planning will involve more people and more time. If the project is a $170M system for a major government agency, the planning will involve representatives from numerous meeting repeatedly throughout the lifecycle of the project.

Project Management is about sharing information.

Personally, I don't care if you use a text file sitting out on a shared drive somewhere. There are better tools available, but the point of all of them boils down to making information available to the required people at the required time. It doesn't matter how great your tools are if the decision makers can't get at the information they need.

Project Management is purposeful.

At some point in every project, a decision will have to be made that others are not going to like. In order to have credibility for cutting features, requesting more resources (time, money, people, etc), or pushing back against requirements, the information needs to be available to state unequivicolly "If we do/don't do X, the project is going to suffer in area Y."

Project Management is ongoing.

von Moltke's dictum says that "No battle plan survives first contact with the enemy." Having a project plan a the beginning of the project is a first step, but it's not the last. Regular evaluation, adjustment, and sometimes even retreat is necessary.

I know that last point is a repeat from yesterday, but it bears repeating. Just because you have a pretty Gantt, PERT, or Critical Path diagram on the wall means precisely nothing. As soon as the project begins, there should an evaluation of your Estimates vs your Actuals. Maybe your estimation technique was off, maybe a supporting vendor moved faster/slower than you expected, or maybe a new product is replacing some of the planned work.

If you're not regularly reevaluating the plan, you're not managing... you're coasting.

Project Management is Not a Silver Bullet.

Project Management will not ensure success. It will not make you finish the project early, to spec, under cost, and appease all your customers. Sure, all these things can happen, but Project Management tools, practices, etc, etc only allow these possibilities, they do not guarantee them.

Project Management is Not an afterthought.

If your project is out of control in terms of scope, time, money, or all three, it may already be too late. If you where flying off the road into the nearest tree, would you say "Hmmm... I think I need a steering wheel." Why is the control of your project treated the same way?

Project Management is Not optional.

I use dotProject for everything ranging from my major clients to simple upgrade tasks on CaseySoftware, CodeSnipers, and here. Excessive? Maybe. Does anything get left out? Not a chance.

Project Management is Not about tools or pretty drawings.

As a core contributor to dotProject, I have a personal and even financial interest in everyone using it, loving it, and naming their kids Gantt and Critical Path. But I don't care what you use, but use something. An Excel spreadsheet would be a step up for many people.

Project Management is Not a random process.

Project Management is about planning. It's about knowing the status of tasks. It's about taking measured risks and having plans to mitigate those. It's about looking at the cold hard facts of the project and sometimes having to say "We're not going to make it."

Project Management is Not a one-time action.

von Moltke's dictum says that "No battle plan survives first contact with the enemy." Having a project plan a the beginning of the project is a first step, but it's not the last. Regular evaluation, adjustment, and sometimes even retreat is necessary.

I know, this sounded harsh, but I'm trying to make a point. I have worked with and for many companies who say "This time it will be different! We have a Project Plan!" like it means something. Well, let me tell you something: It doesn't.

Tomorrow I'll get into talking about what Project Management actually is and why you need it.