Often the only constant on your web team is change. Unfortunately those changes have the possibility of completely derailing a project. Changes to a website project’s scope cause adjustments in timeframes, effort, cost, and research. Most companies utilize project managers to mitigate these risks. However, small church web teams often do not have this luxury. This article will explore what scope changes are, how they occur, and how you can mitigate the impacts to your timelines and quality.
This symptom, sometimes called scope creep, typically occurs over time and in small amounts. The most common cause of this are phrases that start with “Wouldn’t it be great if we could…”. Adding even a small feature to a site after a project has started has the potential to cause major re-work. Page templates that have already been designed may need updated, page flows are disrupted, and experiences can feel disjointed. What does this really mean? Consider your pastor joins Twitter and now wants calls to action (CTA) placed prominently throughout the site. Where will those CTA’s exist? Is it subjugated to the footer, given prominence in the header, or just another item thrown into your side column? Then questions may spring up about other social media outlets; or worse, a previous effort that failed due to a lack of support. You can see how expanding the scope of a project can not only cause issues with how the website behaves, but can easily give rise to an onslaught of “me too” requests.
While it may seem like a good idea to reduce the number of tasks in a project, the same effects of scope increase can occur. By taking away random pieces of a project, you will affect random aspects of pages, page flows, and the site as a whole. An easy example would be an email newsletter sign-up. After the site had been designed, leadership realized that the church staff could not support creating or gathering content on a weekly or even monthly basis. However the original site design had the signup form very prominently displayed. Now a complete reprioritization of page components as well as editing the many places you wanted to mention the newsletter. In addition, your efforts for promoting it via social media need to be halted, as well as any ad campaigns you may have wanted to run. Even worse is that you could affect your offline efforts; such as editing the announcements in the bulletin and the new posters you ordered for around the church.
So despite reading the past two paragraphs, you decided to go ahead with that change in scope. That is perfectly fine as long as you do everything in your power to mitigate the risks. While you can rarely eliminate risks, you can certainly make them have less of an impact, or less likely to happen. A key ingredient in mitigating risks is information, which hopefully you have prepared in advance. Having tools such as a Content Strategy Document will help you remember and analyze what is supposed to exist on each page. Understanding this will inform you where those scope changes will have an effect. Other documents and tools related to content and your libraries can be used in a similar fashion to help you assess how risky your course of action is. I hope this encourages you to have the discipline to create these documents and the wisdom to use them.
In case you missed it, this first two paragraphs of this article are a word of caution for allowing scope changes of any sort to crawl into your web projects. The last deals with how to mitigate the risks of scope change. Many of the tools and documents I have mentioned in the past can be used to help you understand and better assess that risk. So if you have not accomplished any of these, please start now. Once you have them, I suggest utilizing them for when (not if) a committee or stakeholder tries to change the scope of a project.
Photo courtesy of Søren Faurby