I'm working a proposal for a university client that is submitting on a sofwtare, hardware, and operations research project to a large research organization. The buyer has a budget in the single digit millions. The response to the RFP is to develop algorithms, build some hardware, and build a prototype flying machine to test out all these ideas. The needed capabilities are to show in the first phase, that the provider has the right ideas to get hired for the second phase worth mid-double digit millions.
The project is to discover what will be needed to convince the customer that the winning provider should be hired for the next research phase and the likely follow-on contract to build some number of machines using all the software and hardware from the winning previous phases.
So now comes the estimating part
The buyer wants to use agile while also complying with the acquisition processes of the domain, which are more traditional. With the target winning cost -price to win - the winning set of research outcomes and their formal deliverables - algorithms, software, hardware, reports, trade studies, recommendations, etc., a set of technical and science capabilities, some past performance algorithms, software, and hardware from previous research projects (this is a major university bidding on this) - the big question is what can we say in the proposal about why the customer should hire us? We can describe...
- The planned deliverables - all the reports, algorithms, software, and hardware.
- The capacity for work to produce the needed outcomes.
- The capabilities that would enable the follow on win through the assessment of the goodness of the results.
- This is typical of research projects.
- Our researchers can develop better algorithms, do better trade studies, produce more innovative designs and architectures, and do this with less risk then our competition, so hire us - we're good and you'll like the results.
So how are we going to answer these questions, stay within the target contract award, and contractual delivery date?
We're going to have to make estimates of many of the project variables long before the project is awarded:
- Our capacity for work.
- Our plan and its assessment showing the probability of completing on or before the planned time stated in the RFP, at or below the contract award value.
- The probability of delivering the maximum value (all the deliverables that will allow us to win Phase 2) at or below the budgeted cost with the planned time.
- The probability that the deliverables will be satisfactory to the customer and show that we're the winning supplier for the follow on work.
In this project, emergent, vague outcomes, innovative project for a technology suite that doesn't exist, we need to estimate cost, schedule, and performance if we're going to have a chance to get any follow on work.
So when I here, our customers don't know what they want. Ask if they have any sense of what capabilities they need to earn back the money they are investing. NO, then they're about to waste some money trying to find out. You can buy information or you can have some of that information already in your hand. Reference Class Foecasting is one way. Parametric estimating is another.
When I hear - our developers don't like to work toward deadlines, ask the customer if they have any deadlines? NO? then everyone start spending money, and we'll stop when we run out of money or time. YES? Then we'd better have some sense of our capacity for work, what work is needed to deliver the needed capabilities, and how we're going to measure our physical progress toward that deadline, while spending our customers money to provide feedback needed to take corrective actions. Without an estimate of the goal and our future capacity for work, there can be no closed loop control of the project.
When I hear - estimating is a waste, decisions can be made without estimating, or estimating is some how an evil fo software develop, run down the hall to the finance and accounting department and see if they have a sense of the Basic Rules of Business. NO? You're home free, start coding and spending, someone will come along later and tell you what they need, when they need it or maybe tell you to stop. YES? Then learning how to make credible estimates is straight forward. Tons of literature, books, and tools for most every domain, including software development.
Estimating is part of running any business that spends money, other peoples money or your own money in exchange for produced value. Making a decision in the absence of knowing the cost, schedule imapct, or technical imnpact is like driving in the dark with the lights off.
It can be done, but you don't know you ran off the road or ran over something, until it's too late. Those pesky estimating processes, that appear to be such a waste to the developers, are actually the lights that show what is coming down the road. They are the leading indicators of where you want to go, so you can steer toward the goal. The actual feedback you get from the past performance provides the corrective actions needed to keep in between the white lines, speed up, slow down, stop, reverse course or reconsider your plans all together. But you must know where those lines are, and how tightly you need to adhere to their boundaries.
In the end when it is conjectured that estimates are not needed in the software development business, ask that person if they are now or have ever been accountable for the P&L or Balance Sheet of a business. NO? Walk away, they don't have any notion of why estimating is a critical success factor to any business.
