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.

If you would like to share a success story – then please contact info@citi.co.uk or visit the dedicated area of our website here http://www.citi.co.uk/about-us/success-stories-shared/

However, innovation in the public sector is less about new products and more about improving efficiency and quality of outcomes. Innovation can therefore not only be linked to technological innovation leading to “Product Innovation”, but it can involve internal organisational processes and structures leading for example to new approaches to client services – “Client service innovation” – or new approaches to reaching clients – “Marketing Innovation” – or new methods for transforming information – “Information Innovation” – and so on.

The Publin report D20 introduces the concept of innovation in the public sector as a “…deliberate change (in behaviour) with a specific objective in mind “Innovation and change share a common DNA and in the public sector innovation and change are linked to improvements and novelty in systems, processes and products that add value to the public by allowing them to be more efficient and effective. In other words, innovation in public sector organisations involves the successful implementation of change.

So what can the private sector learn from the experiences of the public sector about the challenge of changing organisational structures, processes and behaviours?

Innovation examples in the public sector include: the use of new technology; the drive towards public-centric processes with the view to deliver simpler services and greater convenience; or the empowerment of staff and the public to better engage and participate in the design and implementation of new policies/services. To enable all these innovations to be successfully delivered in the public sector organisations we need effective change management methodologies and approaches.

Many of the barriers to innovation are common to both the private and public sectors; resistance to change, risk adverse cultures; centralised structures, internal politics, etc.

Some of the lessons learnt from the public sector innovations are:

1. Promote collaboration and collaborative working cultures within and across divisions and departments by identifying clear accountabilities and mapping (sometimes even creating) the cross-organisational interdependencies that need to work in order for the desired outcomes to be achieved
2. Beware that ‘fear of failure’ stifles innovation and change in organisations: in fact successful change organisations tolerate failure as part of learning, and growing change capability
3. Articulate an all-encompassing vision of what the change initiative will accomplish and align all stakeholders behind the vision
4. Capture all the expected benefits and the changes in the organisation that will realise the benefits and then establish the right metrics to monitor and track benefit realisation following the end of the change initiative
5. Smart individual and group incentives are needed to instil the desired culture. The most successful of these are about recognition of efforts and achievements, rather than financial reward.
6. Finally, be careful what you measure and what you reward, as this it will strongly influence behaviours, sometimes in unintended ways.

CITI, over the last 25 years, has developed and practiced robust and effective change methodologies and tools that enable change initiatives to be delivered successfully.

One of these models is the Change Diamond that assists organisations to view change through its different and inter-related viewpoints generating robust projects, programmes, and portfolios designed to bring the expected benefits into reality.

The Change Diamond takes a holistic view of the change journeys that organisations initiate; it is relevant not only for changes that involve organisational systems, processes and structures (the “hard” aspect of change), but also the changes that are needed in behaviours and organisation culture (the “soft” aspects of change) to enable change to be successfully embedded and realised.

CITI has supported many clients, from public and private sector markets, to achieve maximum value from their change initiatives and investment designed to bring innovations into the market place or introduce major technological change to enhance value to customers. It has done so by developing their programme, project, and change management communities.

Some recent examples to indicate the depth of our experience and support we provide to our clients can be found here http://www.citi.co.uk/case-studies/public-services/

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.

Now, nearly twenty years later, it may be timely to review whether the considerable investment is yielding an appropriate return. It would probably be equally useful to discuss, if not set, the agenda going forward.

Centres of Excellence

Conceptually a COE is simple; a focal point for the assessment, capture and sharing of the best of practices available in the discipline area with the intent of driving overall performance up. This is how world records keep getting broken and pioneering surgical techniques advance; ‘top-slicing’ talent rather than ‘bottom-slicing’ incompetence is the aim of effective COEs.

The difficulty is translating this ambition into practical day-to-day activity – who does what and under what authority? In providing guidance on this the Cabinet Office focused predominantly on the audit and review process offered under the aegis of the Gateway Review scheme. Whilst mention was made of improving delivery capability and performance this was relegated to a phase two activity once the COE had established a sound footing of review.

Sadly audit and review, the dominant themes of the Gateway process, do not add value; they simply guard against it being lost by reducing the likelihood of ‘downstream’ failure. To add value it is necessary to improve inputs to a process in advance rather than inspect the consequences post process. Outside the P3M community COEs that flourish identify best practice, analyse it and then effectively embed this into the future process – this is not about stopping failure but aggrandising success; growing excellence.

Arguably this is something that the phase one COEs were ill-equipped to achieve. The question remains; how many have effectively transitioned into phase two and started to realise their potential?

What’s working?

The main thrust of the original OGC remit, by some considerable way, was the introduction of a range of reviews. These have been widely adopted and have, doubtless (despite several high profile examples) reduced the tax-payers’ burden of cost in failed projects and programmes. Some have even moved visibly towards the attainment of phase two type capability improvement among the P3M community. We are eager to identify and discuss the promoters and inhibitors of this transition.

What’s not?

What still seem to be absent are any clear paragons of excellence. Have we seen a COE that has identified ‘best in breed’ practices and behaviours and established a reliable mechanism to disseminate them, effectively, into the wider corporate or national P3M community? If you can talk, from experience, about capturing such rewards you will have a keen audience.

There were floods last year, too. The Environment Agency described those floods (less severe than the current inundation) as a “100-year flood”. Presumably two in a row is a “10,000-year” flood event? Or perhaps the probability of occurrence isn’t a 1-in-10,000 (as local residents are suggesting) and more positive and long-term action is required.

Additional pumps have been brought into the area, and are pumping ten tonnes of water per second into the river Parrett.

The area between Bridgwater, Wedmore, Baltonsborough and Curry Rivel forms (within a bit) a square with sides ten miles long. If an inch of rain falls in that square (and that has happened a few times recently) it weighs 6.5 million tonnes – which at ten tonnes per second, will occupy the emergency pumps for almost 11 weeks running 24/7. That’s until mid-April. For that one inch of rain.

So when do we need a project, and when can we manage with business-as-usual activities? Business-as-usual used (until 18 years ago) to include dredging the Parrett and Tone rivers, but this was discontinued on the grounds of being not cost-effective. The reality is that there are no hard and fast rules for deciding whether a project is required. The risk (and therefore cost) of relying on business-as-usual activities (which in this case includes emergency pumping) is presented in sharp focus in the media, and is clearly regarded as unacceptable by residents. This implies that a project (perhaps to specify and let a dredging contract, but there are no doubt many proposals and even more opinions) would be required to bring about a new, more acceptable business-as-usual state that can be maintained by business-as-usual activity. We should expect that some form of stakeholder engagement exercise will take place in order to identify and consider the many options that will be put forward.

The cost of cleaning up should give an indication of the size of the budget, but this will probably be a weaker link than would be expected in a more commercial project environment, as it involves quality of life as well as bank balance.

The political aspects bring other forces to bear. Even if the Meteorological Office is completely certain that the odds are 1 in 100 that such events occur in any one year, the odds of now having three in a row – flooding next winter – are 1 in 100, and if no action is taken, and it floods again, ministerial (and meteorological?) heads might roll. The ‘do nothing’ option may very well not be an option, even if no effective action can be afforded. It may be that a number of measures are identified as being required (trapping water on higher ground, more pumping stations, better water-flow gauging, dredging, etc.) and the Environmental Agency will structure and implement a programme of work.

It is no longer the preserve of a self-selected group of devotees, but is now being discussed, and implemented, by CIOs and Change Directors in major organisations across a variety of industries where IT forms a major component of change programmes and projects.

There are copious sources of technical information about Agile available on the Internet, so we have little to add in terms of defining it – apart from issuing a health warning at the end of this article.
Agile is a sensible approach, mainly because it embodies some well-understood good practice.

There are several well-known endemic problems in the ‘traditional’ product development approach of developing solutions from a detailed set of requirements that have been defined and documented ‘up front’:

• Business priorities (and therefore requirements) change, and individuals change their minds as their understanding of the requirements evolves over time.
• Business representatives can’t easily visualise in detail what they need during abstract early discussions, so they tend to over-elaborate on requirements and ‘invent’ functionality – ‘just in case they might need it’. This leads to subsequent ‘bartering’ with the delivery team as the constraints of time, cost and quality bear down on the project.

At best, this approach results in some disappointment as the final product falls short of the initial (over-inflated) vision. At worst, the business has spent money on software that is neither relevant nor useful (see Figure 1).

In Agile approaches, the constant engagement of the business in shaping the requirements and the solution addresses these major problems head-on; however, this is not as radical an approach as some might argue. Back in 1983, Barry Boehm wrote a seminal report which offered sound advice for the conduct of IT projects, which foreshadows much of intent of the Agile Manifesto.

In other words, any approach that promotes engagement between the product developers and the business has got to be an improvement on the fossilised ‘separate tribes’ model that encourages bureaucracy, inefficient communication, delayed/poor decision-making and lack of ownership.

In short, Agile approaches have much to offer businesses trying to implement sustainable and beneficial changes. However, we conclude with a warning for those venturing into Agile…

Warning: Agile project management does not exist!

Agile is a philosophy and approach to the development of IT application systems, and this is not the same as the overall management of a project. To talk of ‘Agile project management’ is about as sensible as debating ‘hand-crafted strategy’.

This is not mere pedantry: it is critical to highlight that any IT application development approach needs to be embedded in a project management framework. Put simply: use of Agile does not remove the necessity to strategically manage and govern change.

This point is worth dwelling on for a moment because some more excessive ‘devotees’ of Agile argue that it radically changes the change management paradigm, and dispenses with the role of project manager along with much of the usual governance associated with ‘traditional’ projects.

This is a dangerous fallacy. Agile was never meant to ‘remove the shackles’ of governance, but simply to recognise that in modern business we cannot define all the requirements of change up front – in fact we usually start from a very vague understanding of what we really need – and therefore we should develop solutions in a way that gives us maximum flexibility to change our minds. We still need effective change governance to ensure that the impact of the change is understood, that it can be successfully integrated into business as usual, and that it will bring benefits.

In our next article we will discuss how we can identify where Agile can best benefit the business, and how to exert appropriate controls on projects employing Agile product development.

Subsequent article(s) will address the following questions:

• “Benefits: how can one gain best advantage from employing Agile methods in change projects?”
• “Governance: how do I ensure that the business maintains appropriate control over change in an Agile environment?”