Why is it called "agile" project management? Could it be called "agile project" management. This is the endless discussion, that has no resolution. Or at least no resolution that has any value.
So what's next? How about a simple approach to putting agility back into conventional project management? There are two fundamental elements of projects and the management of projects:
- Activities - the effort of people, machines, systems, business and any other "resource" working on the project. Activities like: tasks, process steps, processes themselves, actions on the action items list.
- Outcomes - the results of these activities. The "thing" delivered as a result of the activities. Things like: deliverables, features, products, services, work packages, control accounts, WBS elements.
When activities and outcomes get mixed up, the project usually suffers. While the conventional project management methods don't explicitly state "let's mix these two things up and screw up the project," there is no specific, explicit guidance on how to separate them in places like PMBOK. Now this is not PMBOK's fault. Far from it. PMBOK is "A" guide to the Project Management Body of Knowledge. It is not "THE" guide, nor "THE" Body of Knowledge, nor even a very good approach to the processes of managing a project. This is as it shoudl be. Since project management is a set of process that must rapidly adapt to an emerging set of circumstances, putting such advice down in a book that takes several years to get to the next edition is pretty much a waste of time.
But back to the problem. I am convinced that those looking in from the outside, those not well practiced in the art and science of project management, and generally those that confuse managing projects with building software don't understand the separation between ACTIVITIES and OUTCOMES.
This is where "agile" comes in. Agile Software Development Methods - stuff like Scrum, XP, Crystal, DSDM - all are focused on Outcomes. Delivering value to the stakeholders on some periodic basis. Forgetting for the moment that the units of measure of value are not defined by these folks, the other parts make sense in terms of "outcomes."
In some agile software development process, the activities are well defined. Well sorta well defined. But in many many conventional projects - projects that keep us busy doing the "project recovery" work, these activities are not very well defined. Poorly defined actually in many cases.
So what's the real problem in project management.
- Following processes that are hard to follow means you don't follow them
- Not focusing on outcomes means you don't know what done looks like, how fast you're getting there, and what time you're going to arrive and how much it will cost when you arrive
Now some people have figured out how to combine Outcomes with Activities and now calling it Agile. IMP/IMS is one of those. But IMP/IMS is not directly applicable to all projects. It could be, but first you have to get over the notion that the US DoD is the source of IMP/IMS. Then the notion of "deliverables based planning," "assessment of increasing maturity of the product or service," and the measure of physical percent complete in some units meaningful to the stakeholders - dollars is a good measure.
So what comes first. Well in the IMP/IMS world Outcomes come first. Only then can you define the activities needed to provide those outcomes. This is call Planning. A Plan is the Strategy for the successful completion of the project. Next comes the Schedule. This is the list of activities, their durations and order; necessary to produce the Outcomes.
It's that simple.
- Tell what you are going to do - Outcomes
- Tell how you are going to do it - Activities
and add
- Tell how you are going to measure that physical progress is being made.
When we speak of agile, agile starts with the Outcomes. Just like the Covey book says - start with the end in mind. Start with the outcomes. They don't emerge (for the most part), they don't appear by using "magic beans," they don't change too often. What does change are the activities, the sequence of activities, the duration of those activities - along the way to DONE. DONE is the ultimate OUTCOME.
