me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference. – Saint Francis of Assisi (1182-1226)
Of the great saints, Francis perhaps sets the most
inspirational example of personal change and sacrifice. Born into a wealthy family, he lived a high life as a young man until taken captive during a war to defend Assisi. Emerging
a year later as a changed person, he sold all his possessions and devoted the rest of his life to serving others.
Accept the things you cannot change
As discussed in the Project Plan chapter, it is vital to properly plan your portal project and not to simply 'wing it'.
Through decent Stakeholder Analysis and Prioritisation, your should have a Project Scope that meets the business
need. From your pilot, you will have confirmed that delivery is feasible.
Resist the temptation, then, to make continual
changes and tweaks to the Project Scope. Have the courage of your convictions and 'stick to your guns'.
Frequent, unwarranted changes in direction are likely to demotivate
the team, confuse your stakeholders and cause costs to escalate. Where changes are also poorly thought through, there may
be an impact on benefits and/or delivery may not prove feasible (where not tested in a pilot).
Change what is not working, if you can
Having said that change for it's own sake is not a
good idea, there will clearly be occasions where controlled change has to happen if the project's objectives are to be met (e.g. where strategic priorities change or where a pilot proves a course to lack feasibility).
The wisdom to know the difference
Given that changes to scope or method may at times
be required, but that poorly planned change is unwise, it seems only logical to ensure that the wisdom of your governance is fully utilised in planning and approving change.
The Change Board
To avoid creating a separate bureaucracy (and to
allow for flexible and responsive changes), my recommendation is to have a subset of the Project Board responsible for approving any project changes.
Project Change should be a
standing item at the bottom of the (say monthly) Project Board agenda. If there are any changes to propose, then the members of this 'Change Board' stay on to discuss the
proposals, whilst the others leave.
Where changes need urgent discussion (and cannot wait for the
next Change Board slot) there should be a process for the review and approval of Change proposals offline (for example via email).
The Change Control Process
Changes arise because of an issue. For example, the company acquires a competitor, but the scope of the project didn't take account
of such an eventuality. Thus, a change is required to bring the new business into scope for the intranet.
Thus, every Change Request (CR) starts it's life in the Issue Log as an issue.
Once agreed the only way to resolve the issue is through a change to the project, the next step to assess the change for impact on costs and timescales, before bringing it formally before the
Board for approval.
In the panel right, there is a process map for change management and a single page template for impact assessment (suitable for presentation to the Board).
Don't overdo it! There are different degress of change. Small
changes should simply be packaged together and presented in a block. Similarly, larger changes that do not impact significantly on costs or timescales can be handled together. Stay focused on
the big ticket changes that really need discussing!
Some change requests will be backed by their own sponsorship and
funding. These may well need to be handled differently, in much the same way as they would be in the Steady State model.