Avoiding & managing downside

Much of our own history in IT and Systems projects, and the Skop.es Objectives Driven approach, is focused on maximizing the upside of projects, outcomes and meeting objectives.

There is however a less rosy side of projects, the downer side. A Harvard Business Review study indicates that one in six IT projects turns into a “Black Swan”, that is a project which results in negative outcomes (Black Swan measure: cost overrun of >200% and go over schedule by 70%).

A Genca study (report cheerfully named “Doomed from the Start?”) found that 75% of “business and IT executives and practitioners” stated that their projects were “Doomed” from an early stage.

A related study undertaken by McKinsey suggests that 56% of projects suffer cost over runs, and 47% benefits shortfalls, so perhaps IT execs are being realistic rather than pessimistic.

So whilst upsides are more enticing (and wringing value from projects remains an under-done activity), addressing downside is equally critical.

A good first step is understanding the causes of project failures. Helpfully there have also been plenty of studies done on the causes of project failures, and derived from those several Critical Success Factors (CSF) lists.

We have taken the next logical step by standing on the shoulders of those standing on shoulders of giants, and produced a CSF graphic that illustrates the success factors associated with mid-sized IT projects (those with a budget under $2m).

Critical Success Factors for IT and systems projects of USD value less than 2 million.
Critical Success Factors for IT and systems projects of USD value less than 2 million. Usage warning: this diagram is an extrapolation and is simplified.

In addition, breaking down risks into those over which you have some control (and are manageable) and those that are true externalities is a useful exercise when it comes to creating risk management plans.

Skop.es perspective

The Skop.es application strikes a reasonable balance in the identification and management of risks, because risk management is 100% overhead where risks do not manifest.

Skop.es therefore supports risk analysis and mitigation in a few innovative (and efficient) ways:

  1. Address unknown-unknowns: Providing lists of common risks – pick your favourites! Risks are often unknowns, so lists based on other peoples mishaps are better than making your own
  2. Supporting a structure for creating management and mitigation plans
  3. Creating visualisations of risks and impacts, ‘dinosaur in the wing-mirror’ stuff
  4. Actively prompting team members to periodically review / mitigate as necessary
  5. Reporting / tracking on risk related activities ‘in-project’

Get some governance

Governance is also a key risk mitigation activity. Engaging more and sharp eyes and minds to contribute and oversee projects is an excellent approach to both avoiding failures and maximising upside.

Others that have been there and done that, can shine light on unknowns both ‘in project’ and externalities within the organisation that team members may not be aware of.

Accepting less than perfect

The reality (as it currently stands) is that your project is very unlikely to be delivered ahead of time and under-budget. There are of course exceptions, and the head-in-sand approach is to expect that yours is one of them. There are smarter options though.

Here are a couple of suggestions, cheap tricks maybe, but none the less effective:


Including contingency (a timeline buffer and a secret stash of cash) will help you and the project cope the first set of unanticipated bumps in the road. The level of contingency can vary depending on many factors including your and your teams experience, and the project complexity. An additional key factor is the number of stakeholders and individuals involved or impacted.

Some use 10% as a starting point for considering contingency.

We are of course biased, but we recommend that you use Skop.es as well as putting in place contingency.

Managing expectations

An additional option is expectation management.  Whist expectation management should not be used as a tactic to allow for dramatic delays and issues (black swans), adding in healthy ‘margins for error’ can be helpful. Again, some use 10% as a starting point expectation management, for example the project schedule says 10 weeks, publish an expected end date of 11 or 12.

Expectation management is usually deployed as a technique for ‘managing up’. For example adding ‘fat’ to expected delivery dates, or being conservative with expected financial returns can be beneficial.

You can of course layer contingency and expectation management, although be aware this does not become a cyclical activity, where each layer of management adds a little more until there is more contingency and fat than project.