- 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.
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:
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:
|The organisation applies a scalable standard project management framework to all of its projects across all of its business areas.|
|A set of project management processes is maintained that is easily accessible and easy to use.|
|The processes fit within a defined standard project lifecycle.|
|The processes drive standardisation, but include defined differences where beneficial.|
|The processes (and tools) are continuously improved based on on-going user suggestions, lessons learned from projects and periodic reviews.|
|The project community is highly competent in delivering projects, having received appropriate training in the project management framework according to their role.|
|All software tool users are highly competent in use of the tools, having received appropriate training based on their specific role.|
|As the organisation’s project management maturity continuously improves, the project community are kept informed of evolving processes, and retrained appropriately.|
|New employees (and those changing roles) are provided with appropriate training as part of an induction process.|
|Project managers are matched to projects based on competency versus size and complexity.|
|Individual personal development plans and rewards include links to project management performance and conformance.|
|The organisation has governance and support structures in place in order to optimise delivery of the organisation’s projects.|
|Standard (simple) definitions of roles & responsibilities exist for all project related roles (including support, assurance and governance), applicable across the organisation.|
|There is clear ownership of project management processes and tools (as defined in roles and responsibilities).|
|The software toolset provides easy access to all current project roles & responsibilities, processes, templates, reporting and guidance materials (with obsolete materials being archived out of circulation).|
|The software toolset provides easy access to all current and recently completed project data, deliverables and related documents (with historic materials being archived out of circulation).|
|The software toolset enables easy use of indicators, based on defined standard project performance and compliance criteria, that are included in portfolio reports.|
|The software toolset is robust by design and is maintained by an infrastructure support team, who carry out defined periodic ‘backroom’ tasks.|
|The underlying architecture and networking are such that all users experience satisfactory performance.|
|There exists a defined support structure that ensures timely resolution of user queries and issues with the software toolset.|
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:
|Title||A meaningful definitive description of this benefit.|
|Category||Financial / Non-Financial|
|Measurement||The means by which the benefit is measurable.|
|Value||A measurable value that the benefit should achieve.|
|Responsible||The individual who is responsible for ensuring the benefit is realised.|
|Approver(s)||The individual who is the authority to approve that that the benefit has been realised.|
|Status||In Progress / Realised / Approved|
|Date Approved||A record of when it was approved.|
|Notes||To record any discussion points.|
|Related Tasks||Reference to related tasks in the plan.|
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.