There has been some discussion of late about agile project management and its relationship (or not) to tradition project management. Some have mentioned PMBOK as the way to "NOT" manager projects, others have even mentioned that agile projects may not even be projects but might be operations.
But now's a good time to review what makes a good project independent of any method - and I mean ANY method agile or not.
- Unambiguous measures of progress
- Mission focused
- Requirements derived from business capability needs
- Integrated Product and Process Development (IPPD) processes
- Interface control driven architecture (not user interfaces but system component interfaces)
- Design configuration freeze must deal with customer needs not process needs
- Continuous feedback paths from multiple business cycles - day, week, month, quarter, event
- Event based planning that exposes the accomplshments and criteria of increasing maturity
- Risk tolerant execution planning processes that can deal with the four kinds of uncertainty
- Program and technical performance measures that provide tangible indicators of reaching the end
Many of these are probably meaningless at this point. Some are code words for other more extensive processes - Event Based Planning - for example. Capability Based Requirements is another. The topics above will make a great outline for a book length paper titled "Successfully Managing Projects Independent of the PM Method"
The reason I say this, is these attributes - and maybe some more - are actually found on successful projects. Projects I've managed, projects I've watched being managed, projects I know about and projects I've read about. Projects that range in size from a few people for a few months to 1000's of people for decades. All have something in common with these attributes.
But all these attributes are not equal in importance. The highest importance depends on what came before. For example:
If I have good requirements and a good customer, then unambiguous measures of progress is important.
Defining requirements in terms of capabilities needed by the customer is the most important, because without that you have no project by which to have unambiguous measures of progress.
Notice these attributes are not words used in PM Guide Books or supposed project management methods - which always get confused with software development methods in these days of "agile" anything and everything. These attributes are execution outcome focused NOT process focused.
I'll go out on a very big limb here...
If project management is ever to enter the executive washroom, then it needs to get into the business of business management and get out of the business of telling people what process steps are needed to be compliant with their favorite methodology - be it CMMI IPPD or the latest agile development magic.
Project management is about "management" of projects, not about tools, tricks, and toys.
