• Project, Programme and Portfolio Management
• No comments

ESTABLISHING A POSITIVE CHANGE IN PROJECT COMMUNITY BEHAVIOUR.

If the project management lifecycle and processes have been well designed, so that they are simple to use while enabling the appropriate level of project control, then there will be very strong foundations to achieving successful project delivery. If these have been supplemented by simple templates and user-friendly software tools, then there is the potential to deliver projects efficiently. However, the time and money invested in creating the framework will have been wasted unless it is successfully employed. Worse still, of course, is that the organisation will continue to deliver projects with limited success. In this post I will discuss creating a successful project management culture.

It is extremely important to recognise that the organisation requires the behaviour of the project community to change and that people can be very resistant, so change needs to be carefully managed. The discipline of ‘change management’ deals with how to bring about changes to an organisation’s culture, which is too big a topic to be dealt with in detail within this blog post, but I would like to offer some useful guidance.

Applying Simple Programme Management

The ‘vehicles’ of change are projects and programmes. The subject of my blog is project management, but there are some principles of programme management that will greatly assist achieving successful adoption of the project management framework, and other initiatives that require changes in employee behaviour in order to be successful.

Before considering this, I recommend that the design of the lifecycle and processes is achieved as a project with a small project team applying project management principles. As there is no framework to work to yet, this will require an experienced and capable project manager. Similarly, the production of templates and implementation of software tools (if applicable) should be achieved as a project.

These projects (or combined project) should include definition of roles and responsibilities, provision of training and rollout to the project community. Alternatively, these could also be treated as separate projects. All of the projects could be included within a change programme, led by a programme manager accountable for successful delivery of the projects and the change being successful. However, for simplicity, and assuming that the organisation has low programme management maturity, I suggest the following change management activities are either treated as a further separate project or incorporated into the existing projects:

Identify the stakeholders

In order to work out how we are going to bring about the necessary changes in behaviour, we need to consider who will be affected by the change. These will be a mix of individuals and groups who will either assist or resist adopting new practices, depending on their perspective. For each stakeholder (individual or group), a strategy

needs to be formalised on how to involve them in the change process in a way that will align them to the revised way of working.

One option is to involve them directly in the workshops in which the revised practices (e.g. the project management processes) are being formulated. It is not usually feasible to involve everybody so directly, however, so providing a mechanism for involving more stakeholders in reviews of drafts is another option, preferably by presenting the drafts to them face-to-face, rather than simply issuing them out as documents for review.

The number of reviewers is also likely to be finite, for practical reasons, so other stakeholders will need to be kept informed of progress by being provided with regular updates. Again, this will preferably be done face-to-face whenever practical, so that these stakeholders also feel involved and can ask questions or voice concerns, but there may be a good case to provide some updates to selected (perhaps less influential) stakeholders as documents only.

It may be deemed that certain stakeholders are so critical to the success of the desired change that it is worth nominating an individual to be responsible for engaging with them one-to-one.

Create a Vision

The value of developing a compelling Vision is extremely underrated. Involving people in the process of deciding what a good future state of the business would like look is extremely powerful towards achieving alignment. Whether they were directly involved in the creation of the Vision or not, if alignment of the stakeholders to the end state is achieved, such that everybody who can influence the change has a desire to make it a success, it is a great start to ensuring this will be so.

A Vision should describe the intended future state of the organisation, in this case in terms of improved project management. It is most powerful when written in the present tense. It should not describe the change required, nor any references to the current state of the organisation, but simply provide an attractive ‘picture’ of the organisation when it is functioning well, in a way that is successfully and reliably delivering projects.

It is convenient to define a project management Vision as a short list of bullet points in terms of:

• Processes
• People
• Organisation
• Technology

Below is an example of such a Vision that can be used as the basis of an organisation specific version. I am not suggesting that it should be adopted as is, but rather used as an example of what should be developed with the stakeholders:

Define the Benefit Profiles

If, as I have suggested, improvement in the organisation’s project management is brought about through a set of projects, then a list of benefits should be included within a Business Case. Some benefits may be financial, while others may be non-financial (or at least not directly providing identifiably financial benefits). Whichever, it should be possible to define benefits that are measurable, so that they can later be judged to have been achieved, even if the measures are subjective assessment ratings.

Each listed benefit should be assigned to an individual within the organisation, who is responsible for ensuring the benefit is ‘realised’. The individual who should approve that it has been realised should also be identified. The following simple list of fields is therefore proposed for Benefit Profiles so that they can subsequently be tracked:

Plan and track stakeholder engagements

Based on the strategies decided previously, the activities to carry out the stakeholder engagements should be planned, so that tracking of these important tasks is possible just the same as other project tasks.

Some activities should be scheduled early on, to give stakeholders an indication of what is coming and why. Careful thought should be put into the various communications and they should be tailored to each stakeholder (individual or group). Early communications should also include content on why the status quo is unacceptable and how each specific stakeholder will be affected, focussing on the improvements from which they will benefit.

Plan and track benefit realisation

It is usually the case that most, if not all, of the benefits of a project that provides improved capability, are realised some significant time after the project has produced all of its deliverables and the project has been closed. It is therefore logical to plan the benefit realisation activities outside of this project, although the planning itself can be completed within the scope of the project.

The activities required to define the benefit profiles should also be planned, again so that these tasks can be tracked to completion, just the same as other project tasks.