One approach to Agile Project Management is to declare a new paradigm, "in with the new out with the old," quote Thomas Kuhn, demand we "burn" our previous project guides, abandon generally accepted accounting principles, etc. etc. etc.
Now doubt there is merit in any significant improvement to practices that have failed in the past. And certainly there are massive project management failures that are the basis of change At the same time are we missing something in the conversation?
I'm working this Saturday morning, like many Saturday mornings for the past month on a proposal team for what will probably be the second or third largest development project in the last 25 years. Not counting the BIG DIG, which is not really a single project but a portfolio of projects, much like the Chunnal. Our baseline is the Joint Strike Fighter, so we like to see the world through cleanly designed and rigorously controlled specifications.
The point here is that the processes used to write the proposal - make iterative estimates, turn the design many times before committing to a "point of departure," incrementally developing a Master Plan and Schedule, assure continuous feedback from all participants, or "only what is needed to win," and all the other "win strategies" I been trained to do and practice everyday as one of the IMP/IMS architects - are straight out the play book for Agile Project Management.
But a further look at our work products reveals that standard PMI processes are in place as well.
- "Initiate the project" with formal kick offs, daily stand ups to re-initiate the project every day. Feedback and communication are critical on a proposal team, since the date of delivery is fixed, the participants come from other areas and have to go back when they are done, and the requirements start out as vague and confusing.
- "Plan the project," using every conceivable planning trick in the book - mostly visual, but check lists, rolling wave Gantt's, detailed sequences of events, routing boxes for everything from artwork to change controls
- "Control the project," using daily meetings, big visible progress charts, ruthless adherence to schedule, especially for artwork, a very formal decomposition of the effort, as if (and it actually is) a Hollywood movie story board approach.
- "Execute the project," by deliverying everyday on the commitments made in the morning meeting
- "Close the project" by shipping the winning proposal that contains the right price, the right technical solution on the winning management team
This last item is critical to a proposal project and in fact to any project - "do we have the winning management team?"
This process which seems very structured, planned to the smallest detail is actually "chaos" in the proper description of self emerging. The winning proposal "emerges" from this chaos through the efforts of the Proposal Manager. The Proposal Manager is the Project Manager of the proposal. He's not the Program Manager for the execution - there's one of those, the finance manager, the IMP/IMS manager (I'm one of those) or any of the technical manager (there are several dozen of those).
The process of producing the proposal must flow over into executing the program as well. A well produced proposal is likely to represent a well executed program - at least at first assessment.
In the end all the formality is blended with massive amounts of agility on the part of the proposal team. Without this agility the 45 day "drop dead" schedule will never be met.
But the critical success factor is a core of simple, clear and concise processes derived from very traditional management techniques. "Plan the work, work the plan," "don't do anything that doesn't add value to the result," "meet every commitment you make," "divide and conquer by partitioning the work into massively parallel efforts," "look everyone in the eye every hour of the day to confirm you and they are in agreement as to the result and when it will be ready."
When the agile project management pundits state we have a "new paradigm" they need to sit in for a "day in the life" on a few projects around here and see that Project Management as a profession (not necessarily PM for software BTW) has been doing all the things they call new, since the early days of aerospace.
