When some say we're doing agile project management, or "our software development method includes project management," ask the following to determine if you're actually doing project management
- A project charter has been developed - do we know what done looks like, why we're doing this project, and the everyone on the project shares this understanding in units of measure meaningful to their particular point of view?
- Requirements are collected and managed - can we capture in some form, what are the deliverables of the project? Along with all the annoying little requirements to make these bigger pieces appear to the stakeholders?
- The scope of work is defined and controlled - is there some process for bounding the scope of the project? This means keeping the scope changes within the ability of the team to respond and forecast what the cost and schedule impacts will be?
- A Work Breakdown Structure (WBS) has been created in the spirit of MIL-STD-881A - 881A is the Gold Standard for building a WBS. The core concept is the have Product Deliverables ONLY, no functional activities. Things like Design, Code, Test are NOT in the WBS.
- A schedule has been developed and its contents controlled - some form of a sequence of work needed to produce the deliverables. Remember the purpose of time. It keeps everything from happening at once.
- There are estimates for cost and schedule and these estimates are managed - some way to bound the final cost and delivery dates.
- Quality of the outcomes is planned and managed - a description before the work starts of what "good" looks like.
- There is a risk management process applied to the project - Risk Management is how adults manage projects. No risk management, no project management. Hope is the only strategy at that point.
- There is a communications processes applied to the project - keeping people in the loop is the glue that holds the project together.
- The stakeholder's expectations are managed - if the stakeholders don't agree what done looks like, then the project is lost before it starts.
- The project team is managed - you don't always have to be happy. But have to be willing to continue to work until you are done. Making the team happy is not the primary role of the project. That self actualization process is outside the project. But the team members need to work for the stakeholders in a productive manner.
- The project's performance is monitored and reported, and this information is used to control the project - velocity is of no value if you don't know the distance.Earned Value is a core process in many domains. Velocity is not the same. It's close. It's useful. But it's not the same as Earned Value, not matter how many times someone in the agile community says it is.
- The project is closed out - getting people off the payroll is part of close out. They can move to the next project or to support. But projects have finite ends.
The terms "control" and "manage" can be defined to meet the needs of the reader. For agilest these are terms that elicit knee jerk reactions. But in someway, somehow, the project needs management and control - pick your poison.
If your project does not "do" all of these items in some recognizable way - then you're not managing the project, the project is managing you.
