I'm speaking at the ICEAA conference here in Denver (not on travel for once) on forecasting the Estimate At Completion (EAC) for large complex programs using Box Jenkins algorith. And the Cure for Unanticipated Growth in EAC.The notion of making estimates of cost, schedule, and performance of something goes back to the beginning of all projects. From the Egyptians to modern times. Projects that bend metal, projects that develop new life forms, projects that write software in exchange for money.
Each and every project on the planet today has three variables. These variables ae not independent. They are coupled in some way. Usually this coupling is non-linear, non-stationary (this means they are evolving) and many times unknown. These variables are cost, schedule, and delivered capabilities.
If these variable on the project are are UNKNOWABLE (Black Swans), your project is in the ditch before it starts. So let's skip that excuse for not estimating the three variables of the project. Another excuse we can dispose of is our clients don't know what they want. If this is the case, someone has to pay to find out what DONE looks like in units of measure meaningful to the decision makers. Don't have this information in some form, any form, that can be used to further the conversation? Your project is a Death March project on day one.
Modeling Random Variables on Projects
If we are managing a project, or a participant on a project, we should know something about the work we have been asked to do, the outcomes of that work, the relationships between the elements of the work - the hull size of a ship and the cost of the propulsion system. Or, the size of the hardware needed to handle the number of users on the systems.
But the first and most important thing to know is all variables on projects are random variables. If you hear we can't estimate because we can't know exactly what the cost, schedule, or capabilities will be, that person may be unaware of the underlying statistical processes of all projects. Projects are not accounting. They are decision making processes. Decision making in the presence of uncertainty. Anyone seeking certainty - a manager, a customer, a provider - is going to be serious disapponted when they discover all the project variables are random variables, with a Mode (Most Likley), a Standard Deviation, and higher order Moments, describing the shape of the Probability Distribution Function.
So here's a simple and straightforward approach to modeling our project in Excel. Let's start with some urban myths about estimating anything:
- Estimating is not guessing - guessing is not only bad math, it's bad management, and it's bad development. You wouldn't guess at how to size the table space on disk for your Oracle instance? No you wouldn't. You'd get to explain to your customer why you ran out of table space and the app crashed - ONCE. Then you'd have to explain to your customer, why they should keep you as a supplier or an employee.
- There is nothing new under the sun. We're not inventing new physics. I've worked in that job early in my career and we did invent devices and their software that required new physics - surface acoustic wave digital filters. Somewhere, someone has done what you have been asked to do. If you can't find them, you can build a parametric model of something that looks like you've been asked to do. This is the is it bigger than a bread box game. It's also the 20 questions game. Here's an example of How To Estimate Any Software Deliverable.
- Our Customers Don't What They Want - if this is the case you're in a Death March project. Buy Yourdon's book read it, Stop Doing Stupid Things on Purpose. If you've been tasked to be the steward of your customers money, time to behave like that. Inform them of the consequences of spending money without knowing what done looks like. You may be able to find what DONE looks like, but it's going to cost money. And spending that money on the project may be a true waste, since the customer will be spending money exploring while you are writing code for things that may never be needed to deliver those pesky Capabilities that produce the needed business value.
- We don't know how to estimate - That's acceptable. Many don't. It's a common situation. But saying we can't estimate, or estimating is a waste, or we can't forecast the future ignores a very large body of literature, books, courses, and tools that can be the foundation of learning how to estimate, that you can find here.
In The End, It Is This Simple
If you're building products or providing services using someone elses money, you are professionally obligated to provide some sort of understanding of the cost, scehdule, and probability of showing up with the needed capabilities. Since each of those is interconnected in some non-linear, non-stationary manner, with unknown, but knowable correlations between the lowest level work elements, assume a fixed budget and a set of past performance from measurements of work will provide a credible forecast of future performance is naive at best.