There are three key elements of every project on the planet - Cost, Schedule, and the performance of the product or service produced by the project. Each of these has drivers. The connections between Cost, Schedule, and Technical Performance are not Iron as suggested in the Iron Triangle of a PMI view of the project. Instead, the connections are elastic, springy, flexible. But they are connected.
Drivers of the Three Elements
Cost is driven by:
- Labor - how many people do we have on this project?
- Materials - what's or raw material cost and what's the conversation rate for that material?
- When we spend money, how efficient are we? What's our efficacy of funds? Do we get - at a minimum - $1.00 in return for every $1.00 spent?
- What's our overhead rate, our fully burdened costs of labor and materials?
- What are the other indirect costs? Benefits, facilities?
These costs are themselves variable, as a function of the project phase, external forces for labor, materials, and overhead. But the cost variable starts with these.
The schedule is driven by:
- The irreducible uncertainties of the work being performed. All work durations are random variables. The shape of the Probability Distribution Function can be known, but the exact probability of occurrence of any one duration for any one task can not. So to protect from this uncertainty we need margin. Schedule margin, cost margin, technical margin.
- The reducible uncertainties are event-based. There is a probability that the material we order will not arrive as planned and we'll have a delay in our project and have to pay for labor waiting to start work. We can spend money to reduce or eliminate reducible uncertainty. There is a probability that when we test the new data-based server with the actual data, it will not perform as needed. We can spend money and time to test the scalability of the database.
- The capacity for work impacts schedule. We are not as clever as we thought. We are not as capable of working the planned number of hours as we thought. Our capacity of doing the work is impacted in ways we didn't think of.
Technical Performance is driven by:
- Unrealistic expectations of the Effectiveness and Performance of the resulting technology
- We have an unanticipated risk.
- Our solution doesn't scale, isn't as reliable as we need, is harder to repair, doesn't meet the technical, performance, or effectiveness goals.
So What Does All This Mean?
- The three elements of a project are not independent.
- One impacts others.
- Two impacts the third.
- There are constant tradeoffs.
- All elements are random processes, possibly known, sometimes unknown.
But for project success, we need to have several things in place. The random behavior has to be knowable. It can't be chaos. If it is chaos, the project will fail, because there is no corrective action.
The three elements need to be known to some degree of confidence.
- What's the target schedule.
- When does the customer need to outcomes of the project?
- What are the delivery times for the intermediate outcomes of the project, so the customer can look at them and determine if they are what was needed before it's too late to correct them?
- How much is this project going to cost when we're done?
- How much money will we need along the way?
- In exchange for this cost, what is the beneficial outcome, to offset the cost?
- This is the fundamental Return on Investment calculation ROI = (Benefit - Cost) / Cost. If we don't know the cost we can't know the value.
- We may know the cost because it is fixed, then we need to know the schedule and the value produced in exchange for that fixed cost and schedule in terms of capabilities.
- What are we building?
- Is it the right thing to build? How do we know? Do we have some Concept of Operations, a Statement of Work, or Statement of Objectives, sticky notes on the white, 3x5 cards, something that says what DONE looks like in units of measure meaningful to the decision-makers?
- How can we assure that what we're building meets the needs of the customer?
- What the Measures of Effectiveness that state the operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions?
- What are the Measures of Performance that characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions?
- What are the Key Performance Parameters that represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program?
- What are the Technical Performance Measures that are the attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal?
Do know these to some degree of confidence, you don't know what DONE looks. The only measure of progress becomes the passage of time and consumption of the money. It's unlikely any customer is going to be willing to pay you - at least for very long - to spend their money, without some understanding of Cost, Schedule, and the resulting Technical Outcomes.
The variables in the project or the product development process, are random variables, the their reducible and irreducible uncertainties creating risk to the probability of project success. Answering the questions above and the many other questions encountered in the business of writing software for money, require we make estimates of the outcomes of any decision that impacts the project or product. With these estimates, decisions can be made about the best path to take to increase the probability of success. By best it means the best with the probabilistic knowledge at hand.
Increasing the Probability of Program Success(project or product) must be the goal of every process improvement effort. When we hear of some new and untested approach to developing software in the presence of uncertainty while spending other people's money, ask how does this increase the probability of success in units of measure meaningful to the decision-maker. Rarely is that decision-maker the one spending the money.
Here's some background on how we think about this critical topic.
- Probability of Program Success, Acquisition Community Connection, Defense Acquisition University
- Probability of Program Success (PoPS) Acquisition Metrics Decision Support, Booz Allen Hamilton,
- Probability of Program Success Operations Guide, Acquisition, Logistics & Technology Enterprise Systems and Services, United States Army
