We challenge project managers to think more broadly about the skills and approach they need to be truly effective in the role.

Process plays a crucial role in improving safe governance of projects. However, it should not become the project manager’s ‘comfort zone’.

Let us take the example of managing conflict in projects.

Project managers sometimes choose to avoid conflict in projects. They may recognise disagreement over the problem being addressed, the objective or the benefits of a project. However, sometimes project managers may feel these conflicts are intractable, or beyond their capability to resolve, or just ‘too much hard work’.

When this happens, project managers try to compensate for a lack of stakeholder agreement with process, producing a comforting array of technical documentation and gateway sign-offs. However business requirements documents, architecture designs and other project paperwork will not solve an essentially ‘political’ problem: if left unresolved it will eventually resurface as a bigger problem later.

In these circumstances what would be a better approach?

Working with the sponsor to reach the resolution of the underlying conflict? Ensuring that the project can move forward on firmer foundations? Securing senior management support for the project mission?

This requires the project manager to get out of their comfort zone and take a more business outcome focused approach. She or he must approach the project ‘from the outside in’ – talking to the business about strategic outcomes and business issues first, rather than solely concentrating on technical delivery.

How can you, the project manager, gain such insights and skills?

At CITI we advocate that you take up opportunities to project experience a variety of business environments.

This does not necessarily mean that you should ‘job-hop’ from company to company (there are great advantages in building up a supportive network of stakeholder allies over time) but it certainly means refusing to be type-cast as an ‘expert’ in a single technical field. You should not pursue greater depth of technical knowledge (and be aware that this is a tempting comfort zone). Instead you should seek to develop your understanding of business issues, perspectives and language.

If you experience a variety of business project challenges, and learn not to rely on deep technical knowledge, then you will be able to engage your stakeholders much faster engagement and communicate with the business more effectively.

That is why at CITI our assessment tools (used to recruit and develop project professionals) examine attitudes and experience as well as process skills and knowledge.

Types of white elephant projects
These generally fall into the following broad categories:

• those projects which deliver a technical solution that doesn’t work as intended,
• those that deliver a working solution that that nobody particularly wants to use, or
• those that deliver a working solution that delivers no added benefit.

Public or private sector failings?
Paul related two stories to me of two recent highly visible public sector failures – very large UK government IT projects that have failed or are failing.  I pointed out that in my experience across a wide range of public and private sector clients in the last decade, the problems can occur anywhere – it’s just that we get to read about the failures of our governments who are obliged to report to Parliament, while we are less likely to hear about the foibles of private companies.

Why?
Having said that, Paul, asked me for my opinion on the examples below.  What went wrong, and how could we prevent these happening to our clients:

£500m – e-Borders programme
This failure is rather well summarised in a recent Daily Telegraph article in the Telegraph headlined “Government IT projects fail because of politicians, not programmers” where the author identified a host of reasons why this Home Office programme failed.  Chief among them were that the requirements were not captured, and the project was planned on the basis of poor assumptions.  For example:

• When the system was ordered in 2007, no one in government realised that the objectives were illegal under EU law
• The pilot was only tried at airports and it was assumed the system would work at ports and the Channel Tunnel.  It didn’t.

See http://en.wikipedia.org/wiki/E-Borders for more detail.

£10bn – NHS Connecting for Health programme
From its inception in 2003 it was realised that this was a large and significant technology programme, quoted as “the world’s biggest civil information technology programme”. 

In such a large and complex IT programme run over several years, it is impossible to isolate a single point of failure.  Reservations were being raised as early as August 2005, and the programme was not cancelled in July 2011.  However, two points are uncontestable:

1. Scope of the programme was huge – too  large to be readily managed by even the most experienced team
2. End-user buy-in was not managed, and support among stakeholders was consequently very  low: in 2008 two-thirds of doctors said they would refuse to have their own medical records stored on the system!

See http://en.wikipedia.org/wiki/NHS_Connecting_for_Health for more detail.

What can you do?
When Paul and I got down to discussing what can be done, It’s clear that there is no magic answer and expensive mistakes can happen to any company.  However, there are ways to minimise the chances of your project becoming a ‘white elephant’.

The online IT magazine 6 Strategies for Cancelling a Major IT Project raised a number of valid points for the IT project manager to consider, but at programme level there is a need for the business to ask itself hard questions.

1)      Challenge the desirability – too many unsound projects get nodded through without challenge.  Don’t suppress opposing opinions; on the contrary, invite people to demolish the business case, expose the assumptions, question the projected savings/increased sales.  Get those who are most affected to talk about the undesirable consequences of the project being implemented. Conflict at the beginning of a project journey is positive – it shows that people care, and it can save dissatisfaction at the end.

2)      Challenge the do-ability – size matters in projects, and where one can break a large an ambitious piece of work into smaller pieces, there is an increased likelihood of success.  Moreover, at a programme level, one needs to organise the projects so that they deliver benefits early and at controlled intervals.  Programme tranche planning allows the business to safely steer and even to stop a programme without massive wastage of investment.

There are many ways to achieve these two goals, primarily through

• project and programme initiation workshops, which are aimed at setting the right structures and direction from the off, and
• health-checks, which can be conducted at any stage of a project, to ensure that the course already set is valid and will lead to the desired outcomes.

These are often best conducted with the help of external experts – because it is often politically very painful to expose the failings of a project or programme.

The good news

Using the right tools and approaches, a project or programme can be restructured and set back on the path to success.  As an expert in this aspect of project and programme management, we have helped many clients benefit from early interventions to ensure maximum return on investment in their projects and programmes.

Your thoughts and views on this subject are welcome – if this article resonates with you, then I am particularly interested to hear about your experiences.