As a Blogger, it's incumbent to have a list of books. Many others have recommend the books that speak to how to manager your team, how to communicate with your customer, and how to develop your skills. No my cup of tea, so to speak.
But there are books that can add value to your role as a project manager. I've used these books over time. Some were acquired in 2010, so before but put to work in 2010. Let's start with one of the best books on managing software development projects.
Shenhar and Dvir define a process for managing enterprise class IT projects in a way no other authors do. They define a framework for describing four elements of project success and then show how to put to work on real projects.
Their approach is based on reducing uncertainty. It is uncertainty that is at the root of most project, especially IT project, failure. Uncertainty about requirements, uncertainty about cost and schedule, uncertainty about performance. But most of all uncertainty about what "done" looks like.
Their four dimensions are: (1) Technology, (2) Novelty, (3) Pace, and (4) Complexity.
Details of each dimension are described in actionable terms that can be applied to "real" projects, not just the idealized project.
One size does not fit all. There is a deep discussion about industry and domain impacts on how projects are managed. A rarity in the world of "apply my method, it will work for you." If you're in the IT project management business, this should be your starting point on how to move away from the "check list" approach and the "how to keep my team happy" advise, and move into the profession of managing other people's money for success.
Terry's book describes many of the problems encountered in managing complexity in projects. But this book doesn't talk in terms of fancy complex adaptive systems, all the hand waving and fancy mathematical references of Chaos theory and the like. Terry speaks directly to the real world problems on real world projects. Projects like Terminal Four at Heathrow, the control of cost and schedule in the presence of complexity, and modeling (modelling in the Queens English) of these. And most of all what "actionable information" must be provided by these models for the project manager.
Validating these models is critical to their use. There are many models of how projects work. Some useful, some interesting, some complete nonsense, and some just down right wrong. None of those characteristics are in Williams book. Hean editor of the Journal of the Operations Research Society and Professor and Head of Management Science Department, Strathclyde University. Both research and practical based advice is in the book.
He models include two key elements. Criticality and Cruciality. If you don't knwo the definitions of those two terms, look them up on Google. If you hear someone proposing a model of project management processes, ask them about how their model addresses those two attributes. If they say "what do you mean?" run away as fast as you can. In the Monte Carlo simulations of networks of discrete activities, each with a distinct probability density function, criticality means identifying which activities are critical to the completion of the project. These "drivers" are where management focus must be placed. Sounds simple enough. How about an activity network of 35,000 activities spread around the world? Now which ones are critical for the "coming due" deliverables? Good question. Cruciality defines the correlation between the activity duration and the total project duration. If you don't know this, you're late already and don't even know it.
Here's my one "people management" book. But it's a "real" people management book. Not one written by an HR person, a consultant, or someone with some Psycho-babble theory of how to manage people. Pepplerin managed real programs at NASA. Like my other NASA book, this books is written from hands on experience in a domain where people die, billions are wasted, and you get to read about yourself on the front page of the New York Times if you're a success and even more about you when you're a failure.
The kind of no BS program managers that make promises and keep them, using billions of dollars of public money.
Pellerin was the Program Manager for Hubble, when it was discovered the primary mirror had a serious flaw. The source of the flaw is detailed in the book. But the real answer was "leadership caused the failure." The important aspect of this work is how to manage teams of people in the presence of uncertainty and possible chaos.
Pellerin has a 4 dimensional framework like Shenhar and Dvir. The four dimensions are: (1) Cultivating, (2) Visioning, (3) Directing, and (4) Including. The 4 dimensions have 4 each behaviors embedded in them. With this model, Pellerin describes how to actually manage people to get things done. These 8 behaviors are applicable in all project domains and context. This is the book to start with if you're looking for guidance on how to manage people. Once read, you won't need any other books.
I've mentioned here numerous times Tim Lister quote, that Risk Management of How Adults manage projects. There are many books on risk, some good, some not so good. This is a good book. A bit hard to read but contains all you need to know about risk management. This is the book that shows you how to what you need to do in a practical way, not just the principles, but the pratice.
Ed shows you how to move beyond the simple (and possibly simple minded) multiplication of probability of occurrence and impact - the PMI model. This of course is not the way to build a risk model.
As well, Ed shows how to connect the risk handling processes with the Integrated Master Schedule. Without this connection - managing risk separate from cost and schedule - the project can not be called credible. Each risk and its mitigation or retirement handling process must be "on baseline" in the IMS. When the risk comes true or we reach the point where the risk must be "retired" or "bought down," both funding and time must be available. If this is not the case, then when the risk comes true - turns from a risk to an issue - there will be no time left and maybe the money will have been spent.
A previous favorite on this topic was The Big Short, Michael Lewis. This book is a narrative of the financial crisis in much nore detail. But more importantly it speaks to how the current problem was in fact "known" to have been in place and how we as a nation failed to recognize the problem at the policy level.
But, individuals knew what was coming. I put this book on the project managers list as a counter to the Black Swan theory, proposed by Taleb in the book of the same name. While there is much discussion around the epistemology of "black swans," in the financial crisis, there was ample evidence we were headed down the wrong path. In fact there were individuals and institutions that "saw this coming" and shorted the market making - literally -billions of dollars. As project managers we need to be careful not to succumb to the notion of Black Swans. We must pursue every path of potential risks, define a mitigation or handling strategy, and not just look at the activities in front of us.
This of course is domain specific, but in any domain we must ask the question "did I ignore a potential risk just because I was unable to conceive it was a risk. One definition of "black swans" can start with formal approach
In epistemology and decision theory, the term unknown unknown refers to circumstances or outcomes that were not conceived of by an observer at a given point in time.
We cannot fall into this trap. We got to look further, ask others, seek past performance examples, read the literature and most of all take a deep dive into the possibilities through "brain storming" session (wide band Delphi was a method I was taught in MBA school, that no longer seems popular).
Since we're on the subject of probability, here's a book that you need to read. There are lots of technical probability and statistics books. This is one applicable to the management of project. Simply because it involves the activities of humans and systems and their interactions.
Keynes of course has a broader view of the world than just statistics. The economics view is what made him a household name.
For project managers this economics view address three fundamental issues of probabilistic project management. Knowledge, Rational Belief, and Argument. Keynes speak to the differences between differences in our beliefs that are rational and the part that is not and its impact on our decision making. For example if a man believes something for a reason which is preposterous or for no reason at all, and what he believes turns out to be true for some reason not known to him, he cannot be said to believe it "rationally," although he believes it and it is in fact true.
Each paragraph in the book provides insight like this. Two paragraphs later is the core of the current "black swan" of probabilistic management. There is a distinction between part of our rational belief which is certain and that part which is only probable. The key here is there are degrees of rational belief and if we fail to understand, and more important, fail to "plan" in the presence of these degrees, then were are taking on more risk and not knowing it. This is a core issue in the financial crisis and managing projects in the presence of uncertainty.
This is the core thesis of Tversky and Kahneman's Anchoring and Adjustment and Probabilistic Reasoning.
My final recommendation of Dr. James Brown's Program Management text. The notion that Program Management is like Project Management is naïve. Program Management is about managing Project Managers. It is NOT about managing Projects. Managing Project Managers is much more difficult than managing projects. The term Program Manager is used often in IT. This book should be mandatory for those in IT who call themselves Program Managers. It’s unlikely you’ve been doing your job according the guidance found in this book, the PMI Standard of Program Management, or the OGC Project, Program, Portfolio Management Maturity Model.
Dr. Brown speaks to the difference between project management and program management. Project
Managers focus on cost and schedule. Program Managers focus on the cultural aspects of the collection of projects. This transforms the Program Manager into a leader in ways not found in Project Managers. The primary duty of the Program Manager Leader is to turn chaos into clarity.
This might be seen as the role of the Project Manager on a project, but if the project is in chaos, there
are larger problems not addressable by the Project Manager. The ideal culture for a successful Program
is one based on the following layers
- People Accountability
- Process Accountability
- Discipline
- Integrity
- Clarity
This pyramid has Number 1 at the bottom and Number 5 at the top. There is a list of the conditions found in a chaotic program management culture. These are common in all failure environments. Dr. Brown provides guidance in the following sections on how to address these conditions, starting with Accountability. Each of the descriptions provides advice that can be put to use. The key here is to have processes around which people can be accountable. These are not rigid processes, but processes that guide the program. You would not call this book “agile,” but many of the principles found here can also be found in agile approaches – once you put in place the people and process accountabilities.
That's It for 2010. These books are not introduction texts, they are not academic guidance, they are not for casual reading, but are a core set of principles that can be put to work on your projects in ways other simple and possibly simple minded texts can not.
