Many good Project Management books arrived on my shelf this year. I came across the best one (I post the entire list before year end), while shopping for a physics books for a CIO friend.
The Seven Secrets of How to Think Like a Rocket Scientist, Jim Longuski, Copernicus Press, 2007
Although the book uses "rocket science" as its analogy, it is directly applicable to IT project management. The book consists of seven chapters with small (2 to 3 page) subchapters:
- Dream
- Judge
- Ask
- Check
- Simplify
- Optimize
- Do
It's not easy to explain why this book is important to us here in the Project Management world. What struck me in the first few lines is the deep misconceptions about project management in many domains - not the least of which is the agile community. I've been struggling for some time to come to grips with why the agilest and the opposite - those not understanding the value of project management and therefore reject its tenets - can not break out of their mind set.
This mind set usually starts with anecdotal experiences ranging from:
- PM is a dying process replaced by some other process - which of course provides the same activities and outcomes relabeled in the "new" form. Old wine in new bottles
- PM processes based on PMBOK and other approaches will always fail because they have failed for the writer and therefore will fail for others. The classic is the writer claiming the Critical Path Method or Earned Value is fundamentally wrong and must be abandoned. Failing of course to read about the multi-billion dollar space flight programs which make use of those two (and many more) approaches on a daily basis to deliver on time, on budget
- Etc. etc. etc.
These critiques are Das ist ganz falsch, using Wolfgang Pauli's famous quote. The core problem is fail to understand the fundamental role of a Project Manager - the person in the form of a titled Project Manager, an XP or Scrum lead, the facilitator of a meeting, or anyone tasked with the activities of...
- Discovering the scope of work
- Identifying the definition of "done"
- Identifying when "done" will arrive
- Identifying the cost to get to "done"
- Discovering and some how mitigate - including ignore - the risk that will prevent "done" from appearing on time, on budget, and on specification
Read this book (it's not too expensive) and glimpse how those who design, build and fly space vehicles, the facilities and software the manage them see the their roles and how these roles can add value to manging IT and software development project.
