And the Principles, Practices, and Processes to Increase Probability of Success
Performance-Based Project Management(sm) on Amazon
Here's the Table of Contents and Chapter 2. This chapter is the anchor for the Principles, Practices, and Processes of increasing the probability of project success.
The processes by which we have discussions about project processes must be based on probability and statisics. Every project is subject to aleatory (irreducible) and epistemic (reducible) uncertainties. When we talk about cost, schedule, and technical performance are all statistical in nature.
Here's a book that should be read before engaging anyone in a conversation about the processes of project management, estimating, risk, performance management.
Coming soon Performance-Based Project Management.
The Principles, Practices, and Process of project success described with working examples in 256 pages. This is the full length version of Principles, Practices, and Processes of Performance-Based Project Management(sm) in 60 seconds.
These Principles, Practices, and Processes are applicable to all projectr domains and all development methods. They are Immutable.
There is a popular quote from George Box about all models are wrong, but some models are useful. This quote is many times used by people suggesting some new or innovative approach to a problem that has been around long time.
While this quote has a pithy ring to it, I'm almost certain those using the quote do so without actually reading the book where is was used.
In the early 1970s econometric models had been constructed for a number of countries using time series data. They were largely static, with responses to change assumed to take place within one period, irrespective of whether it was a year or a quarter.
The time series models of Box and Jenkins stood in stark contrast to these naive and static models. The Box and Jenkins used a single variable in isolation and dynamics played the central role. A few studies compared the two approaches and concluded that univariate time series models provided the more accurate short-term forecasts.
This was a turning point because it implied that dynamics were more important for understanding short-run movements than economic relationships as then understood. The emphasis in time series econometrics therefore shifted from modelling large simultaneous systems to taking account of dynamic interactions.
Box and Jenkins were influential not so much because what they said was new, but because they said it well. Their contribution was to show how the dynamic properties of observed series could be matched to those of theoretical models.
The Project Management Point
Models are a critical component of any credible forecast of cost, schedule, and technical performance. Without these models it is actually Guessing as so many critics of estimating are fond of stating. With credible models, forecasting becomes a tool used to increase the probability of project success.
So next time some self-proclaimed person uses Box's quote, ask if they have his book in the shelf and on what page that quote appears.
Chapter 1 of Maximizing Project Value introduced the idea of value. Chapter 2 speaks to where and how that value flows. A couple years ago there was confusion about the term value. Let's restate it here again. The value John speaks to is the business value. He speaks to Earned Value later in this book, but even more so in Project Management the Agile Way.
Chapter 2 Highlights
I've found what I was looking for in Chapter 7 that makes the book critical to our success - connecting Business Value with Capabilities Based Planning. I won't skip ahead. For now Chapter 2, is the starting point for putting these ideas to work.
I once thought it was not worth sitting down for a time as short as that; now I know differently and, if I have ten minutes, I use them, even if they bring only two lines, and it keeps the book alive.
I'm writing a book on Performance-Based Project Management. This quote has guided me in my efforts. Short, quick, directed edits to emerging ideas, one chapter at a time. Then off to the editor, back with markups, then a dedicated review of the content, themes, and narrative flow.
During the year I buy books, lots of books. Some on impulse, some with intent. Here's my list that has served me well.
There was a time when I didn't like the notion of "agile project management." Agile Software Development, sure. Been there, done that. Our group was one of the first to address the issues of agile and Earned Value Management Systems on government programs.
But "agilely" managing the project was outside the norm. This book show how to do that. It has case studies for real government projects and then a detailed presentation of the processes used or that could have been used for those projects.
There are some issues with the book, but certainty not series issue that are sometime found in books written by authors who don't have broad experience in the trenches of delivering product or service.
My review approach is a detailed assessment of each chapter from my marked up copy of the book. I'm on Chapter 8 of 22.
There are several shelves of books about many topics in our house. Project Management and related topics are in the Office. The list of books below have specific attributes. They have not only been read, they have been marked up, reread, and used in practice. I have many books that are read, but not marked up. Other books that have been read, marked up, but not put into practice. And a hand full of books that have all three attributes plus one more. The contents of the book has changes how I do my job.
There are other books that I've read, marked up, and concluded the content was either not applicable to the problems I work on, or in a few cases complete nonsense. By this I mean the content is not only not appropriate to the problems I work, but if applied will result in disappointment.
So here's my must have list. This list is not populist in nature. By populist I mean a book or paper in which you CANNOT calculate some outcome. A populist book is something to read if you are just coming to the topic and want to discover the lay of the land.The books listed here are nit populist books
This list is in no particular order, other than they were taken off the shelf in this order. One other attribute is if I know or met the author.
General Project Management
These books are about the general concepts of managing projects, including agile projects. They are from authors who are or have recently benn project and program managers. This is important for the simple reason that who wants to read about something from someone that actually doesn't practice what is in the book. By the way, project management techniques that do not address agile approaches are not that useful anymore. As well, authors with 1996 style credentials have likely been passed by the current approaches as well.
There are so many books on leadership in the project management space. I'm simply burned out listening to all the voices on leadership from folks who speak and write about the topic, but who have not actually lead people under circumstances that require real leadership. Here's the books that you need from those people who have.
In the aerospace and defense business Program Management is a Systems Engineering paradigm. This is because the technical architecture of the program has to be matched with the programmatic architecture. The product that is being designed must also be built and shipped. This means the value stream flow of work needs an architecture as well. This is the purpose of the Integrated Master Plan (IMP) and the Systems Engineering Management Plan (SEMP)
These books are the basis for being a good project manager. Here's a list of specific topics, meaning more technical, needed for project success.
There are lots of risk management books, articles, websites, and Bloggers out there. Here are the two you should own and read.
As an aside determining risk drivers is a critical success factor for any Risk Management process. Typically risk management means making lists of risks, ranking them, and doing some kind of handling. This is not only naive, but it is wrong. You must determine which risks drive which undesirable outcomes of your project. Start with A Framework for Categorizing Key Drivers of Risk and Taxonomy-Based Risk Identification. I worked with one of the authors.
Earned Value Management
There aren't really a lot of books about Earned Value Management. But there is a ton of misinformation about how EV is used, no used, applied, and misapplied. So these books and sources should be the starting point
There are other sources of Earned Value, even in the agile world. But care is needed. To properly use Earned Value you must be able to do several things:
If you can't do these, you shoulded be considering Earned Value for your project
Statistics and Math
Project managers need to know somethings about probability and statistics. All the numbers in project management, cost, durations, head count, technical performance are random numbers. In the absence of knowing how to use statistics and probability, you're going to be late and over budget before you start.
I've reviewed the book and attended a previous talk at the Colorado Springs PMI Chapter.
This time, I'm bringing my book for a signature.
If you are looking for the seminal book on how to manage a collection of projects, this is it.
I'm the son of a University Librarian. I'm a reader of books, all kinds of books, fiction, non-fiction, technical, science (biology and physics), journals (business, science, technical), and about half the time, books in my field. These include project management, cost management, earned value, government contracting and gory detailed stuff around program management.
Over time I've come to the conclusion there are two kinds of authors.
For some reason many authors in the agile business start their books and most chapter with a negative statement.
"Management has a hard time dealinig with change."
"All the waterfall processes are flawed."
"EV is Hog Wash."
These authors seem to have an axe to grind, and by God they're gonna grind in at every opportunity.
Other authors start with a baseline statement and add their touch,
"there's more to project complexity, than just the concept of complexity."
"One of the best ways to introduce Scrum is through a small group setting within an interested collection of developers."
As a trained proposal writer - one of the life changing jobs I've had - we learned that "down selling," is poor selling. Selling based on the problem, locks the problem as the basis of the sale.
"You can't get the CPR out the door, so you need us to help you."
Is factually correct, but it sets the tone on the problem rather the solution.
"We can provide you actionable information in a timely manner that increases the probability of your project's success,"
is my current "upward selling" tag line for our services.
I've written book chapters in science and engineering books, loads of refereed papers, and even loads more technical reports, and more proposals than I ever wanted to. The proposal writing is the hardest for the simple reason that the reviewer doesn't just comment of the likeability of the content. They award or do not award contracts on that likeability. It's the ultimate test of writing skills - you win the contract or you don't. You have to have 7C's for the winning proposal (thanks to the proposal school):
There are two books that describe how to manage projects with Earned Value. You can read about EV in a variety of places, but the principles are many time missing from these sources. Here are three books that not only provide the principles, they also define the practices.
Mario Vanhoucke provides detailed insight into managing projects with Earned Value. The key understanding for all successful Earned Value implementations is time is not money. The units of measure in Earned Value is money. Only money. OK, maybe some other simple unit like hours. But both time and money are not used together in Earned Value. This is both a problem and not a problem. It is not a problem, because the role of Earned Value to to show progress to plan in a stable unit of measures. It is a problem, because it is hard to speak about performance of the schedule, when we say we're $129,000 behind schedule. What is a dollar worth in time? It depends of course on the labor rate.
The main purpose of Earned Value Management, or any performance management system, is to provide actionable information to the decision makers early enough to actually take action to avoid unpleasant outcomes.
This is where Walter's book comes in. Dr. Vanhoucke provides insight into Earned Schedule as well, but Walter's book is the companion to Mario's. Earned Schedule is an approach to Earned Value - using the same data developed for Earned Value - to forecast the schedule performance of the project.
Both are needed, one is official in the US Government, guided by ANSI-748B.
The Earned Schedule metrics are time based they augment the Earned Value metrics (which are also time based in proper implementations). The detailed schedule analysis is the result. With the Earned Schedule Analysis, improvements in the fidelity of the performance forecast is possible in ways not found in Earned Value alone.
Why is it Important to Read Books Like This?
There are many opinions about the application of Earned Value and its cousin Earned Schedule. Most good, some just OK, some simply misinformed. Earned Value management is both simple and complex. Simple in that the measures of performance are just that simple:
That's it in a nutshell. Plan the work and the budget for that work. Execute to plan. Measure the percent complete with some tangible evidence, record how much it costs to produce that percentage of the work at the time I measured the performance.
The hard part comes from controlled the baseline for the work. It does no good to change the baseline for the budget, since that allows the percent complete measure to be stretched. Rubber Banding the Baseline is the term we use. The next hard thing is to define the budget for the planned work. If you don't what work you will be performing in the future, than you can't know the budget for the work.
But if you don't know the work you will be performing in the future, you've got a bigger problem. You don't know what DONE looks like. And if you don't know what done looks like, than you can't manage the project in any meaningful way. The only way you can management it is with the passage of time and the consumption of money. That means when you run out of time and or run out of money, the project is complete. That definition of DONE doesn't sound very pleasant when you spending someone eles money.
While I'm working my way through Management 3.0, here's two recommendations that will get to the point in rapid order, convey ideas in simple language without all the self referencing analogies, and be applicable to specific problems you may encounter on projects.
The Rocket Scientist book and related to the Martian Principles book are many ways more subtle than Management 3.0 and in other ways just plain blunt - do this is you'll be successful.
The Martian Principles book is about developing software at JPL for Mars landers, orbiters, and the Deep Space Network that supports them. This software is done in an agile manner, with emerging requirements. At the same time the software is subject to very high levels of formality. The software must integrate with a complex network of other software, all of which is emerging in parallel.
There are 19 principles are:
Sound familiar? It should. The development of Deep Space Network (DSN) based missions is all about agile development inside the rigor of spaceflight. But most importantly this book is about how to "engineer" the solution. None of the fluffy "it'll emerge" crap. Make it emerge. The customer doesn't know, so have a process that moves the customer down the path of knowing. We're build Billion dollar mission in an emergent environment.
The Rocket Scientist book is a step-by-step process of how to approach complex problems. This complexity is real complexity - engineering complexity. This process has some simple steps:
These sub elements of each chapter have working examples you can apply to your own projects. No philosophy here, no high minded principles, just plain old engineering and program management practices.
Both these books make an assumption that is critical to understanding how complex systems are delivered. They are delivered through getting the right people on your program, getting the wrong people off your program, having the best skills and experiences, and never ever confusing effort with results.
This means "we're here to build something of value, if you want to grow your career, learn how to be a better person, come to understand all the philosophical aspects of developing software for money, do that on someones else's program." I want fully formed engieers who can work together as a team - after some forming, storming, and norming processes for sure. But then behave like a team. Jon Katezbach's team
A group of individuals who hold each other accountable for a shared outcome.
I've been trying - I really mean it - to read Jurgen Appelo's Management 3.0 book. With lots of hype - much of it self-promoted - I bought the book and started reading. I bought John Goodpasture's book as well, skimmed it, saw what I wanted (EV and Agile), incorporated those ideas in my NDIA Information Systems Summit paper and moved on.
But I have to put Jurgen's book down after a few minutes. It just doesn't resonant with me on several levels. It's VERY and I mean VERY anecdotal. I get a visceral reaction to self referencing narrative. It's my science training, it's my mother's English professor training, it's my formal proposal writer training. Then there is the analogies that are likely very useful for many in the software development world. But my education, training, and avocation gets in the way - in a big way. I was a budding particle physicist. I wasn't a very good physicist, but I could write really good FORTRAN code for extracting signals way below the noise -60db. This type of software replaces or augments Lock In Amplifiers and other types of signal process algorithms.
So what's the problem with the book? Well the use of analogies that are flawed is somewhat OK. But about every 5th page there is a blatant - read bogus - analogy. The first one that caused me to close the book is on page 42. Jurgen says, "A double pendulum is also a simple system. It is easy to make and easy to understand. And yet, it undergoes unpredictable chaotic motion do to a high sensitivity to the initial setup of the pendulum.
First of all it is easy to make. But it is not easy to understand. The equations of motion for the double pendulum consist of four independent equations for two couple second order differential equations.
Here's the Wolfram solution derived from the classical mechanics texts every physics major has on his shelf 30 years later.
So what's the issue here? Jurgen uses the double pendulum as an example of "unpredictable" behavior. This is simply not true. The behavior is exactly predictable. The Wolfram tool solves those two coupled DiffEQs and even draws a picture. If you start the pendulum in the same place every time, it will follow the same path EVERY TIME. It has to, the double pendulum is subject to the laws of gravity, Newtons laws of the conservation of energy and momentum. That's it. The double pendulum is NOT chaotic, it is predictable. Now insert non-linear friction and its still predictable. Start it off in a slightly different position and the path is different of course. But that's just Newton's laws again. Freshman classical mechanics. OK, maybe is freshman can solve the Lagrangian for the two-body problem.
So now what? What does this to do with anything in the Management 2.0 book? Well a lot actually. The use or mis-use of analogies is at the heart of the book. The terms used to complex, chaos, emergent and all the other words used by the agilest are of course now suspect. This is not an evidence based narrative about Management 3.0. It is a personal journey through the analogies of how Jurgen thinks about complexity, chaos, emergence.
No problem, hell it's his book. But it gets better. The section titled Innovation is the Key to Survival, starts out sorta nice. But when I get to the 3rd paragraph (page 53) it all goes in the ditch. I know a lot about physics. I know some things about biology, our son is a biology guy. So when Jurgen says, "researches say that complexity - that interesting state between order and chaos - is the root of innovation in physics, biology, psychology, and beyond," I'd like to have some references. Because there seems to be a core misunderstanding about how physics works along with evolutionary biology (the current theory of everything in biology). OK, psychology I can see, since it's not really a science like physics is a science. Now these pages are interesting analogies, with some cool pictures, but they don't hang together when I got to the top of page 54 and the wonderfully misinformed quote, "innovation is doomed to fail when launched top-down program of special people assigned with the exclusive and difficult task of inventing something new."
Jurgen needs to talk to the guys at Boeing on the 787 and 777 assembling processes from the top-down steering committee, or the United Launch Alliance chief engineer on the top down processes for building stir-welded tank technology. These and dozens of other high profile, multi-billion $'s.
So here I am on Chapter 4 and I'm pretty much ready to stop. But I won't. I'll continue on. There is value in there. I'll keep looking.
The big up side is on Page 57, which I'm going to use directly on one of my programs. Jurgen claims this is the "best known" model, with no reference - typical. But I know the method, and I'm OK.
It's the model of creative process, the 1926 The Art of Thought, Graham Wallas and Richard Smith.
So in the end, the analogies that are used for the "emergent" systems. People are certainly the most complex of systems, but the speculation that this complexity is on other domains, particle physics for example is not founded on any fact. The Lagrangian in the example of the double pendulum is also the Lagrangian used to define the interactions of subatomic particles - Quarks, Lepton, Hadrons, and the assemblages they form up to molecules. Stock markets have no Lagrangian, neither do people. Software development probably doesn't have a Lagrangian in the way an ensemble of particles do.
So without the analogies that are inappropriate and sometimes just wrong and instead provide a foundation for the management of complex processes based on actual principles, the real value of the book would arrive 80 pages sooner.
I'll start using the items above, thanks for that. And I'll keep going looking for those nuggets that I know are in there.
I've purchased two "agile" books with "agile" in their title. I decided the review these two books in a previous post. I've had an interaction with both authors over the past years. Jurgen Appelo and John Goodpastuer each have a distinct point of view I find interesting for different reasons.
I started reading Jurgen's book with an anticipation of understanding his point of view. I know John from an exchange of ideas and his contribution to editing several briefings I have prepared for NDIA meetings.
I started with Jurgen's book. I got to page 47 and discovered why I have difficulty understanding his point of view. While Jurgen states
Some scientist have not so nice things to say about like us borrowing their scientific terms. They say we use scientific terminology without bothering about what the words the mean.
I know Jurgen would object to the direct application to the agile discussion, but it is insightful to his "world view."
This is all irrelevant actually. I stopped reading when I reached page 47.
I have two "Agile Management" books on my desk.
While these books have similar titles they have distinctly different approaches to the topic. I'm reading both in parallel and writing notes and comments for both in parallel. I'll write a book review for in my style of book reviews. The Handbook for Program Management, Agile Estimating and Planning, and Total Project Control are some recent examples.
I'm through Chapter 1 of each book, and will be posting the review(s) a chapter at a time.
There is a well worn myth in the agile community, that large complex projects are developed using waterfall methods, where all the requirements are defined upfront, (BDUF), rigid processes are used to execution the program and the outcome is defined before the project starts. This of course is great fodder to the replacement of the "devil" waterfall process with agile processes.
For anyone interested in how a program actually works, here a good book that can be found at the Air University Press book store. "The Development of the B-52 and Jet Propulsion: A Case Study in Organizational Innovation," Dr. Mark D. Mandeles, Air University Press, Maxwell Air Force Base, Alabama. March 1998. The Air University Press has many books on management, leadership, strategy, and history.
Quoted from the preface:
The B-52 and Jet Propulsion: A Case Study in Organizational Innovation is a coherent and nonpolemical discussion of the revolution in military affairs, a hot topic in the national security arena. Mark Mandeles examines an interesting topic, how can the military better understand, manage, and evaluate technological development programs. We see Murphy’s Law (anything that can go wrong, will go wrong) in operation. No matter how carefully the military designs, plans, and programs the process of technological development, inevitably, equipment, organizations, and people will challenge the desired expectations. Mandeles argues convincingly that recognizing the inevitability of error may be the single most important factor in the design of effective organizations and procedures to foster and enhance innovative technology and concepts.
The book focuses on the introduction of jet propulsion into the B-52. This case study illustrates the reality that surprises and failures are endemic to development programs where information and knowledge are indeterminate, ambiguous, and imperfect. Mandeles’ choice of the B-52 to illustrate this process is both intriguing and apt. The military had no coherent search process inevitably leading to the choice of a particular technology; nor was decision making concerning the B-52 development program coherent or orderly. Different mixtures of participants, problems, and solutions came together at various times to make decisions about funding or to review the status of performance projections and requirements.
Sounds like an agile project to me.
A few years back I came across an interesting blog - Rogue Project Leader. There are lots of self-proclaimed "project leaders" out there. There are lots of book authors that make claims about how they are the ones to follow, how their books are the "next big thing," and how they measure their importance by how fast their books and related ideas are being snapped up on Amazon.
Well Dan isn't one of those. Dan Ward is an Air Force Lt. Colonel who writes about a variety of things. Some about project management, some about things unrelated. Dan latest book is The Radical Elements of Radical Success, cover to the left. Dans other books are F.I.S.T. and the Simplicity Cycle.
Now these are not the high minded books we see passed off by those thought leaders. You know books that will change how you think about management, development, projects, or general principles of anything. They are down to earth books. So far down, that one is free, the others are under $20. All paper backs, all ready to read and put to work.
Dan's F.I.S.T is a compilation of articles from the pages of Defense AT&L. This is one of several journals from the Defense Acquisition University. Dan has an article in the current edition, titled My Big, Slow Fail. It may sound like I'm Dan's cheering section. It didn't start out that way. We had an extended "discussion" of sorts around the notion that Cost, Schedule, Quality (Technical Performance actually) could all be had in equal portions and the "faster, better, cheaper" (FBC) school of thought needed to be re-introduced.
My experience with FBC is through two spectacular failures of Mars missions. Two very expensive machines "bounced" on Mars during the NASA FBC days. In the end the discussion came around to the Domain and Context of FBC needs to be tightly controlled. Dan's counter example is the FBC article in AT&L. And the rapid deployment of MC-12, which provides real-time full-motion video and signals intelligence and allow military leaders to make battlefield decisions. The MC-12 might be considered an example of an "agile" project. But unlike those IT agile projects, the MC-12 is a fielded combat system which was "engineered" for a specific mission.
So all this leads me to the point - sort of. The radical Elements of Radical Success is a book I've order for our staff of a simple reason. Along with Dan's F.I.S.T, Radical contains advice from someone "walking the walk" of agile acquisition. This means for the Air Force "buying stuff from defense contractors." We're a defense contractor and are simple business strategy is "sell stuff to the defense industry." We sell Program Controls Services, but those who buy our "stuff" build "stuff" that Dan's organization buys.
It's just one happy selling machine. But lately the "buying" side of this machine is running a little low on cash - for all the right reasons. The "Boss" of this enterprise has put out the word that buying will now have to be cut back and when buying it'll have to be for very good reasons and that buying will have to take into account the current "agile" practices. For the IT buying community there is a "clear and concise" directive in NDAA Section 804.
All this leads me to the end. The NDAA 804, "Mr. Gates," the notion of rapid and agile acquisition, and the related rapid and agile development (MC-12 example) and Lt.Col Dan Ward's notions of F.I.S.T have all come together. The principles of Agile have come to roost in the defense community. A colleague and I gave a talk at the recent NDIA (National Defense Industry Association) titled "Successfully Integrating Agile and Earned Value Management."
This is the beginning of what is hoped will be the "mainstreaming" of agile concepts. Now I know many of the Agile leaders think they have mainstreamed the concepts already. But let me explain a simple fact. Follow the money. The IT budget for the US Federal Budget exclusive of DoD is in the many billions of dollars. For DoD the same. We're talking many many billions - money with a B.
So when there is talk of scaling agile to the enterprise, let's put that in perspective. A payroll system that pays 6.2 million people through 252.2 million GL accounts to the tune of $578B, a health care delivery system for active duty, reserves, and retired military with a budget of $29.243B. There's those pesky B's again. So if anyone on the planet needs agile its the US DoD and related agencies.
Now the agile we're speaking about, throught SecDef mandated (NDAA Section 804), and the acquisition community is starting to require, the same as "five guys in the same room with their customer?" Uh that's be a NO. But the principles of Agile are DIRECTLY applicable to the work in which I work. They are.
Ignoring some of the nitty language issues, who in this room (there were government and industry officials there) would NOT want to have these principles applied to their program?
The members of the audience included the leaders of the EV community, defense contractors big and small (we're small) and our hosts who manage the largest defense procurement going on today, with a planned acquisition of $238B (those B's again).
The answer in nodding heads, smiles (in our domain people don't smile that much) and later requests for the presentation materials, seemed to indicate No One would NOT want these principles applied to their program. We then revealed the "title" of this briefing page - THE 12 PRINCIPLES OF THE AGILE MANIFESTO.
So there we have it. The principles are there, all we need to do now is put them to work inside the FAR 34.202 and DFAR 252.234–7002., DoD Instruction 5000.02, Enclosure 4 Table 5. Defense Acquisition Guidebook, Chapter 11, Section 126.96.36.199, ANSI-748-B, OMB Circular A-11, Part 7, and NDIA EVMIG guidance.
And all this thanks to Dan's proding several years ago around "getting with the program and start thinking in F.I.S.T terms for the Billion $ procurements.
I've been on the road too much in the past 2 months. Between our office here in Denver and two client sites in Phoenix and Albuquerque, I've had time to catch up on reading. Here's some materials that have kept my attention: