Mark Hayes, 2nd August 2019.

Ways to Improve Control in Software Solution Delivery

Some of the best ways to ensure controls work effectively is to:

All of this needs to be done without introducing micro-management or administration (of any kind). Development teams work best through collaborative, matrix like structures. Larger projects that involve multiple teams, as well as smaller ones that just require a couple of developers and an analyst, all require direction and leadership.

This doesn't mean they must be "managed".

Honesty, Accountability and Transparency

All project reporting must be based on information that is visible and can be verified. In other words, don't just ask.

With administration removed from delivery, this need be little more than a simple task list, showing expected effort and percent complete. This should be maintained by the lead developer, as part of monitoring deliverables and leading the team, and each item signed off by the person performing the task when complete.

Once this is done the lead developer can review, approve or reject the piece of work as appropriate.

In a team that is properly managed and constructed, nobody should have anything to hide, the task list should be clearly visible to all.

Focus on Performance to Date


Everything in One Place


A quick glance at the chart above is enough to tell even an office junior that this project is clearly out of control. This kind of slippage, month to month, is a good indicator that the project needs to be rescued.

If the people in control had control, you would see the delivery date pushed back or an increase in resource requests. Repeated slippage like this leads only to bad things.

When a project is slipping, take immediate corrective action. Don't assume that the causes will magically disappear, or that somehow the team will catch up later. These things never happen.

Instead, identify the issues and tackle them head on. If they can't be corrected, realistically revise the plan as well as any costings and resource requirements. If the original plan was wrong, deal with it. It was likely produced in a rush or without sufficient information. In such situations the plan should have been delivered with caveats, if it wasn't the wrong people produced it.

Regardless of circumstance, politics and expectations, if a project can't be delivered to plan then the plan is a pointless and counter-productive overhead. In cases where projects require rescue, focus on the core items that should have been delivered already, drop the people responsible and then just get on with it. Avoid anyone that over-promises and try to ensure the teams culture is such that it's members are happy raising issues and being honest about what can be achieved over time.

Manage Slippage, Don't Try to "Plan" it Away

Being able to identify slippage early on allows the delivery team to react and, hopefully take action to compensate. However for this to work it must be possible to identify the actual cause and address what went wrong, without worrying about such things as office politics, feelings and finger pointing.

In most cases slippage can be attributed to things like:

All of these issues are easily addressed, hiding from them, repackaging or underestimating them only results in issue growth. Issues must be documented and public, include a root cause analysis, a path to resolution and a realistic assessment of what's actually possible and when. For example... If the requirements are lacking either:

  1. Reject them with a good explanation as to why.
  2. Accept them with the caveat that extra resources will be required for clarification during development.
  3. Accept them with the caveat that development will not start until they are acceptable. I.e. the delivery team takes them on and refines them with input from the customer where required.

For options 2 and 3, emphasise that User Acceptance Testing may require a lot more time and resource, forecasting will be difficult and no promises, in respect to delivery date, can be made at this point in time.

Dealing with issues as they arise prevents them having a cumulative impact on the rest of delivery. If an issue relates to quality, be it requirements, external dependencies or team members, make the necessary change. If the reality is that the resources are either not at fault, can't be changed or better facilitated, then clearly the plan is wrong. Correct it, without wasting the rest of the teams time discussing it, and move on.

An unrealistic plan can easily increase day-to-day overheads by a third, simply through talking about it. The fact is that many large projects are too dynamic to be planned out in detail.

The better approach is simply to cut the team the slack they need to get on with it, push the delivery date back (if possible), and focus on making it easier for them.

Stricter Scope Management

Almost any complex solution can be both over and under engineered. To avoid excess scope-creep and de-scoping it's essential that the importance of each aspect of requirements is clear. Additionally, that scope changes are defined, assessed and agreed as quickly as possible.

To state the obvious, if we have a deadline and limited resource we can only deliver so much. Therefore we must be able to agree what we will do with that resource. I.e. what's important, must be included and can realistically be delivered.

Scope management is important not just in relation to the deliverable, but also in relation to how a project is managed. Personally, I've worked on several large projects where such things as the projects structure, reporting requirements and change control procedures were changed more than once. In each case considerable resources were drained and no value was added to either the deliverable or delivery date.

In either respect, deliverable or management, clarity of expectation is not just about being precise, but about being consistent. Regarding scope, if something is not already in-scope then unless it relates to a critical omission, or new requirement, simply make a note about it and revisit it later.

Many projects waste a lot of time talking about scope without actually taking into consideration the time they are wasting talking about it. Even in respect to simple "nice-to-haves", it's not uncommon to waste considerable resources discussing and documenting them. Resources that would be better utilised working on the job at hand.

Manage scope by focussing on delivering what has already been defined in the requirements. If there's time and resource left when that's been done, then start looking at adding a few bells and whistles. When something does crop up that's not already in scope:

  1. Identify it's criticality.
  2. If it's not critical, shelve it.
  3. If it is critical:

    1. Discus it with the customer, if appropriate, and get agreement on what to do about it.
    2. Assess its impact on the rest of the deliverable.
    3. Prioritise it.
    4. Allocate or re-allocate resources accordingly.

  4. Get back to work.

Even in an iterative approach, the scope of a solution can be defined clearly in broad statements if the right questions are asked at the beginning.

For example:

Q. Will the solution be required to integrate with any other solutions in any way?

If the answer is "Yes" then such things as data exports and physical integration are in scope by default. If "No" then they are not, regardless of criticality, until the requirements have been changed appropriately.

Caveat: Scope Creep in Methodologies

Most delivery methodologies are perfectly adequate in the right context. They are just processes however, and like any process can easily become over engineered, cumbersome and polluted by unnecessary administration within a project.

It is also the case that the actual methodologies also fall victim to scope creep.

Agile is a classic example of this. Search for "Agile is Dead" on YouTube to see an excellent talk by Dave Thomas, one of the original architects of the "Agile" methodologies, explaining how it has been corrupted by administrators and become rigid and cumbersome.