Mark Hayes, 2nd August 2019.

Controlling and Monitoring Solution Delivery Progress

In most cases, control and monitoring are one of the most expensive aspects of delivery, it goes without saying they should actually add value. However, as with conflicts of interest in respect to compliance, mentioned above, the same issues apply here. Think about the meaning of the words "Controlling and Monitoring". Doesn't "Facilitating and Monitoring" sound a lot more constructive?

The charts below provide two perspectives of the same progress data and demonstrate how easy it can be to miss what's actually going on. The solution doesn't just apply to progress curves but also to issue resolution. The key thing that gets ignored in monitoring and controlling is slippage.

Why aren't the Controls Working?

It's the Wrong People, Again...

The key issue here is that the wrong people are running the show.

As mentioned above, by integrating administration, compliance and delivery, and having them fall under the control of an administrator (such as an accountant), severe conflicts of interest are introduced.

So we get Packaged and Misleading Progress Reporting

This is the inevitable result of having the wrong people running a project. Given the difficulties, inefficiencies and conflicts of interest that result from mixing delivery, administration and compliance, any progress reporting will naturally be misleading. Replaced by packaging and "managed" expectations in the hope that by the time anyone notices, the project will have too much momentum to be stopped

Always Focussing on Today


(click a month to view its curve)

In the above somewhat simplistic example, progress to date and forecast to completion are reported each month as you might expect. However, the value of this kind of data is often lost, or hidden, by not making comparisons to previous periods.

If you click each month quickly, one after the other, you might notice the project is slipping. In reality however, this type of chart is usually reviewed monthly, in isolation, and unless someone senior has the good sense to compare them to previous versions, the slippage, and therefore loss of control, can go unnoticed.

This might not seem such a big deal but even a small amount of slippage each month can, if not resolved, result in considerable costs and delays.

More importantly, if slippage is occurring each month the project is clearly out of control. If the delivery date is not moving away, resources added or scope reduced, the reports are clearly fictional.

Assuming project headcount, for example, remains relatively constant from one month to the next, expecting to recover from previous repeated slippage, as well as continue development to meet original forecast dates, is naive at best.

Controlling

The idea that a delivery team can be controlled is a big mistake. When a "blockage" occurs, such as ambiguous requirements or unavailable resource, it must be cleared.

The problem is that most managers focus on redirecting the efforts of the developer as opposed to clearing blockages. This is weakness incarnate and a big mistake.

Instead of tackling the problem head on they schedule meetings, attempt to negotiate compromise and repackage the issue, often as a "challenge", to avoid possible conflict.

This is not control, this is no more than noise and interference. The list of "challenges" grows as does the time to resolution and, due to the myriad of dependencies found in complex solutions, the impact on other aspects of delivery grows exponentially.

The end result is a significant drop in both the efficiency of the delivery team and the quality of the deliverable.

Counter Productive Issue Resolution

The correct solution to a problem is almost always the one that is most flexible. Despite this, non-technical people are often frightened by flexibility as they think it's scope-creep in disguise.

Another negative characteristic of this type of delivery is that issues go unresolved for far too long. The person tasked with resolving a particular issue predicts resolution in, for example, a week yet the following week, does not deliver. This then goes on, sometimes indefinitely.

Now consider the impact this has on the team in respect to wasted time, flow and morale.

To listen to the same person, or people, week after week making the same excuses for the previous week, and promises for the next. This can be soul destroying, worse still the negative affects of repeatedly interrupting work-flow this way are cumulative.

For example, ask yourself how long does it take to answer the question or provide the detail. Then ask why do we have to ask repeatedly and why are we waiting days, weeks or months, for something that might only take the person we are waiting on minutes or hours. Now ask, what is the cost of repeatedly accommodating the delay.

The longer it takes to resolve such issues, the harder it is to get back up to speed when they are resolved. Worse still, in many cases the resolution impacts other aspects of the solution that have, or might have, already been completed.

In other words, the longer the path to resolution the bigger the cost, not just financial, but also in terms of quality and completeness.

As a consequence of this type of delay, a "manager" will often step in with a fundamentally flawed solution and insist it gets implemented. A box ticking exercise to hide the fact something is failing.

Mutating Scope

De-scoping is too often the standard approach to "catching-up".

Instead of tackling delays head on, negotiating extra resources or pushing back delivery dates, the reluctance to admit there's a problem results in supposedly less important, and often unrelated, areas of functionality being quietly removed from scope.

This not only devalues the final solution but makes a mockery of any attempt to cost, plan and manage. In the same way scope creep, not to be confused with filling the gaps in incomplete requirements, is also problematic.

Although often a necessity due to inadequate requirements, failure to acknowledge the impact of scope creep on resource burn will result in missed delivery dates, increased stress and failed dependencies. Scope changes require discussion, negotiation and agreement, all of which take time.