Approximately a week ago, I was speaking with some senior execs at another technology company about some potential Project Management opportunities and where CaseySoftware could assist in their efforts. Throughout the discussion, they asked the standard questions about company history, previous and current projects, etc. After talking for a bit, we got down to business and I was asked point blank: “What's your Project Management style?”
While I believe that there are techniques and practices that apply in all cases, I believe that solid project management must be customized to the specific team. That may ruffle some feathers, but let me talk about the common aspects before I defend that assertion. According to numerous sources – Peopleware, Rapid Development, and Mythical Man Month to name a few – the vast majority of projects fail due to just a few reasons. These serve as a hit list to be addressed by all project managers.
First, requirements are an entire issue unto themselves. They change, are wrong, are incomplete, no longer applicable, are added, and a variety of other things. They must be monitored, controlled, and carefully tracked throughout the entire process. This doesn't mean that requirements changes should be set in stone at the beginning of the project – after all, they could be wrong. It means that every requirement must be evaluated to determine impact to the schedule, importance to the customer, and dependencies. As I've covered elsewhere, I use a simple 1-10 scale to represent both priority and impact on the project.
I have been involved with projects where fully 30% of the original requirements were deemed to be completely incorrect and another 20% were not complete at the outset of the project. Architectural decisions, user interface design, and a variety of other aspects were impacted by this bad information. It caused the initial release of the project to be one of those dreaded “It's exactly what I asked for, but not what I wanted” scenarios that I have mentioned before.
Next, estimates and project plans must be accurately created. This is a skill that can only be learned through experience with similar areas and can't be learned from a book. This means that you'll completely screw it up a few times, but you'll get it right once in a while too. Don't be afraid to make mistakes, but always be sure to track your actuals vs your estimates and which process you used. You should eventually be able to say that your estimates are -5%/+12% (meaning that your estimates fall within 12% under and 5% over actual).
On a recent project in which I was serving exclusively in a PM role, the project team admitted that they gave the client an estimate on cost and timeline without actually evaluating the project. They simply told the client his original ceiling on price and deadline. It's the equivalent of planning a trip from New York to Los Angeles and simply saying “drive west”. It gives direction and goal without describing a route or level of effort.
Finally, the effort must be tracked throughout the project. Ideally this would be done by team members meeting together on a regular basis, preferably once a week, but for larger projects this may not work. In addition, these meetings cannot simply sessions where everyone ponders gnawing off their arms to get on with their day. You must engage people and foster a place for open discussion were problems can be shared and discussed. Odds are someone else in the project has a different perspective and information from a similar situation. You must connect these people.
On one project for a government client, there were twelve different organizations involved. Status meetings entailed anywhere from one to four representatives from each organization, some political maneuvering, and constant gossip. Sharing information meant putting your organization's role – and potentially your job – at risk. Prevent this from happening at all costs.
Due to the unexpected length of this, I'll cover the remaining tomorrow. Thanks for reading.