Software intensive project work is indeterminate. Many times, customers don't know what they really want until they see something working. Development's capacity for work is not well understood early in the project. Technology emerges and impacts the effectiveness of the project. Reducible and irreducible uncertainties abound. These conditions are normal, they can't be wished away.
So what are the options? Let's start with some advice and see what we can do to improve the Probability of Project Success. Wise leaders from the past have words we can use to guide our efforts.
I know one thing: that I know nothing
— Socrates
Ignorance more frequently begets confidence than does knowledge
— Charles Darwin, The Descent of Man
The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt
— Bertrand Russell
The fool doth think he is wise, but the wise man knows himself to be a fool.
— William Shakespeare, As You Like It
Welcome to Lake Wobegon, where all the women are strong, all the men are good-looking, and all the children are above average.
— Garrison Keillor, A Prairie Home Companion
Knowing nothing about the project is not good for increasing the probability of success. Knowing what capabilities are needed to fulfill a mission or business need is a starting point. Capabilities are not requirements, those come next. Capabilities allow the user to do something of value. This is the value spoken about, most times spoken about in the absence of any units of measure. These measures, the measure of capability is the Measure of Effectiveness. (The tool in the previous link is a systems engineering tool, that provides all project participants with clear, concise, and testable assessments of their understanding of what Done looks like. The notion that tools get in the way of success is ill-informed at best, and just plain wrong at worst).
Measures of Effectiveness are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in an operational environment, under a specific set of conditions.
They:
- are stated in units meaningful to the buyer or decision maker.
- focus on capabilities independent of any technical implementation.
- are connected to the mission success.
If we don't know what capabilities we want the project to deliver, it's going to be a low probability that the project is a success. We don't know what done looks like. Now we can get paid to discover these capabilities. Capabilities Based Planning is a process to discover these. Someone has to pay for this of course. It is usually the customer that pays. But someone has to pay.
With the needed capabilities in hand, we can make our first estimate for cost, schedule, and the probability of success. Here's an example. Frank Cepollina was speaking at the BAA (Broad Area Announcement) for the Hubble Robotic Service mission.
He stated his needed capabilities rather than in techncial requirements. Those always come after we know what done looks like. Notice these capabilities are mission capabilities. Get the job done descriptions.
- Do no harm to Hubble, it is very fragile
- Change the wide-field camera, it had failed long after its planned
- Attach the umbilical battery
- Attach the de-orbit module
How much does that cost and when can you have it ready to fly?
The three vendors needed to develop an estimate. The details of this process can be found in Assessment of the options for extending the life of the Hubble Space Telescope. This example can be extended to IT and software development projects. What do we want the system to do? Don't know? Go find out. Make that the first step in the project. Read Predictabilty: A Simple Approach to Creating Reliable Project Schedules, Steve Bockman for an example of how to think about this in a software development environment. No matter what our domain, size of project, we're going to need to understand something about what capabilities are needed for project success. We might be able just to start work and let these emerge. But our probability of success is unknown and that's not likely a good thing in the end.
So when we know something about the needed capabilities, we can start to discover the requirements. But first we're going to need some kind of measure for those requirements. These are performance measures.
These are measures that characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. These are Measures of Performance, and are:
- Attributes that assure the system has the capability to perform
- Assessment of the system to assure it meets the design requirements at satisfy the Measures of Effectiveness.
These are measure of how the requirements are going to perform in pursuit of the mission.
Final we have to discover the Technical Performance Measures. These are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. These:
- Assess the effectiveness of the design process.
- Define the compliance to the performance requirements.
- Identify technical risk.
- Are limited to critical thresholds.
- Include projected performance.
Here another need for estimating. How fast do we have to process transactions to meet the needed capability? How much can we weigh and still have the capability to fly? How reliable (mean time between failure, mean time to first failure, mean time to recover from failure), and still meet the needed capabilities?
These estimates are focused on technical outcomes. Thing that fly away, things that provide services in support of the customer. Things.
Where are we going here?
We must learn to estimate all kinds of things on a successful project. The credibility of our skills as project managers is always tied up with our ability to estimate. Can't estimate, choose not to estimate, see estimating as some kind of dysfunction, it is doubtful those providing us with money are going to have much confidence in our ability to deliver that mystical value we are told is part of all projects.
Estimating is part of project work. To not estimate, means we won't know what done looks like until we arrive at the end. That's unlikley to be acceptable to those paying us to do work.
The next step is to determine what requirements will be needed to implement the needed capabilities. These are defined as Measures of Performance that characterize physical or functional attributes relating to the system of operation, measured or estimated under specific conditions.
These are:
- Attributes that assure the system has the capability to perform.
- Assessment of the system to assure it meets the design requirements that satisfy the Measures of Effectiveness.
Notice something important here. Software project success always depends on development of working software. But what software, in what order, with what Technical Performance Measures, Measures of Performance, and Measures of Effectiveness all supporting the needed Capabilities.
Success doesn't start with coding. It's about knowing the answers to the CBP, MOE, MOP, TPM attributes. The notion of emergent anything works only when we can state in some unit of measure what DONE looks like. Without that we're just wasting the customer money exploring, challenging everything, and looking for the mystical Unicorn hiding in the bushes.
So Here's the Punch LIne
When we spend other people's money on our project, private money, public money, government money, they have the expectation of knowing something about how much much and when we will be finsihed with the work in exchange for that money. This is pretty much the case for every project I've ever worked for the past 34 years. It's the basis of every successful business - knowing what your costs are for the operations. So when we hear about developing software for money and not having any concern about the cost of that effort it simply doesn't make any sense.
