Change – That’s Just the Way It Is
Change is inevitable for any website or web application you maintain on behalf of a client. Such requests can happen for a multitude of reasons but for simplicity these can often be grouped into the following:
- Client or agency requested enhancement, often to solve a new business challenge.
- Reactive fix to solve a reported problem.
- Proactive fix to avoid or reduce the threat of a potential problem.
Changes may involve for example, changing, removing or adding code, upgrading software or hardware, integrating third party API’s or a hosting reconfiguration. Well to be honest absolutely anything and everything!
As a digital project manager you have to prepare for the fact that the brand spanking new quality website just launched, which you’ve repeat tested to the point of near insanity, will very soon change. Quite often I’ve known websites on ‘go-live’ day which have already amassed a backlog of prioritised new requirements.
Please don’t misunderstand me and assume I don’t like change. Not true, what I care about most is ensuring that the agreed level of quality for a website does not drop. Therefore what I’m not a fan of is impulsive unplanned change and the potential threats these can pose to the websites look, usability, functionality, performance and maintainability.
Change Scoping Document
For me, the preferred method for evaluating and approving a change is to ask a number of questions upfront and record and compile the answers in a Change Scoping Document [CSD]. These questions are loosely based around ITIL®V3 ‘Seven R’s of Change Management.
The most common questions I ask are as follows:
- Who is the point of contact that has raised the change?
- What is the reason for this change, detailing the specific requirements?
- What are the high-level Zebedee tasks required to provide the stated deliverables?
- What are the risks involved with this change?
- Are there any assumptions associated with this change?
- What is the plan to test and deploy the change?
- What are the client’s responsibilities necessary to successfully complete the change?
- What is the relationship between this change and any other changes?
- What are the forecast timescales to deliver this change?
By the way if some of these questions don’t work for your business, website or the specific change request in question then don’t just blindly answer them, but change them to ones which will provide value. For example if the change involves an additional third party you will also want to understand their specific roles and responsibilities. We also update the CSD to record exactly what code has changed after development for internal reference.
Collaborate
If as a project manager you are sat at your desk at 17:00 armed only with a strong coffee and thirty minutes set aside to ‘knock-out’ most of the answers alone, then I’m afraid you’ll be wasting your time. It’s only through fully embracing the mindset of active collaboration that the true value of this method for evaluating change will materialise.
DSDM’s® Principle 3 summarises perfectly the benefits of collaboration
“Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association. Collaboration encourages increased understanding, greater speed and shared ownership, which enable teams to perform at a level that exceeds the sum of their parts”
AgilePM® DSDM® Agile Project Management Handbook v2, p.20
At a minimum collaboration should involve:
- A client single point of contact that represents all the users’ needs and requirements affected by the change, and who also has the authority to officially approve the CSD on behalf of the business.
- Anyone in the digital agency team that:
- Will be directly involved in designing or developing the requested change.
- Can provide technical or commercial assurance when required.
- Could contribute ideas and feedback.
- If the change involves third parties then they too may be involved in your change evaluation.
By the way, the evaluation doesn’t have to be conducted as a single workshop involving everyone at once; quite often the CSD document is collated as a result of a series of quick meetings, conference/ phone calls, e-mails etc.
Benefits
The main benefits of this approach of evaluating website changes through asking the right questions in close collaboration and documenting, distributing and agreeing these are as follows:
- Reduces ambiguity, uncertainty and unpredictability.
- Minimises the risk of uncontrolled change or continuous unaccounted growth in the scope of the change, known as scope creep, which may delay the delivery date of the change request.
- Allows the client point of contact to determine if the level of risk identified is acceptable when compared to the benefits which they forecast the change will provide to their business.
- Provides the project manager and client contact with a firm foundation to confidently manage the change request.
- Fosters a spirit of empowerment, openness and creativity both with the client and the users they represent and also the within the digital agency team.
To summarise
If you’re a digital project manager and feeling a little apprehensive about a pending website change you are managing then I would recommend you start with this approach. I would also suggest afterwards that you review the change and record what valuable lessons, good and not-so-good, have been learnt in the process.
Personally what I find reassuring is that any approach which encourages people to collaborate openly and freely without criticism can only improve the overall quality of a ‘product’, be it a document, delivery plan, test plan or more importantly the changed solution.