Case Studies

- Articles

It’s not what you do, it’s the way that you do it

Sound advice on the best way to implement new project management software.

So you have used Evaluation Centre to help make a decision on which project management software solutions to review. But what approach are you going to take to arrive at the final decision?

It makes sense to use a straightforward scorecard, including all the key criteria that you require from the software, with all members of the decision-making team providing scores.

However, what is equally important is how you feel about the people you will be working with – the type of relationship that will be established with the software provider and what type of company they are. Ask yourself: can I really work with these people?

It is likely to be a different type of relationship when you are in the evaluation process (when you are more in control and the software provider wants to add you to its client list), compared to when you are a customer and in need of after-sales support. So make sure you undertake your due diligence thoroughly, research the product, obtain references – and preferably visit them – research the company, attend other demonstrations or user group meetings, speak to colleagues and check out their experiences.

Doing all this thoroughly takes longer, but can save you having to go through the disappointment and the same process again two or three years later when things have not worked out and hard-earned cash has been spent.

When considering these aspects, it is important to think about what happens when the software has been deployed, when something is not working as it should and the first support call needs to be made.

Ensure you know the process, the service level agreement and the escalation process. This is not negative thinking, it is merely protecting your potential investment and making sure you understand clearly what happens when something goes wrong – which inevitably it will do, at some point, as the perfect software solution has not yet been developed.

Change delivery team

You can have all the software you like, but if the people delivering the change have not got the required skills, the software will not make much of a difference. The leadership and composition of the change delivery team is therefore critical in ensuring the change is successful and the benefits of the investment are gained.

Personal experience suggests that companies attach significantly less importance – in terms of resources and time – to internal business change than to external client-facing change. If this is the case, then project failure statistics will continue to provide miserable reading.

To be successful, the leader of the change delivery team must be exceptional in offering the following combination
of skills:

  • Leadership skills – strategic thinking, communication, influencing/negotiating, stakeholder management, motivation, team building.
  • Management skills – planning and organising, time management/prioritisation, delegation, risk management, budgeting and resourcing.

In terms of project teams, a two-tier approach is recommended. Appoint an overall strategic change team, comprising a Boardlevel sponsor, change manager and key stakeholders, with the purpose of ensuring the change is on track and the identified benefits are achieved.

The second tier is the implementation team, led by the change manager (being the link between the two teams) and including people directly affected by the change who know the details of the processes and systems. Always include the softwareprovider on these teams.

The implementation team needs combined process, people and technology skills. If these people are not available in your organisation then you have to act and either put effort into developing them internally, recruit or outsource.

If you are going to develop the team internally this takes time. Identify your best people, set out a personal development plan covering a two-year period and highlighting the skills gaps, and invest in training and coaching.

Being a member of your professional body is important. It can keep you up to speed with developments and enable you to meet like-minded people, attend relevant seminars and workshops and continue to develop skills and knowledge.

If you outsource implementation responsibility, you must ensure you still retain significant presence on the change team. Your people know the organisation, the structure, the people and how things work; the software provider
does not.

Change or project?

In Project Magazine there was an intriguing discussion about the situation at the opening of Heathrow’s new terminal and what aspects should have been considered from a project, programme or change management point of view. The article highlighted the change readiness of the organisation, how individuals might have responded, and leadership of the change. It also highlighted stakeholder engagement, communication and risk management as key requirements.

I would like to suggest that everything intended to improve a business should be considered as business change, not just projects or programmes, with different scales of change being recognised.

In this way, you adopt a more holistic approach. Recognising the process, people and technology impacts of the change and linking the change directly to the business strategy puts the change – whatever its scale – into context and recognises its importance to the business.

Again, in a recent Evaluation Centre article, the difference between a project and a programme was discussed, with programmes being described as ‘big things that are designed to bring about a major business change’.

Instead of being concerned about definitions of terms that already provide a degree of confusion, I prefer to talk about business change and the scale of the change.

Treat the introduction of your project management software as a business change; consider the process, people and technology impacts – not just the technology ones – and you will see that the end result will be significantly improved.

Why people resist change When introducing anything new there is always resistance, the scale of which reflects the type of culture in the organisation.

There are those people who embrace change and can see how it will improve things; there are those who are unsure but willing to be persuaded that the change will be beneficial; and there are those who are uncomfortable with change (31% according to a PMP Research study) and wish to retain the status quo.

This scenario will apply to the introduction of project management software pretty much as it would any other software. People are worried about what it will mean for them, and therefore the benefits must be communicated early in the change and personalised to explain what is in it for them.

The change manager must recognise that resistance is only natural, plan for it and address it through active and frequent communication and by involving people who are affected by the change.

If people already have knowledge of the new software, then the transition for them will be easier, especially if they consider the new product to be an improvement over the existing one.

By undertaking stakeholder mapping and engagement early in the change process, you can communicate key messages and clear up any misunderstandings. Also ensure that you engage actively with any people who are against the change so you can describe the benefits and get them on board.

Learning from experience

Research has shown that non-technical reasons – in particular poor management and communication skills – are the major cause of change failures, rather than technical issues.

Recent PMP research (see the ‘Strategy/Market Research’ section of this Evaluation Centre) has found a similar story, with the need to re-organise processes and retrain people, and people being reluctant to change, being in the top five barriers to adopting a project portfolio management or professional services automation (PPM/PSA) solution.

In other words, focusing only on the software/technical aspects of the proposed solution will result in failure.

The PMP study also highlights that 64% of companies have never completed a pre or post-implementation benchmark for their
PPM software – does this surprise anyone? It means all those companies are not learning anything from their experiences, positive or negative, and are therefore very likely to repeat the same mistakes.

From recent personal experience, many ‘project management’ companies do not undertake systematic, regular reviews or postchange reviews, even with major business change. And if they do, any learning derived is either not recorded or not disseminated.

Is it any wonder there are still so many change failures if a simple process for learning cannot be deployed?

Recently, I recommended that a company should review a change that was not progressing well but which would provide significant benefits and help achieve a strategic objective of the organisation. Initially this recommendation met some resistance but the review did proceed – although two members of the change team could not attend.

During the review, it became evident that some good work had been done, but this had been completed very much on an individual basis and not communicated to other members of the team. Communication with stakeholders was lacking and there was no actual plan for the change.

The outcome of the review was positive and several key recommendations have been made to get the change back on track and address the issues.

Likewise, I recently facilitated a post-change review of a major software development, with feedback provided by the change team on five positive aspects and five aspects that could be improved. This was the first time such a review had taken place in the organisation regarding an internal business improvement.

The input from everyone on the team was excellent, with an open discussion and even a balance of positive aspects and improvement points, as it is too easy just to focus on negatives.

This learning is currently being documented and will be disseminated within the organisation, to ensure the positive aspects are absorbed into other changes and the same mistakes are not made again. This is not a difficult exercise to perform, does not take long, yet is extremely powerful and provides the basis for continuous improvement in the organisation.

In summary, companies should handle their PPM/PSA investment as a business change. You need to take an holistic approach, considering the process, people and technology impacts and undertaking regular reviews and a post-change review. That way you can spread the learning and even enjoy the experience!