How to Handle Project Failures

Many organisations plough on with a project in the hope that the solution being delivered by their external IT partner will eventually meet their business requirements.

For IT partners or suppliers on the other hand they are faced with the challenge of trying to deliver the solution defined in the procurement phase and all too often clients with evolving business requirements.

The scenario then develops where the project team manage a complex change control process which sadly will have built in ambiguity as to which party will pick up the costs for changes, modifications, enhancements etc

Sadly at some point the relationship between the two parties deteriorates and the project is stopped and the respective parties call in their legal representatives. There is rarely any arbitration or cooling off process and at this stage the project is dead but the legal effort and associated costs is about to snowball

As a practitioner I have always assumed the outcomes of legal cases are kept out of the public domain as organisations rarely 'wash their dirty laundry in public' and so valuable lessons learnt are not available for the project management and business community therefore to review.

Having been involved in a recent legal dispute and acting as a project management witness for a Systems Integrator, I came across an interesting organisation called the IT Group. They specialise in IT disputes and one of their areas of expertise is addressing IT Failures

http://www.itgroup-uk.com/consultancy/it-outsourcing-and-project-failure-s

The IT Group have worked on a number of high profile project failures to help their client seek redress

• NHS Patient Records (NPfIT)
• Building for Schools Programme
• CSC outsourcing of IT for BAe Systems
• BT outsourcing of IT support for Essex County Council Vertex BPO contract for Westminster City Council

What would be useful for the Project Management Community is to identify the underlying causes of the above project failures but I am pretty sure many of us can take a good stab at a few e.g. NPfIT

The Cabinet Office ( I worked in this organisation 2009 to 2011 and was responsible for developing best practice and supporting failing projects) created the Major Projects Authority to oversee and more importantly reduce the risk of further high profile public sector project failures. When they looked at the DWP Universal Credit Programme they found;

'Universal Credit project set out to use agile methodologies, but this quickly foundered and was effectively scrapped'

Which beggars question why such a high profile project was not managed using established and suitable project methodologies such as MSP, PRINCE2 etc and the project gambled on using Agile techniques!

Sadly the public sector never learns the lessons and the following headlines to often appear

Margaret Hodge MP, chair of the Public Accounts Committee, said: "DWP seems to have embarked on this crucial project, expected to cost the taxpayer some £2.4bn, with little idea as to how it was actually going to work. Confusion and poor management at the highest levels have already resulted in delays and at least £34m wasted on developing IT. If the department doesn’t get its act together, we could be on course for yet another catastrophic government IT failure."

Surely there has to be a better way of managing projects and avoiding IT Failures?

Please feel free to post your comments on the BLOG site 

Another Project War Story - Managing Aggressively Led Business Projects

 As an IT Project Manager you are asked to take control for the delivery of a project which has seemingly already been defined by the business sponsor or business team. As you apply your professional approach to project initiation and specifically, start to undertake some due diligence you find out pretty quickly that all is not well. 

Then comes the challenge to meet with the business to explain that despite their seemingly good work to date and  enthusiasm to get things moving there is a whole set of issues that need to be properly addressed if the project is to be successfully delivered.

Common Problems that the Business Team fail to Identify:

·        Role of a sponsor: set out for the sponsor how they will support the project through the various project  stages

·        Establish an appropriate procurement contract with the supplier and ensure references are taken and ideally site visits are made to customers who are working with a similar solution  

·        Identify and name the available business and IT resources required to deliver all stages of the project

·        Create a solution architecture document which will act as a ‘blueprint’ and allow all IT partners to understand their role in the delivery of the solution

·        Invest in detailed requirements gathering workshops which will include the key business users and the suppliers both external and internal. Ensure the sponsor is involved in the gap analysis workshop so that key decisions can be made about delivery options

·        Commit time to documenting business processes

·        Run business led roadshows or conference room pilots to ‘socialise’ the emerging solution and to build user commitment across your organisation

The above guidance is most applicable in organisations where the business teams are driving projects and where the IT department is being treated as an internal supplier. Although I would always advocate that the business owns the project they must do so with due respect to the support and guidance being provided by the IT department.