August 11, 2014

Staying on Plan Means Closed Loop Control

For most projects showing up on or near the planned need date, at or near the planned cost, and more or less with the planned capabilities is a good measure of success. Delivering capabilities late and over budget is usually not acceptable to those paying for our work.

So how do we do this? Simple actually.

We start with a Plan. Here's the approach to Planning and the resulting Plan.

Planning constantly peers into the future for indications as to where a solution may emerge. A Plan is a complex situation, adapting to an emerging solution. - Mike Dwyer, Big Visible

The Plan tells us when we need the capabilities to produce the needed business value or accomplish the mission. The Plan is a strategy. This strategy involves setting goals, determining actions to achieve the goals, and mobilizing resources to execute the actions. The strategy describes how the ends (goals) will be achieved by the means (resources) in units of measure meanigful to the decision makers.

Strategy creates fit among a firms activities. For Enterprise IT, this fit is defined by the relationships between the needed capabilities delivered by the project. The success of a strategy depends on doing many things well — not just a few.

The things that are done well must operate within a close nit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions.

As successful Plan describes the order of delivery of value in exchange for cost, the inter-dependencies between these value producing items, and the synergistic outcomes from these value producing items working together to meet the strategy.

With the Plan in hand, we can ask and answer the following questions:

Do we know what Done looks like in units of measure meaningful to the decision makers?

Do we have a strategy for reaching done, on or near the need date, at or near the budget?

Do we have the resources we need to execute that strategy?

Do we know what impediments we'll encounter along the way and how we're going to handle them?

Do we have some means of measuring our progress along the way to provides the confidence we'll reach done when we expect to?

This Post Answers the Last Question

The example below is from our cycling group. The principles are the same for projects. We have a desired outcome in terms of date, cost, and technical performance. These desired outcomes have some end goal. A budget, a go live date, a set of features or capabilities needed to fulfill the business case.

Along the way we need to take corrective actions when we see we are falling behind.

How did we know we were falling behind? Because we have a desired performance at points along the way, that we compare our actual performance to. The difference between our actual performance and the desired performance, creates an "error signal" we can use to make adjustments.

Out thermostat does this, our speed control on our car does this, the Close Loop Control systems used for managing our project does this. So replaces the cycling example with writing software for money. The Peleton for the desired performance of our work. In the presentation below, ignore the guy in the Yellow Jersey at the end. Turns out he's a Dopper and an all around bad person to his fellow riders and fans.

So let's look at a project example using the analogy of our cycling group, ignoring Lance.

We have a goal of riding a distance in a specific time. This can be a training ride, a century, or a Grand Fondo (timed distance for record).

We have instruments on the bike. Strava on the smart phone. Gamin on the bars. Both keeping track of instantaneous speed, time moving, total time. As well an average time over the distance.

We know, because we've done this route A 100 times before, or we know because we looked at the coure map, or we know because we have talked about the planned distance for the day - about how fats we need to ride - on average - to get back to the drive on a planned time.

Say we're out for our Saturday ride, which is usually a 50 to 65 mile loop from the driveway in Niwot Colorado to Carter Lake south of Fort Collins.

As a group we agree our average pace will be 20 MPH. Everyone has some way of measuring their average and instantaneous speed.

Over the course, it's never flat, some climbs and descents, change the flat land speed, but the average needs to stay at 20 MPH.

When one or more drop off the back, I'm usually one of those, we know what are average is. And instinctively we know how much faster we need to ride to catch up - pick up the pace.

But if we were actual racers riding solo - time trial or Triathlon, we'd look at our Garmin to see if we're going fast enough to get back on pace, and come in under our target time.

This example can be related to a project.

We have a target for the end — a target set of capabilities, with a need date, and a target budget

We have targets for all the intermediary points along the way — capabilities over time, budget over time.

We know our pace — how fast to we have to go, how much cost can we absorb, to make our goal of delivering the needed capabilities on the needed date, for the needed budget.

We know the gap between our pace and our needed pace to stay on track — with an intermediate desired performance, budget, number of features delivered, stated capabilities ready to be used, and the actual measures of these, we can develop a variance that is used to product an error signal that is used to steer to the project. This is the feedback loop. The closed loop control system we need to keep the project on plan.

From that variance we know how much faster we need to go to arrive on time.

This is Close Loop Control

Have a target for the end and we have intermediate targets along the way. These intermediate targets are the feedback points we use to assess progress to date

Measure the actual value of whatever variables we need to provide visibility to the project's performance. This can be cost, schedule, performance. But it can be other attributes of the project. Customer acceptance. Market place feedback. Incremental savings.

Determine the variance between the plan and the actual.

Take corrective action to close the gap to get back on target or get within the variance tolerance.

Repeat until project ends.

You're cruise control does this about every 10 milliseconds. You Nest thermostat does this slower, but still less than a minute. To know how often you need to sample your progress against plan, answer this question

How long are you willing to wait before you find out you're late? Sample at ½ that time.

This is called the Nyquist Rate, one of the starting point for all the process control software I wrote in my youner days for flying and swimming machines. But it's a good question to ask on all projects as well.

Comments

Staying on Plan Means Closed Loop Control

For most projects showing up on or near the planned need date, at or near the planned cost, and more or less with the planned capabilities is a good measure of success. Delivering capabilities late and over budget is usually not acceptable to those paying for our work.

So how do we do this? Simple actually.

We start with a Plan. Here's the approach to Planning and the resulting Plan.

Planning constantly peers into the future for indications as to where a solution may emerge. A Plan is a complex situation, adapting to an emerging solution. - Mike Dwyer, Big Visible

The Plan tells us when we need the capabilities to produce the needed business value or accomplish the mission. The Plan is a strategy. This strategy involves setting goals, determining actions to achieve the goals, and mobilizing resources to execute the actions. The strategy describes how the ends (goals) will be achieved by the means (resources) in units of measure meanigful to the decision makers.

Strategy creates fit among a firms activities. For Enterprise IT, this fit is defined by the relationships between the needed capabilities delivered by the project. The success of a strategy depends on doing many things well — not just a few.

The things that are done well must operate within a close nit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions.

As successful Plan describes the order of delivery of value in exchange for cost, the inter-dependencies between these value producing items, and the synergistic outcomes from these value producing items working together to meet the strategy.

With the Plan in hand, we can ask and answer the following questions:

Do we know what Done looks like in units of measure meaningful to the decision makers?

Do we have a strategy for reaching done, on or near the need date, at or near the budget?

Do we have the resources we need to execute that strategy?

Do we know what impediments we'll encounter along the way and how we're going to handle them?

Do we have some means of measuring our progress along the way to provides the confidence we'll reach done when we expect to?

This Post Answers the Last Question

The example below is from our cycling group. The principles are the same for projects. We have a desired outcome in terms of date, cost, and technical performance. These desired outcomes have some end goal. A budget, a go live date, a set of features or capabilities needed to fulfill the business case.

Along the way we need to take corrective actions when we see we are falling behind.

How did we know we were falling behind? Because we have a desired performance at points along the way, that we compare our actual performance to. The difference between our actual performance and the desired performance, creates an "error signal" we can use to make adjustments.

Out thermostat does this, our speed control on our car does this, the Close Loop Control systems used for managing our project does this. So replaces the cycling example with writing software for money. The Peleton for the desired performance of our work. In the presentation below, ignore the guy in the Yellow Jersey at the end. Turns out he's a Dopper and an all around bad person to his fellow riders and fans.

So let's look at a project example using the analogy of our cycling group, ignoring Lance.

We have a goal of riding a distance in a specific time. This can be a training ride, a century, or a Grand Fondo (timed distance for record).

We have instruments on the bike. Strava on the smart phone. Gamin on the bars. Both keeping track of instantaneous speed, time moving, total time. As well an average time over the distance.

We know, because we've done this route A 100 times before, or we know because we looked at the coure map, or we know because we have talked about the planned distance for the day - about how fats we need to ride - on average - to get back to the drive on a planned time.

Say we're out for our Saturday ride, which is usually a 50 to 65 mile loop from the driveway in Niwot Colorado to Carter Lake south of Fort Collins.

As a group we agree our average pace will be 20 MPH. Everyone has some way of measuring their average and instantaneous speed.

Over the course, it's never flat, some climbs and descents, change the flat land speed, but the average needs to stay at 20 MPH.

When one or more drop off the back, I'm usually one of those, we know what are average is. And instinctively we know how much faster we need to ride to catch up - pick up the pace.

But if we were actual racers riding solo - time trial or Triathlon, we'd look at our Garmin to see if we're going fast enough to get back on pace, and come in under our target time.

This example can be related to a project.

We have a target for the end — a target set of capabilities, with a need date, and a target budget

We have targets for all the intermediary points along the way — capabilities over time, budget over time.

We know our pace — how fast to we have to go, how much cost can we absorb, to make our goal of delivering the needed capabilities on the needed date, for the needed budget.

We know the gap between our pace and our needed pace to stay on track — with an intermediate desired performance, budget, number of features delivered, stated capabilities ready to be used, and the actual measures of these, we can develop a variance that is used to product an error signal that is used to steer to the project. This is the feedback loop. The closed loop control system we need to keep the project on plan.

From that variance we know how much faster we need to go to arrive on time.

This is Close Loop Control

Have a target for the end and we have intermediate targets along the way. These intermediate targets are the feedback points we use to assess progress to date

Measure the actual value of whatever variables we need to provide visibility to the project's performance. This can be cost, schedule, performance. But it can be other attributes of the project. Customer acceptance. Market place feedback. Incremental savings.

Determine the variance between the plan and the actual.

Take corrective action to close the gap to get back on target or get within the variance tolerance.

Repeat until project ends.

You're cruise control does this about every 10 milliseconds. You Nest thermostat does this slower, but still less than a minute. To know how often you need to sample your progress against plan, answer this question

How long are you willing to wait before you find out you're late? Sample at ½ that time.

This is called the Nyquist Rate, one of the starting point for all the process control software I wrote in my youner days for flying and swimming machines. But it's a good question to ask on all projects as well.