There is a notion that all you need for successful project management is a Budget. This is the notion put forth by some in the #NoEstimates community and repeated in a recent Harvard Business Review post of nearly the same title. This article raises several important questions, but misses the notion of project management as a control system.
As well it has several odd points.
- Breaking down projects to 1 to 3 days chunks is very domain dependent. It's a common mistake for agile and actually agile tools providers to assume that such a fine grained decomposition is even possible. The 44 day rule is applicable to our space and defense programs. Which says, the work for any tangible deliverable can only cross one accounting period - 44 days in duration. The principle is
- How long are you willing to wait before you find out you're late
- In A&D that's 44 days, even with agile development processes. The development cycles for enterprise class projects like GPS III OCX (Ground Systems) are not the same is 5 people in the same room with the customer building the web site for the warehouse.
- In Agile that's 1 to 3 days - assuming the work can actually be broken down to that small of chunks. Patching 54 SQL servers with the current update may take 8 days - now what?
- The notion that budgets are only needed for strategic decisions, ignores the very principle of microeconomics of software development. Value at Risk is the primary driver of how decisions are made. What are you willing to loose?
- The Budget is a target to steer toward.
- The actual costs to date and the estimated cost to complete and the estimated cost at completion are the management information needed to make decisions.
- Budget alone and accumulation to date are open loop control.
- The budget question for strategic decisions must be proceed by estimated cost and estimated benefit.
- Then you can ask do we have the capital for this project?
- Starting with the budget isn't the basis of delivering the needed capabilities.
- Defining those capabilities, estimating their cost - with the requisite variance, risk adjustments, and confidence intervals - can then reveal how much you need to budget for the work.
- Value can only be determined if we know the cost of that value. So estimating that cost provides information for determining if we actually can afford the value we seek.
- This is basic microeconomics - opportunity cost assessment of our spend.
- The variances in the estimates in some of the tables in the article are wildly wide. This would indicate lack of basic understanding of the problem and would not be found in any mature shop where estimating is a profession.
- Any statment of completing at or below a value requires we know the Probability Distribution Function of that estimator (the number we're trying to estimate).
- This is core probabilitic forecasting processes.
- The approaches in sofwtare development for making these estimates is well devloped, with mature and affordable tools, books, and papers.
Here's the core problem
The budget is an end of project - a target. It is - or should be if we're going to stay in business - a goal for the project to stay under. Anyone going over budget where I work, needs to have a good reason - and there are many good reason - so pick one. But they still need to have justification.
But the budget tells you NOTHING about your performance along the way. It's like saying ...
Our goal is to drive to Los Angeles from Denver (1,200 miles) with our two small children (we did this long ago) and not having any feedback about when we're going to arrive.
So when they ask when are we going to get there dad, my answer can't be, it's 1,200 miles from Denver to LA.
That'd be a nonsense answer to our children, just like it's a nonsense to the adults paying for our work. The actual answer is it's 1,200 miles from Denver to LA, we've made it to Grand Junction (on the Utah Colorado border) in about 8 hours, and we're going to spend the night in Las Vegas and then go on to LA the next day
That tells the kids in the back seat of the Suburban absolutely nothing. It's meaningless to know just the budget and not the progress toward that budget in units of measure meaningful to the person asking the question. And most importantly what is our Estimate to Complete (ETC) and the resulting Estimate At Completion (EAC)
So when it is asked how much is this going to cost? Or when will we be done? Then that's only one half the process. That establishes the end point of the path along the way to actually arriving at the destination.
The destination for the road trip is Disneyland for the two 12 year olds. For the project that destination is the need date, the budget, and the set of capabilities needed in the date and for the budget so the project can start earning it's keep by fulfilling the capabilities that are Fit for Purpose and Fit for Use.
But along the way we need feedback that we're actually going to arrive on budget, on time, on spec. Let me say now, that projects without deadlines, budgets, and needed capabilities can't be very important to those paying for the project.
So What Do We Need for Project Management - Feedback?
We need measures of progress to plan. That's nice. But we need to know what SHOULD the performance to plan be at this point in the project. In the driving example, what speed SHOULD we be going at to arrive at Grand Junction in time for lunch and a potty break?
The answer is the knowledge that Grand Junction is 118 miles from where we are now. Once we get past Eagle Colorado, the expected speed on I-70 is around 70MPH average we'll be there in 1Hr 44 Minutes. Because that average has variance. Lots of variance. Google knows about this variance, because it has captured the time over distance numbers from all the cars driving on I-70 using their smart phones and can provide an estimated time of arrival from all that past performance.
If you didn't know, this is how Google Maps makes the road lines RED when you look at your map. It's from all the cars traveling on that route and their individual performance. Used to be there were sensors in the road. They stopped that and got it free from Google and their data scraping from the wirless providers.
OK, Back to Our Project Management Problem
We need a budget - the funds to cover our expenditures to produce the expected value at the end of the project - our spending goal. And a schedule and a set of capabilities to go along with that budget. And we need to know our progress to plan and the REQUIRED progress to plan to stay on plan. And the rerquired spend rate to arrive at the end at or below our budget and on or before the need date of those deliverable to produce the value.
This is called Close Loop Control.
Without all three of these elements is called Open Loop Control. And don't listen to anyone telling you otherwise, because they weren't paying attention in the Control Systems Class in engineering school and they missed reading a book on control systems.
My favorite, since it was the text I used in grad school - 1st Edition, which I used to write the Root Locus solution - in FORTRAN 77 - for a position holding control loop for an orbiting vehicle. Where starting on page 7 it's provides the reader with the core concepts of open and closed loop control. Let me bore you with some actual details about how control systems work for this book
Feedback Control Systems. A system that maintains a prescribed relationship
between the output and the reference input by comparing them and using the difference as a means of control is called a feedback control system.
An example would be a room temperature control system. By measuring the actual room temperature and comparing it with the reference temperature (desired temperature), the thermostat turns the heating or cooling equipment on or off in such a way as to ensure that the room temperature remains at a comfortable level regardless of outside conditions.
Closed-Loop Control Systems. Feedback control systems are often referred to as closed-loop control systems. In practice, the terms feedback control and closed-loop control are used interchangeably. In a closed-loop control system the actuating error signal, which is the difference between the input signal and the feedback signal (which may be the output signal itself or a function of the output signal and its derivatives and/or integrals), is fed to the controller so as to reduce the error and bring the output of the system to a desired value.The term closed-loop control always implies the use of feedback control action in order to reduce system error.
Open-Loop Control Systems. Those systems in which the output has no effect on the control action are called open-loop control systems. In other words, in an open loop control system the output is neither measured nor fed back for comparison with the input. One practical example is a washing machine. Soaking, washing, and rinsing in the washer operate on a time basis. The machine does not measure the output signal, that is, the cleanliness of the clothes.
In any open-loop control system, the output is not compared with the reference input. Thus, to each reference input there corresponds a fixed operating condition; as a result, the accuracy of the system depends on calibration. In the presence of disturbances, an open-loop control system will not perform the desired task. Open-loop control can be used, in practice, only if the relationship between the input and output is known and if there are neither internal nor external disturbances. Clearly, such systems are not feedback control systems. Note that any control system that operates on a time basis is open loop. For instance, traffic control by means of signals operated on a time basis is another example of open-loop control.
I've bolded and underlined the words above to make a point. Using the budget only and even with empirical data from past performance to linearly - since the underlying stochastic processes of the past are not used - to foecast the future is not Closed loop. It's Open Loop.
There is no error signal calculated from the current performance compared to the desired performance to determine what corrections are needed to arrive on-time, on-budget, with the needed capabilities in hand. Here's a summary of these concepts.
- You need the intermediate targets - where SHOULD we be at this point in time of cost, schedule, and technical performance of our needed capabilities?
- You need the measure of progress to plan in these units, not the passage of time or consumption of money.
- You need the error signal between Plan versus Actual to take corrective actions, forecast the EAC and ETC and determine the probability of showing up as planned for the planned budget with the needed capabilities.
And since those planned performance and the needed performance are probabilitic variables, you need to estimate what performance and its variance, is needed to stay on plan or get back on plan.
You need the Estimate To Complete and the Estimate At Completion
to determine if the project is going to turn out as expected for those paying for your work. Anyone one suggesting otherwise needs to go back to there control systems class and reread the control systems book.
Now if you work in a domain where these things aren't that important, or the value at risk is low enough sos those providing the money and waiting for the results don't really care if you're late, over budget, and deliver less than needed - then you can proceed to manage the project Open Loop - no one cares.
