Herding Cats

Project Management Books

Andrew Filev asked on his Blog awhile back, "what Project Management books should you read?" This is a good question for all project managers. But I have difficulty with the books he listed. Which may be my same difficulty with grasping the notion of PM 2.0 paradigm. 

His first "book" PMBOK^® is not a "book" about project management in the sense of the books listed below. The PMBOK^® speaks its name. It is a Guide to the Project Management Body of Knowledge. The Knowledge Areas (Integration, Scope, Time, Cost, Quality, HR, Communications, Risk, and Procurement) and Process Groups (Initiating, Planning, Executing, Monitoring and Controlling, and Closing) in PMBOK^® provide a framework for managing projects. Which by the way, if you're not doing these knowledge areas and process groups in some way, you're not doing project management. You might be doing something else, developing code, collecting "to do lists" in your email, chatting with colleagues on IM and Twitter. 

So first of all, please do not use PMBOK^® as a starting place for learning about project management. PMBOK^® is a framework assessment book. 

Here's what's on my self that I use for our practice of Program and Project Management and Program Planning and Controls.

• The Management of Projects, Peter W. G. Morris, Thomas Telford, London, 1997. You can get this book from Amazon UK or sometimes from Amazon US
• AntiPatterns in Project Management, William Brown, Skip McCormick, and Scott Thomas, John Wiley and Sons, 2000. They have other AntiPattern books as well. Although Patterns and AntiPatterns have good out of favor in the ADD world of WEB 2.0, knowing these AntiPatterns will allow you to resist the siren song of IM, Twitter, and email as a replacement for good project management processes defined in PMBOK^®.
• Modelling Complex Projects, Terry Williams, John Wiley & Sons, 2002. All nontrivial projects are complex in some way. All attempts to simplify complex projects usually fail in some spectacular way. Dr. Williams book explains how this happens and how to avoid it.
• Software Project Management, Walker Royce, Addison Wesley, 1998. This book is getting a bit long in the tooth, but still has lots of good advice for enterprise class software development projects. This Royce is the son of Winston Royce of TRW, who's paper on Water Fall is the mots misinterpreted piece of writing in all of software development. I worked in the same build as Royce and Boehm (O6, TRW, One Space Park, Redondo Beach, CA) in the hey days of software development methodologies. 
• Managing Agile Projects, Edited by Kevin Aguanno, Multi-Media Publications, 2004. This is a good survey of how to manage "agile" projects. It is not an agile "project management" book. There is a dramatic difference between the two. Without knowing the difference you fall victim to the belief that agile software development is the same as project management.
• Catastrophic Disentanglement: Getting Software Projects Back On Track, E. M. Bennatan, Addison Wesley, 2006. This is one of the paradigm changing books. Bennatan provides a step-by-step process for rescuing software projects from the brink. Again a software project management book, not a book about software development.
• Agile Project Management, Jim Highsmith, Addison Wesley, 2004. I run hot and cold on Highsmith. I'm back, now that the hype around "agile project management" has died down. 
• Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation: Aaron Shenhar and Dov Dvir, Harvard Business School Press, 2007. This is one of the best books for corporate IT project management. I share writing duties with Dr. Shenhar in the newsletter PM Weekly Insights.
• IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne Ross, Harvard Business School Press, 2004. The concept of "decision rights" is completely lost on many in the project management world. Who gets to decide is a governance question. When "all" get to decide and anyone gets to decide, the results is usually chaos at the enterprise IT level.

There are books you need that don't have Project Management in the title. These books are about the processes underlying the management of projects.

• Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund Conrow, AIAA Press, 2003. Ed worked on the proposal for the Crew Exploration Vehicle (now called Orion). Ed and this book changed completely my view of programmatic and technical risk management.
• Effective Opportunity Management for Projects: Exploiting Positive Risk, David Hilson, Taylor Francis, 2004. While the notion of "positive risk" is counter intuitive and cautioned against by Ed Conrow, this book is a good survey of the concept of exploiting opportunities in projects. This is applicable during the early stages of development where change has less cost.
• Performance Based Earned Value^®, Paul Solomon and Ralph Young, John Wiley & Sons, 2007. If you want to learn how to do Earned Value right, this is the book. The "iron triangle" for modern projects is Cost, Schedule, and Technical Performance. Paul's book shows you why and how to put this concept to work. Paul is retired from Northrup Grumman where he lead the EV activities for the B-2.
• The Art of Systems Architecting, 2nd Edition, Mark Maier and Eberhardt Rechtin, CRC Press. Rechtin, is the retired president Emeritus of Aerospace Corporation, an arctitect-engineering firm specializing in space systems for the US Government. Aerospace Corporate "invented" GPS.
• The Requirements Engieering Handbook, Ralph Young, Artech House, 2004. You can't have project management without requirements management.

Yes I have the Collins book as well. It's getting less interest these days as the data from book is not holding up in practice. But sill good core ideas.

One final book The Story of Managing Project: An Interdisciplinary Approach, Elias Carayannis, Young Hoon Kwak, and Frank Anbari, Praeger, 2005. This is a survey of a broad range of project management practices in a variety of industries. My chapter "Agile Project Management Methods for IT Projects," starts on page 324.

Cost Estimating Guide

The GAO Cost Estimating and Assessment Guide describes the success factors for managing cost. Chapter 19 is all about Earned Value. While this document may appear to be yet another government tome, it provides important information needed to increase the probability of success for any project, not matter the domain or context.

With the content of this document, you can start to answer important questions about your project:

• Is your performance measurement system producing credible information needed for decision making?
• Are we making physically measurable progress against our planned progress?
• Is the schedule a credible description of how the project will meet its planned completion date and cost?
• Are the trend of the cost and schedule performance improving or getting worse?
• Will the cost, schedule, and technical performance expectations of the project be met?
• Is management paying attention to the project performance metrics?
• Is the Estimate At Completion (EAC) credible?
• Are all the risks identified and handled?

These questions need to be continuously answered no matter the project type, it's domain and context, and most importantly not matter the project management method.

So take a look at the GAO guide and see if something resonates with your project.

Books

A recent post on Andrew Filev's blog - a great blog BTW - answered the question about Project Management Books. Here's a collection of book recommendations going back to 2005

• 2005 books on or about project management
• Books needed for project and program management (update)
  
• Two must read PM books
  

Books needed for Program and Project Management (Update)

While working on a government proposal over the holidays - as is typical for the government to put out the RFP and then go on vacation - I came across another book that is needed for the Program Office Library

• Assumption Based Planning - A Tool for Reduce Avoidable Surprises, James A Dewar, Cambridge University Press. This is a book all complex system development managers need to read and put to use. The concept is that planning in the presence of uncertainty requires a formal "assumptions" management process. This sounds simple, but in fact is a complex adaptive systems problem. For those in the agile world who use the term CAS and likely have little understanding of the theory, this is a book for the planning management processes needed to develop system in the presence of uncertainty.

Josh Nankivel asked for some suggestions of books on project management. In my experience most of he books on project and program management are too simple for any practical use. Over the years (30 years) I've had a different approach to books. First I'm the son of a University Librarian. I grew up in a house where books were scattered everyone. My mother read many books in parallel, a habit I enjoy. She also taught me to buy book I had no use for at the moment. Because when you needed them it was too late. This means reading things in preparation for some future need. In my short lived physics career and my longer lived technical management career, this advice has severed me well.
    Two other important quotes were:

Don't peak too soon
This too will pass

This is what mothers are for.
    My list to Josh is:

• The Handbook of Program Management, James T. Brown. This is a real handbook, with specific advice on managing programs from a professional program manager. I've posted a review for a more detailed background. This is the first book to buy, since it shows what is needed to successfully manage a Program. This is not a project management book however.
• For project management The Management of Projects, Peter W. G. Morris is my favorite. This is not a handbook nor a how too book, It is a history of project management. As such it is a guide of what has worked and not worked in the past.
• A similar book is Anti-Patterns in Project Management, Brown, Malveau, McCormick, and Mowbray, John Wiley. The anti-patterns speak to what not to do in software development projects.
• Systems Engineering: Coping with Complexity, Stevens, Brook, Jackson, and Arnold is a systems engineering book. Every non-trivial project is really a systems engineering problem. This book is a good introduction to the concepts of SE.
• Performance Based Earned Value, Paul Solomon, John Wiley & Sons. This is one of the best EV books to own. Paul integrates technical performance measures with EV to provide tangible evidence of physical percent complete.
• Catastrophe Disentanglement: Getting Software Projects Back on Track, E. M. Bennatan. For any whoi has struggled with "getting back on track," this book provide detailed steps.
• Project Delivery System: 4th Edition, CH2M Hill. This book was used during my Rocky Flats PMO job. It is written for construction projects, but is applicable to other projects, including software. PDS is the CH2M Hill project management method. Project management is what CH does and they do it well. Learning from a firm that earns their living successfully managing high risk projects is a good place to start. You order this book from Amazon, since it is not in the store.
• Beyond Bullet Points, Cliff Atkinson. There are two versions of this book. I personally like the 1st version best. The 2nd version removes some of the structure I like. This is not officially a project management book, but the information on how to build a Power Point presentation is directly applicable to building a credible project plan.
• How to Lie with Statistics, Darrell Huff. This is available in paper back. This boo allows the project manager to recognize the "lies" that are produced in status reports, budget forecasts, and other tools used to hide progress, risk, and productivity. 
• Effective Risk Management: Some Keys to Success, Edmund Conrow, AIAA Press. This is a heavy weight risk management book. By heavy weight I mean it is heavy reading. But it also contains everything you need to effectively manage risks - both technical and programmatic. I had the privilege to work with Dr. Conrow on the Crew Exploration program. He's the author of the risk management section of the DoD PMBOK and several risk management guides for DoD.
• Augustine's Laws, Norm Augustine, Viking. This is a look at larger government programs from the view of the President of Martin Marietta Corporation. Norm's Laws have general applicability to enterprise IT and REP projects in many cases.
• Herding Chickens, Dan Bradbary and David Garrett, is a clever book with some good ideas,
• The Office of Government Commerce has several handbooks useful to project managers:

• Skills Framework
  
• Skills Framework Assessment Guide
• Portfolio Management Guide
• Project, Program, Portfolio Management Maturity Model (P3M3)

These are guides for developing project, program, and portfolio management processes. They are far superior to the PMI PMBOK approach for too many reasons to enumerate here. But take a look at the home site to see if anything there can be but directly to use.

• The two agile project management book I'd recommend are Kevin Aguanno's Managing Agile Projects and Mike Cohen's Agile Estimating and Planning. I have a review of Mikes book here.

Book Review Time (Again)

    I'm review a book The Handbook of Program Management, Dr. James T. Brown. It's a book about Program Management (from the title), but it's really a book about program success criteria.
    Like some other book reviews, my style is to read every word and make comments on the sentences, paragraphs, and chapters they form. This is annoying to some. But a book is a powerful tool for moving forward in the profession of project management. Books can provide the needed tools for making this happen.
    Here are some past reviews while waiting for this one.

A Clever PMP Study Guide

Most PMP study guides are boring. I mean real boring. Boring beyond belief.
Here's one that isn't

Headfirst PMP

PMI Global Congress Books

At the PMI Global Congress, there is a book store. I love book stores, being the son of a University Librarian. I bought several books that I would not have normally bought:

• Effective Opportunity Management for Projects: Exploiting Positive Risk, David Hillson, Taylor and Francis, 2004.
• Pivot Table Data Crunching for Microsoft Office Excel 2007, Bill Jelen and Michael Alexander, Que, 2007.
• Earned Value Project Management, 3rd Edition, Quentin Fleming and Joel Koppelman

Effective Opportunity Management
Most risk books have risk in the title. David's book is about managing opportunity while managing risk. While this is still a controversial topic the conversation about opportunity and risk is starting to emerge. The Edmond Conrow article "Opportunity Management: Be Careful What You Wish For," is the primary source for not connecting risk and opportunity.

Pivot Table Data Crunching for Microsoft Office Excel 2007
Most of the data found in project management is multidimensional. In fact when I come across single dimensional (rows and columns) of data, it usually means the too much summarization has been done. An example of multidimensional would be:

• Named Resource, with hours for the period of performance
• Work Package for the period and the BCWS spreads
• Period of Performance
• Deliverables and their physical percent complete

Now build a report that shows the labor cost and associated hours for each deliverable by each work package. This is the job of a pivot table.

Earned Value Project Management
    The 3rd edition has switched to the "story telling" mode, which I don't like. In fact I find it not very useful. This is a personal issue, since in my heart of hearts I'm a quant. This is why I was an experimentalist in my very days, before I went to the real dark side, writing Kalman filters for missile guidance systems. Kalman filters are "target tracking" algorithms using position and velocity measures in realtime. But EV 3rd edition is a good starting point for those entering the EV domain. That's likely they changed the style. Since EV still has many detractors, many who misuse it, many who misstate its purpose, and many who are simply uninformed - this book is a great value.
    All three books are in use. I'm wading through Hillman's work and will write a review. It sits next to Conrow's Effective Risk Management, and is of equal obtuseness. But obtusness with deep content is usually call important in my domain.
    By the way, it's the obtuse without the deep and executable content that is common these days in the project management Impresario writings.

A Little Book of f-Laws

Cleaning up my desktop tonight, I came across the "13 Common Sins of Management," by Russell Ackoff and Herbert Addison in a PDF file I received from somewhere unknown.

1. The lower the rank of managers, the more they know about fewer things. The higher the rank of managers, the less they know about many things.
2. Managers who don’t know how to measure what they want settle for wanting what they can measure.
3. There is nothing that a manager wants done that educated subordinates cannot undo.
4. The less sure managers are of their opinions, the more vigorously they defend them.
5. The more time managers spend trying to get rid of what they don’t want, the less likely they are to get what they do want.
6. A bureaucrat is one who has the power to say ‘no’ but none to say ‘yes’
7. The legibility of a male manager’s handwriting is in inverse proportion to his seniority.
8. The less important an issue is, the more time managers spend discussing it.
9. The more important the problem a manager asks consultants for help on, the less useful and more costly their solutions are likely to be.
10. Managers cannot learn from doing things right, only from doing them wrong.
11. The amount of irrationality that executives attribute to others is directly proportional to their own.

The collection of 80 Laws is found in Management f-Laws: How Organizations Really Work, Russell L. Ackoff and Herbert J. Addison, http://triarchypress.co.uk/.

A New Agile PM Book?

I came across The Software Project Manager's Bridge to Agility, Michele Slinger and Stacia Broderick. The title alone caught my eye, always on the lookout for new and innovative ways to management projects in the presence of change. There was a free down load that contained the following summary and a table comparing approaches to change management.

• Scope creep" doesn't exist in agile projects, because scope is expected to change.
• Scope management in agile is primarily a function of "rolling wave" planning and the management of the product backlog.
• Scope is defined and redefined using five different levels of planning that take the team from the broad vision down to what team members plan to complete today.
• WBSs are not created per se; instead, release/quarterly plans and iteration plans serve to break down the work into smaller work packages, referred to as "features and tasks."
• Scope is verified by the customer, who is responsible for accepting or rejecting the features completed each iteration.
• Scope is controlled through the use of the backlog, rolling wave planning, and the protection of the iteration.

First Impressions

I was puzzled by the lack of distinction between agile project management and the more traditional project management beyond the "waterfall" and "agile" comparison. "Waterfall" is a code word – for me anyway – for "bad project management." There are numerous project management methods and paradigms beyond waterfall. Waterfall itself was replaced by the US Department of Defense with the release DOD 5000.2R effective in October 23, 2000.

When an author uses "waterfall" in a generic way as the counter to agile, I usually put the book down, turn the magazine page, or push the Back button. It means it's going to be another rant about how agile is the best way and all the ways of the past were wrong. I'm hoping this is not the case here. I haven't bought the book yet. When authors use this approach is usually means they don't manage projects with any current approach, relying instead on a decades old "war story" as their basis for the new approach. At Rocky Flats (www.rfets.gov) we used to have a saying "Don't do stupid things on purpose." That is appropriate here when trying to compare the "new" with the "old."

But let's look at the preview for Chapter 5 – Scope Management.

Traditional	Agile	Comments
WBS Creation
Create a work breakdown structure	Conduct planning meetings and give the team diagram. The responsibility for breaking down the work into smaller work packages (features and tasks), displayed as the release plan at the high level, and the iteration plan at the more detailed level.	The WBS defined in MIL-STD 881A is product focused. The terminal nodes of the WBS Tree are the deliverables of the project. They are the products, services, features, fucntions. They are what the customer paid for. Typically the work described in the terminal nodes or the the nodes one level above are encapsulated in a Work Package that deliver the "feature," "product," or "service." This is the guidance from the US Department of Defense. Sequencing these deliverables is done in the Integrated Master Schedule. The result of following the DOD guidance is exactly what is proposed for the agile method here – no difference in practice.
Scope Validation
Document the completed deliverables that have been accepted and those that have not been accepted, along with the reason.	Documentation of accepted features may be done informally (by moving the sticky notes to the "done" pile) or formally.	"Formally or informally" what's the difference? Sticky notes of change controlled documents? OK, sticky notes are informal. Document updates are formal. What is the difference between agile and traditional?
Document change requests	Customer updates the backlog	Someone updates the change request log. No difference
Scope Control
Use a change control system to manage change	The customer manages the product backlog; once the team commits to the work to be done in an iteration, the scope is protected for that duration.	Managing the changes is a "verb." What this verb gets applied to is a "noun." There is no difference in the description here between agile and traditional
Update all documents as appropriate with the approved changes	The team revisits release plans and product roadmaps regularly, making changes as need to better reflect the team's progress and changes requested by the customer	Update the appropriate documents? Yes that's a good idea. To do otherwise would be  nonsense. No credible PM method says to update everything no matter the consideration of the need. Credible PM methods update only those documents needed to be used to move forward. It's a simple test of logic - why are you doing stupid things on purpose? Stop. If a document isn't needed for the next step in the project or later in the project, it should not have been written. Even DOD 5000.2 says how to do this. No difference.

If this is the comparison between "traditional" and "agile" let's hope it gets better with the other chapters. Otherwise it'll be one of those "restating weak arguments" type books that are popular but provide no real value to us here in the field.

In the End it's about measuring delivered Value

I've said this before, and I've worked directly on DoD and NASA programs using this approach. Scrum and IMP/IMS with performance based earned value are all litter mates. Iterations, with planning packages. Physical percent complete using evidentiary materials – running code, user features, drawings approved for manufacturing, metal bent into spacecraft, etc. are the ONLY tangible evidence of progress to plan.

I'll buy the book, but I'm not looking forward to the weak comparisons between a decades old way, which has been replaced by law and the supposed "new" way of managing projects. Especially when there is no real practical difference being drawn.

Here's my take on "agile" project management using the Deliverables Based Planning, IMP/IMS, Performance Based Earned Value, and Technical Performance Measures with measures of Physical Percent Complete for each Work Package:

• Define the business capabilities needed for the business case to be successful.

• Define the technical requirements and the features needed for the capabilities to appear in an iterative manner. Call it Rolling Waves, Scrums, whatever you want. But is has to be iterative and incremental. Why? Because business requirements – and manned spacecraft requirements CHANGE! That's why. "Don't do stupid things on purpose."

• Measure progress with tangible evidence of produced value.

• Have a risk management plan for all risks that will prevent the delivered capabilities from delivering their value. Keep this plan in front of everyone. Have retirement plans at best and mitigation plans at least.

• Have the customer as close as possible. Sometimes they can't be there physically. We have monthly Technical Interchange Meetings (TIM) on a multibillion dollar program. Ask the customer if we are still in agreement on what "done" looks like every month.

DON'T DO STUPID THINGS ON PURPOSE

The Handbook of Program Management

There are very few project or program management books that interest me from the popular press. I read loads of DoD guides, technical books (Performance Based Earned Value, Paul Solomon), and really technical books (Effective Risk Management: Some Keys to Success, Dr. Edmund Conrow).
    A new book arrived - The Handbook of Program Management, James T. Brown, McGraw Hill. The title is "nice" but it sat on the desk for a few weeks. I stuck it in my backpack for some reading while waiting at the airport. From the first pages on, this is a book written by a Professional Program Manager for Professional Program Managers. Many "how to" style books restate the obvious, assume you're a kid again, and provide really nice theory and not much practice. This is my pet peeve with many of the agile books, except Mike Cohn's.
    Dr. Brown's book is not advice to the naive and uninformed. It is advice targeted to the knowledgeable Program Managers and some advice that is usable for everyone in the business of managing other peoples money. It's advice on the irreducible attributes of good program and project management. The core concept is quite simple:

Process trumps people and technology

    This of course is anti-agile, but reading further it becomes crystal clear why process trumps people and technology. Process is the only thing that is "sticky" in most organization. People come and go. Technology changes every few quarters. All nontrivial projects and programs run on a consistent process.
    Scrum is a consistent process. Scrum is a highly disciplined process. The notion that its "people over process" ignores the fact that one of the most effective agile software development methodologies is a highly disciplined, structured, process focused way of delivering on-time, on-budget, on-specification.
    The core principles of the book are (from bottom to top):

• People Accountability
• Process Accountability
• Discipline
• Integrity
• Clarity

The critical concept is Achieving Discipline with Minimal Process. This is the basis of all good project management practices.
    I'll write a full review when I finish the book. But for now, I'd recommend anyone interested in hearing how to manage Program's from a professional Program Manager, buy a copy.

The Next MUST Read Book

After Reinventing Project Management, the next book that is a "Must Read" is IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne W. Ross, Harvard Business School.
    Much of the confusion around project management in the IT business starts when the concept of Governance is skipped.

• Who gets to decide what to do?
• Who gets to decide what done looks like?
• How can these decisions be connected with the business strategy?
• How can we tell we're making the right decisions?

    Coupling IT Governance and Reinventing Project Management into a three stage process lays the foundation for project success

1. Governance - what are the rules for managing the IT department in its quest to provide value to the organization?
2. Request to Project - what projects shoudl be done for the business? Who gets to participate in these decisions? How can we "Guard the Front Door of IT," so the resources and capabilities in place today can deliver value for tomorrow?
3. Project to Delivery - once the portfolio of projects is defined (project selection using some form of portfolio management), how can they be assured to complete on-time, on-budget, and deliver the promised business value?

    This is the role of the Program Management and Project Management professionals in IT. All the smoke mirrors, and magic beans of project management must address these questions first before any credible discussion can take place about the specifics of managing any one project to its successful conclusion.

The Best PM Book I've Read So Far

    I read lots and lots of project management books. Ranging from useful to nonsense. This one's both useful and makes sense.

Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation, Aaron J. Shenhar and Dov Dvir, Harvard Business School Press, 2007

    This book has sensible, realistic, practical suggestions on how to manage projects. No "magic beans," no psycho-babble about self actualizing the staff before starting to manage the project, no over the top agile suggestions about the lack of purpose of project management, self indulgent proclamations about having discovered the secret to managing projects in some new paradigm, so suggestions that we know and apply every day is some now obsolete. Just plain, straight, approaches to delivering value to customer.
    Worth the $35, buy it, read it, read it again, get back to the work of managing projects for money. That's what we get paid for, that's why we're called project and program managers. We do (or should) deliver value to customers.

2007 Books

The annual book list is a tradition in many outlets ranging from Blogs to the Booz Allen reading list. Here's my list of books that were memorable in 2007.

• Performance Based Earned Value, Paul J. Solomon and Ralph R. Young, John Wiley & Sons. This book now has yellow markings and 3M tabs on nearly every page. If you manage projects for money and what to know how to do it better, read this book.
• The Requirements Engineering Handbook, Ralph R. Young, Artech House. This is the companion book to PBEV.
• Dereliction of Duty, H. R. McMaster, Harper Collins. A history of Vietnam, the Johnson administration and those who led us into the abyss. Replace Vietnam with Iraq and its the same book. I was there and know a bit about looking into the abyss.
• I Am a Strange Loop, Douglas Hofstadter, Basic Book. Hosfstader's latest book. Godel, Esher, Bach changed my life (so to speak). This is GEB but a good read all the same.
• Arsenals of Folly, Richard Rhodes, Knopf. This is the 3rd book about nuclear weapons and nuclear war. His best. Another example of how naive we are about our leaders and their misguided intentions in their pursuit to protect us from the evils of the world.
• Reasoning about Uncertainty, Joseph Y. Halpren, MIT Press. This is one of those books that is pure "tough going." In the end the understanding of decision theory is the result. All the popular texts and articles are now tossed in the trash. Anyone claiming to have simple solutions to making tough decisions needs to read this book. 467 pages of formal systems in decision logic. Not for the faint of heart.
• Of Mice and Men, John Steinbeck, Penguin Books. Our son was reading this for his HS literature class. a quick 102 pages. I vaguely remember this book many decades ago. Devastating ending. Good airplane book.
• Systems Engineering: Coping with Complexity, Richard Stevens, et al, Prentice Hall.  Anyone making claims of a simple, lean, agile approach to complex problems is blowing smoke. Read this book. Investigate the profession and literature of Systems Engineering. (MS in Systems Management, USC 1982 is now back in vogue). Excellent survey of the topic of practical complex systems and approaches to dealing with them. Best understanding - "For every complex problem, there is a solution that is simple, neat, and wrong." It's wildly popular to suggest all complex problems can be reduced to simple problems with simple solution - wrong.
• Semper Fi: Business Leadership the Marine Corps Way, Dan Carrison. While not a Marine I'm am a combat veteran. This is one of those easy read business books that has too many pages. A simple list of principles would have been all that was needed. But it is thought provoking in how simple the ideas of leadership can be applied to almost any domain.
• Catastrophe Disentanglement: Getting Software Projects Back On Track, E. M. Bennatan, Addison Wesley. A nice realistic description of managing troubled projects. No fancy methods or silver bullets. Just plain common sense project management processes.
• Strategic Performance Management: Leveraging and measuring your intangible value drivers, Bernard Marr, Butterworth. All about defining, measuring, and recognizing value. The agilest speak about delivering value. But never speak about the units of measure of this value, or how the value is recognized. Only that the customer defines the value. Well this book and the practices around it define what is meant for the term value - both tangible and intangible - in units of measure meaningful for both sides of the equation - producer and supplier.
• 101st Airborne: The Screaming Eagles in World War II, Mark Bando, Zenith Press. A photo book of the 101st. The commanding general in 1970 (my tour of duty) was a 1st LT at Eindhoven in Holland. A long history of infantry commanders.

There are dozens of other book in the "to read" or "been read" pile. All were worth the effort. Some required more effort than other Pillars of the Earth and World Without End are two examples. My wife can burn through these types of books. I have to read every word, like it is a physics text.

Book Update

I'm working my way through Catastrophe Disentanglement. The author has written other books on the same topic and is a consultant for the Boston Cutter Consortium. This book should be mandatory reading for any project manager.
    While chasing down references in the book and working on training materials for Establishing the Performance Measurement Baseline I came across a Jim Highsmith article on Max Wideman's site describing the issues with the Standish Chaos report. I've never liked the approach Standish takes with reporting IT project issues. It's not statistically sound and skews the sorting bins to make the issues sound worse than they are. I've made some comments in the pat, but Highsmith's voice has much more weight. Nice to see the approach being challenged.
    The loop here is in the Catastrophe Disentanglement book is a picture of Cutter's assessment of the issue of measuring project success and failure. The concept of "on time and on budget" is not only naive, it is counter productive. The role of Management Reserve, flexible capabilities, real options, and emerging business needs is not only ignored in many project assessments, it creates a fluid assessment process in which the definition of Success is itself fluid.

Yet Another Book

    Paul Solomon's Performance Based Earned Value has a co-author- Ralph Young. His book is The Requirements Engineering Handbook . This book is a guide to the development of requirements. Requirements elicitation is critical to any project be it agile or not. Pp. 154-155 discuss a bit about agile requirements and presents some Home Grounds for both the agile and disciplined approaches to requirements.
    The comparison terms of agile and disciplined are probably not the best, since agile processes require discipline - possible more discipline - Table 7.7 on p. 155 does provide a nice side by side comparison. Especially in the enterprise and ERP domain "managing" requirements - whether they are emerging or not - is a critical success factor. While there are many good reasons for this, one of the most important ones is the connect any and all changes to requirements to the business case and back to the Earned Value (BCWP) components of the business case.
    By making the connection between business value derived from the capabilities of the deployed system, to the costs of developing that system, to the Earned Value of the components produced from the investment of that cost - the project managers are able to make informed decisions about trade offs in the presence of emerging or changing requirements. This is the basis of any Systems Engineering trade studies approach. An approach not yet common in the IT and software development business, but at the heart of aerospace and defense systems.
    It answers the question

What is the value of a decision in the presence of risk, cost, benefit, requirements compliance and opportunity?

If the project team is responding to emerging requirements, or reacting to customer requirements changes without the ability to do the trades then they are simply following the will of the customer - and possibly blindly following the will of the customer, because the customer may be just as uninformed about the trade space as the development team. As well this is the basis of Real Options in the context of Project Portfolio Management.

Two Must Read PM Books

I just finished

• Herding Chickens: Innovative Techniques for Project Managment, Dan Bradbary and David Garrett
• Flawless Execution: Use the Techniques and Systems of America's Fighter Pilots to Perform at Your Peak and Win the Battles of the Business World, James D.Murphy

Both are in that must read category. Both can be finished in a weekend.
    Herding Chickens
This is a collection of essays on managing projects. Managing projects from a practical point of view. Hard, cold advice to project managers. It's one of the books you'll skim through then come back days or weeks later and discover a new idea.
    Flawless Execution
Is a more difficult book to read. It needs a bit more copy editing to improve the consistency of the themes. But it is a powerful book all the same. Based on an F-15 pilot paradigm, it show how strategy is the key to success in any business venture. This is restating the obvious, but this book speaks to the actual doing of the strategy-making process.

Books of 2006

There are many good book lists. I've sampled readings from them in the past. My best selections though come from impulse buys:

Business and Technical Books

1. Performance Based Earned Value, Paul Solomon and Ralph Young. This is a culmination of Paul's efforts to connect Earned Value with project performance management.
2. Think Like a Rocket Scientist, Jim Longuski. A survey thought processes that can be applied to project management as well.
3. The Balanced Scorecard series from Norton and Kaplan have been put to work in our BSC work. The best book in this group is Balanced Scorecard: Step by Step, Paul Niven
4. Rethinking Performance Management, Marshall Meyer, establishes all the difficulties with a performance management initiative and the ways of closing these gaps.
5. Agile Information Systems, edited by Kevin Desouza provides a practical guide to deploying agile methods in IT. It is not an agile development book, but a book for those responsible for the business side of IT and the use of technology to meet those business needs.
6. The Management of Projects, Peter W. G. Morris surveys in detail the processes of managing projects. In detail from the field experience of successful and not so successful projects.
7. The Systems Bible, 3rd edition, John Gall. This view of the world is a good starting point for anyone wanting to break out of the methodology box and look at problems through the eyes of a systems engineer.
8. A two volume set: The Space Shuttle Decision 1965 - 1972 and Development of the Space Shuttle 1972 - 1981. Is an very detailed look at the management of "the most complex machine ever devised."
9. Effective Risk Management, Edmund Conrow, is the one and only risk management book you'll ever need. Not for the "weak of heart" due to the deep technical aspects of probabilistic risk management, but exclusive of all the topics needed to manage risks in complex projects.

Pleasure Books

1. Chances Are: Adventures in Probability, Micheal and Ellen Kaplan. An easy read about the subject of probability and how our lives are impacted everyday.
2. Raise Heaven and Earth, William Harwood. A business biography of the Martin Marietta company.
3. Augustine's Laws. Norman R. Augustine. The immutable laws of business as told by the retired president of Martin Marietta
4. Absolute Friends, John LeCarre. In the tradition of "cold war spy resurfaces in modern times," LeCarre provides a set of characters that come close - but not that close - to Smiley and his previous generation.
5. Mission Song, John LeCarre. Another Africa story like The Constant Gardner
6. The Inflationary Universe: The Quest for a New Theory of Cosmic Origins, Alan H. Guth. This is a current survey of the problems associated with the formation of the universe

The Best PM Book of 2006

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:

1. Dream
2. Judge
3. Ask
4. Check
5. Simplify
6. Optimize
7. 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:

1. 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
2. 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
3. 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...

1. Discovering the scope of work
2. Identifying the definition of "done"
3. Identifying when "done" will arrive
4. Identifying the cost to get to "done"
5. 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.

New Books on the Shelf

Fall is setting in, ski season is almost here - Arapaho Basin is open and our 15 & 16 year olds are chomping at the bit to strap on the boards. Cycling season is still here, so not so fast boy and girl, dad still has miles to go before we move inside on the rollers.

Fall is also book buying season. At my age its hard to keep up with the teenagers on the slopes. So ski in the morning, have a nice lunch at Ten Mile Station, and read in the afternoon.

Here's my current list:

• Rethinking Performance Management: Beyond Balanced Scorecard, Marshall W. Meter, Cambridge University Press, 2002 - defines a method of performance management (my current interest) that approaches the realities of Balanced Scorecard and the disappointments of its use or misuse.
• State of Denial, Bob Woodward - everyone I know that has read this book has come away very depressed, my turn.
• The Shakespeare Wars: Clashing Scholars, Public Fiascoes, Palace Coups, Ron Rosenbaum, Random House. I asked for this for my birthday. So far its held up to my expectations.
• Absolute Friends, John LeCarre - we're reading this in our "mens" book club. Our spouses have two and maybe three book clubs. Time to get with the program. I'm a dedicated LeCarre fan.
• Mission Song, John LeCarre - the latest, after Absolute Friends.

It's supposed to be a good winter for us - Breckenridge has a good base long before the season opening - eveyone has new skis and the kids have new boots - so we'll out in the back bowls soon enough.

Another Killer Book

Started reading another good PM book

The Project Management Scorecard: Measuring the Success of Project Management Solutions

The reason this book is useful is that it connects tactical processes with strategy through the Balanced Scorecard. The traditional approach to project management starts with a set of processes - defined in PMBOK for example - and applies these processes to the project in the hope that their use will improve the success probability of the project.

The strategy based approach asks and answers the question:

What is the unassailable beneficial outcome of this practice?

This style of conversation is much different than the "process compliance" approach.

How would we recognize this beneficial outcome when it arrives?