When it is mentioned project management is a control system many in the agile world whince. But in fact project is a control system, a closed loop control system.
Here's how it works.
- We have a goal, a target, some desired outcome.
- The desired outcome usually comes with a budget - some expected cost.
- It also comes with a time frame for achieving that desired outcome.
- That outcome usually - or should if we're doing it right - has a beneficial outcome.
Each of these elements has some unit of measure:
- Time - the day we need to deliver value or aa capability to meet the business goals or accomplish a mission. There can of course be incremental delievrables, but those also have a time element.
- Outcome might be he accomplishments of a mission or fulfillment of the business strategy
- Cost - there is no way to determine the value of anything without knowing its cost. This is the foundation of microeconomics. This can only happen - not knowing cost - by intentionally ignoring the principles of micro-economics. It's done I know, but Don't Do Stupid Things On Purpose.
Here's a small example of incremental delivery of value in an enterprise domain
The accomplishment of a mission or fulfillment of a business strategy can be called the value produced by the project. In the picture above the value delivered to the business is incremental, but fully functional on delivery to accomplish the business goal. These goals are defined in Measures of Effectiveness and Measures of Performance and these measures are derived from the business strategy or mission statement. So if I want a fleet of cars for my taxi service, producing a sketboard, then a bicycle, is not likley to accomplishment the business goal.
But the term value alone is nice, but not sufficient. Value needs to have some unit of measure. Revenue, cost reduction, environmental cleanup, education of students, reduction of disease, the process of sales orders at a lower cost, flying the 747 to it's destination with minimal fuel. Something that can be assessed in tangible units of measure.
In exchange for this value, with it's units of measure, we have the cost of producing this value.
To assess the value or the cost, we need to know the other item. We can't know the value of something without knowing its cost. We can't know if the cost is appropriate without knowing the value produced by the cost.
This is one principle of Microeconomics of software development
The process of deciding between choices about cost and value - the trade space between cost and value - starts with information about both cost and value. This information lives in the realm of uncertainty before and during the project's life-cycle. It is only known on the cost side after the project completes. And for the value may never be known in the absence of some uncertainty as to the actual measure. This is also a principle of microeconomics - the measures we use to make decisions are random variables.
To determine the value of the random variable we need to estimate, since of course they are random. With these random variables - cost of producing value and the value exchanged for the cost, the next step in projects is to define what we want the project to do:
- The desired outcome in the form of capabilities.
- The desired cost for the desired value.
- The desired time for the delivery of that desired value for the desired cost.
- The confidence that we can show up on or before the desired time, at or below the desied cost to delivery the desired value, and deliver the needed capabilities to fulfill the mission.
The actual delivery of this value can be incremental, it can be iterative, evolutionary, linear, big bang, or other ways. Software many times can be iterative or incremental, pouring concrete and welding pipe can as well. Building the Interstate might be incremental, the high rise usually needs to wait for the occupancy permit before the value is delivered to the owners. There is no single approach.
For each of these a control system is needed to assure progress to plan is being made. The two types of control systems are Open Loop and Close Loop. The briefing below speaks to those and their use.
- A desired outcome - the target budget, date, or some performance parameter.
- Measures of progress to plan - what has the project been doing to date? This should be measured in units of physical percent complete. Working software is a popular platitude in the agile community. But is it the right working software to fulfill the needed capabilities developed through a Capabilities Based Planning process.
- Variances between actual and plan - with the target outcomes, capture actuals and calculate variances. These variances are the information needed to make business decisions.
- These decisions are based not only past performance - the actual's - but future performance - the estimates of future performance given the past performance.
- This future performance must also be risk adjusted.
- Both the future performance and the uncertainties that create risks to this performance are statistical processes, producing probabilistic outcomes, that are integrated into the decision making processes.
- Take Corrective Actions - to keep the project inside the white lines. Using the past performance or cost, schedule, and technical outcomes, the assessment of variances, the role of management is to take corrective action to meet the desired outcomes of the project.
- The cost goals - we have a target budget that is used for assesing the Return on Investment or target product margin.
- The schedule goals - we have planned go live or release date that been communicated to the market or the customer.
- The Needed Capabilities - for the product (internal or external) to earn its keep.
- Adjustments - to each of these attributes required management action, assessment of this action to actually get back to GREEN, in our parlance, and keep the project headed to success.
- Monitor these actions against plan - once corrections are taken, management must still monitor the project to assure it stays on plan.
