The quest for simplicity is many times misguided. My personal favorite of course is the email, twitter, IM based project management processes of PM 2.0.
But there are others. Processes where the requirements for the system "emerge" as you go along, while at the same time, the budget and the schedule have fixed boundaries.
I personally experienced this in the real-time instrument product business. The market place had specific minimal requirements, the development group tried to introduce XP in the absence of a set of firm - product success - requirements. After a couple million flushed down the drain and the removal of the software development director, a "normal" requirements based development process was put back in place.
I'm speaking at Carnegie Mellon again in February. The topic this time is the "5 Immutable Principles of Project Management." These are:
- Where Are We Going?
- How Do We Get There?
- Do We Have Enough Time, Resources, And Money To Get There?
- What Impediments Will We Encounter Along The Way?
- How Do We Know We Are Making Progress?
If you can't answer these in units of measure meaningful to both the buyer and the seller, then we're not managing the project. If we're not managing the project, it'll be in the ditch soon.
