There is lots of verbiage flying around about what is a "good project management process?" Is it agile? Is it structured? Stage gates? Incremental? Spiral? Massively parallel? Theory of Consttaints? Toyota's latest super secret process?
When the term "agile project management" is mentioned, the first thing I ask is...
"Tell me what is different about this method and why does this difference matter to me?"
I have my own personal answers but here's a set of answers that can be applied to nearly every style of project management - agile or not.
Things That Matter in a Project
- Managing the schedule matters the most. There is no way costs can be controlled if the schedule is not under control. In nearly project on the planet, the passage of time means money of being spent. The longer the project takes, the more money it costs.
- Measuring earned value (in some way) provides an early warning that the project is in trouble. Simple tools can be built to measure the "value" delivered for the investment.
- In a business systems project, the development and use of new technologies should be avoided. Avoid overselling a technological solution to a business problem. Find the business solution first.
- Apply a systems engineering approach. The discipline of systems engineering provides important processes:
- Interface control - systems engineering is all about defining, managing and controlling interfaces.
- Resource allocation and tracking is a systems engineering discipline. How much something costs, what skills are needed to deliver it, and how technical success will be measured are all activities of systems engineering
- Make traded studies are way of doing business. Build an analysis process that isolates risk and verifies decisions. Don't analyze to death, but analyze enough to choose.
- Risk management is how adults manage projects. Make risk management an embedded activity. Know the top 10 or so risks. Know the planned mitigations. Know how and when these mitigations will be invoked. Install a risk tracking system - even if it is a simple spread sheet. Report risks in the status review. Buy down risk with testing, verification, alternative designs.
- Ask peers to review the work. Engineer to engineer reviews are the best way to spot design and architecural problems. Hold the formal standup reviews for later, when everything is working. Anyone reviewing a design or deliverable must be a practicing engineer (or developer) in the discipline being reviewed.
- Make timely decisions. This is essential to avoid any loss of momentum in the project. Once lost it is nearly impossible to regain. Working harder does not help. Only deliverables can be used to measure "momentum."
Things That Don't Matter in a Project
- Performance reports and the accompanying measures that are too detailed and overly-accurate. No matter how nice the ERP system is at delivering fine grained information about the project, this information does not actually fix problems.
- Having a meeting without a purpose. If all the attendees cannot state why they are in the meeting and what value they are going to try to deliver to the participates, kindly ask them to leave. This sounds very harsh, but it does amazing things to groups - it focuses their attention on the task at hand. Have the meeting, make the decision, and get back to productive work.
- Compliance with formal quality and process improvement standards. Any audit based improvement process rarely works and simply causes grief for all involved.
Why are the Thing that Matter Important?
There are numerous (too numerous) silver bullet solutions to project management problems. Start with the basics. Fix the problem in the absence of a tool or a canned solution, or even a canned philiosphy like "agile." If the problem can't be fixed in this way, look for the next solution in a new and possibly unique method. But if you haven't walked all the paths to the current problem, then you're going to miss the easy fixes and replace them with a fancy and complicated "solution" that is looking for a problem to solve.
