skip to Main Content

Do you drive to the supermarket with the assumption that it is okay not to buy, let’s say, 20% of the items on your shopping list?

Alternatively, perhaps you prepare Sunday lunch and feel happy leaving out one or two items? You might even get ready for a holiday willing to take only half the clothes you need and put enough petrol in the car to get you 80% of the way to your destination.

You don’t do that? Then why do you accept it in an IT project? Building in a mop-up ensures:

  • A decrease in benefits
  • Overspend
  • Quality issues

Loss of benefits is easy to understand. Miss out some people and not only do you lose their productivity gains, but you commit to legacy hardware and unsupported software. Even more costly is missing out a group of people who are key to a business activity. At best new workarounds are required – at worst they may lose the ability to work with their colleagues. [for example, I once worked in a team left behind in a Windows/ Office update. We could open no attachments sent by migrated colleagues]

As we consider overspend, we have to be honest with ourselves. The original project budget will be spent on the lucky teams included in the scope. Anyone demoted to a mop-up phase will be the subject of another round of spending. The organisation then has the unpalatable choice of leaving a team behind or spending more money. And if you take the former route, the cost of running old systems grows. So you are going to be spending that extra money anyway. [for example, I have seen the decision to roll out geographically have a domino event on the upgrade of a system. Eventually leading to dual identities so that a group of people could work on multiple sites]

Quality issues are the most controversial of these claims. The mentality of ‘fix it later’ is contagious and I contend that a project team that is willing to descope, grows willing to ignore risks and issues. [for example, I mopped up after a project that used a tool to support readiness activities. But the tool didn’t work, rather than fix the tool the first team allowed people to opt out of the project. Many of those who opted out had no need for the tool, but the project team let it ride.]

So, if mop-ups are so bad, why are they common practice? I am afraid this is going to sound cynical:

The IT service industry depends on repeat work and mop-ups are the most lucrative of all activities

Because we accept mop-ups, we accept poor planning and we descope when the work is too hard

Organisations selecting service providers on cost drive the scope down to an assumed core set of activities

“It’s so bad that maybe the government should give up the ghost on trying to do anything and simply accept that multibillion [dollar] failures are a permanent part of the landscape,” said analyst Michael Krigsman, CEO of consulting firm Asuret and an expert on IT project failures – Computer World December 2012

The solution? Start right and be honest; every short cut taken will come back to haunt you (or the poor soul asked to recover the project)

Your business case must set out expectations explicitly. Including the systems to be decommissioned, the people included and the acceptable level of acceptable business disruption. Developing the business case will help you decide if you really can afford to leave part of the organisation behind.

Audit the environment against your assumed ‘standard’. Uncover and document the variations. Understand where all your people are and how they work – are they mobile workers, are they customer facing, do they have project deadlines? Understand the times of the week, month and year that can brook no disruption. Get to grips with the IT literacy of the target population.

Build project governance across IT, the organisation and third-party resources. Foster open, robust risk and issue management. Set up approval processes for the process and plans, and agree go/ no-go criteria. Make sure the responsibilities and purpose for data capture, recording, analysis and reporting are clear. Set data led performance targets.

Apply best practice to the project – you need good people, strong processes and robust data. Agree the Quality up front and ensure compliance.

Learn lessons. Use pilots for customer acceptance and to test your processes. Assess each activity and build improvements into the process.

This list holds no surprises, except the fact that very few projects do all this, let alone do it well. There is one more factor to consider – how well the IT project works with the business.

If your IT team seems to see the organisation as a necessary evil, something that has to happen so that IT exists, you are not going to do well. On the other hand, if your IT team builds relationships with the organisation, listens and responds, you have the potential for success. During every IT project, capitalise on this relationship, ensure contact at every level of the project, from steering group to specialists and their customers, and keep the relationship alive.

If you can do all this, my son, then you will avoid the phrase ‘let’s plan the mop-up’.

This Post Has 0 Comments

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back To Top