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
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
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
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:
This is what mothers are for.
My list to Josh is:
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.
Most PMP study guides are boring. I mean real boring. Boring beyond belief.
Here's one that isn't
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
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:
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.
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.
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/.
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.
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.
|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.
|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|
|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
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):
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.
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.
Coupling IT Governance and Reinventing Project Management into a three stage process lays the foundation for project success
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.
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.
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.
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.
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.
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.
I just finished
Both are in that must read category. Both can be finished in a weekend.
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.
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.
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
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:
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:
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...
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.
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:
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.
Started reading another good PM book
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?
The Systems Bible, John Gall arrived this week from Amazon. This is the 3rd edition of a book I discovered in the mid '80s. A quote from the book is in the title page of my thesis "Fault Tolerant System Reliability in the Presence of Imperfect Diagnostic Coverage,"
In a complex system, malfunction and even total nonfunctional may not be detected for long periods of time.
The 3rd edition contains the usual John Gall approach to systems theory - examples of failures, simple phrases about systems failure and a well footnoted discuss of the theory behind the failure of systems. A bibliography of covers nearly every aspect of the subject of complex systems and their management.
This is NOT a philosophy book - which has become popular these days in the systems business. It is a handbook for those of us who are faced with managing complex systems, be they software development or large projects.
Mike Cohen was kind enough to send me a copy of his latest book Agile Estimating and Planning. A full review is at the link above. But in short buy this book. It is a combination of good advice for agile software development and it contains a solid set of processes that can be used for managing projects in other domains using agile methods.
Most importantly is the development of the estimating methods that can be applied across the board.