Thanks to my 17,000 readers. It's been a busy year. Working on both the policy and execution side of large progams. Finished the book after 9 months work, coming in Feburary. The year ended with a focus on estimating and risk. The slew of mails, blog posts, and twitter exchanges is always a good indication of an important topic.
Here's a summary of the estimating topic
- Three kinds of uncertainty about estimating cost and schedule - while working late at the bar in DC our team came up with three sources of cost, schedule, and performance short falls. (1) We didn't know, (2) We couldn't know, and (3) We don't want to know.
- Risk Management for Dummies - risk management is how adults manage projects. I don't personally like the For Dummies book titles, but this one needs to be written.
- Missing Domain, Context, and Evidence in Many Discussions - this is a recurring theme and a recurring problem. Whehn someone says I apply this in the software domain, what software doamin, There are 100's. Without a domain and a context and actuall evidence to backup the discussion, get's going to be hard to have that discussion.
- Domain and Context King - there was a rant of sorts from a popular blogger about the trouble he experiences in his work. Statements about what can and can't be done. No domain or context of course. Here's some.
- It's an Estimating Problem, not a Problem with Estimating - those provides the funds for us to do our work need to know how much money, when to provide it, and when we'll be done spending the money to produce the value they paid us to generate. It's that simple. All the dancing around not estimating, drip funding, and other ways of avoiding the need to know how much ignore the fundamental principal of all business. Return on investment has cost in the denominator and the numerator. Ignoring that means your're ignoring the business. Ignoring that is not a formula for continued work.
Along with the estimating discussion is the discussion of project risk
- Black Swans, They Never Saw It Coming - the term Blacks Swans is tossed around in the project management domain, without much cconsideration for its source of actual meaning. The actual meaning is the problem we've now encountered is not knowable. If it was knowable, we would have done something about it or at least known it was possible. The mortgage crisis is called a Black Swan, but of course there were those that made 100's of Millions by shorting for bonds. They saw it coming, others choose not to. Same for major project failure. We don't want to know is the actual source of the Black Swan in project management.
- Big Systems and the ACA Site - there's a notion that big systems are somehow evil. In fact big systems are the norm these days. The management process for larger, which is the code work for non-trivial - projects is not the same as it is for other projects. It requires discipline and most of all a customer who has some clue of what Done look like in terms of needed capabilities. These capabilities has Measures of Effectiveness in units meaningful to the business or mission decision makers. The picture at the bottom of the post is an example. The ACA likely did not have such a picture.
- Why We Confuse Development Processes with Risk Management - it is common to state a software development with risk management. That works if the development method has all the steps of risk management, then its a risk management process too. But that's unlikely. The most common is someone says Agile is risk management. Agile - as a software development process - is not risk management. Risk management is risk management.
- A Fundamental Principle of Managing Uncertainty - here's the basic principles of managing in the presence of risk. These principles when added to a software development process can increase the probability of project success.
- Both Aleatory and Epistemic Uncertainty Create Risk - risk comes from uncertainty. Uncertainty comes in two forms. Reducible uncertainty. This is uncertainty we can do something about by direct action. Do testing, buy two instead of one thing, change the design. This uncertainty creates risk if it is not handled with direct action or doesn't have a reserve to handle the risk if it were to occur. This uncertainty has a probability of occurrence. The second uncertainty is irreducible. That is it's always there, it can't be made to go away. The only way to handle irreducible uncertainty is with margin. Weather delays, delays in traffic, uncertainty in productivity of the work force. Both cost and schedule margin can handle irreducible uncertainty.
Some other topics that were important in 2013 include:
- Quotes - around the topic of project management
- Planning - since planning is everything. You can't know what done looks like without a plan. It was popular in 2013 to listen to voices that said that planning was not needed. Let the project emerge. No problem. You have money for that? You have time for that? No, you better have a plan to show up on time, on budget, with the needed capabilities.
2014 opens with the continuation on the policy side with updates to integrate Technical Performance Measures with Earned Value Management and on the execution side of triage for major defense programs.
