Writing Scope

The idea of writing a scope document can seem like an insurmountable mountain of vagaries and subjective unknowns. There are several resources that talk about the importance of scope, particularly from an agency perspective. The definition of scope really sets the boundaries for the project. No matter how big or small the amount of work the scope allows all of the parties involved to start with a common definition.

Scope is a way for your stakeholders to validate that the requirements have been addressed and added into the scope of work. If something is pulled out of scope it is important to communicate with the stakeholder the rationale behind the exclusion. For example in a recent scope document my teammate and I pulled some work out of the main body of our scope document and added a new section for future considerations. We had already gathered the requirements necessary to complete the work so we left it there for the next round of work.

For the team they get more clarity around the breadth and depth of work that will be included in the project plan. One of the key goals of the team review is to provide an estimate on the work to be done. It is important to keep the team engaged throughout the writing of the document so that they are not blindsided by a something they aren’t expecting. Remember your team is going to be putting fingers on the keyboard you don’t want to alienate them early.

Among the many things the scope document is used for it also serves as a reference when questions come up from stakeholders. Therefore it is important to remove the vagaries and subjective unknowns as much as possible. For example if the stakeholder always uses a certain size for banner ads and always uses flash it would be a good idea to include that. On the other hand if there are no existing mechanisms for their banners this could be an open invitation for interpretation. More definition here may save heartache later on.

Project Process: Requirements Gathering

When it comes to project process I tend to shut down. My coworkers will attest to the fact that my eyes glaze over as I retreat to my safe place when this subject comes up. The fact that I’m not a raving fan of any particular process does not mean it isn’t important or useful.

To me one of the most challenging and strangely fulfilling stages in the development of a website is pulling the requirements for the project. The challenge comes from the delicate balance of validating assumptions vs. understanding requests that are unknown prior to the session.

I spend a significant amount of time understanding the project that is being requested. This involves researching the market trends and competition but also understanding the underlying business reason for the request. Once I am able to process the research I shift gears and do some brainstorming on my own as I wrestle with the assumptions and research.

Once I work through my personal brainstorm session I can visualize an end product. 99.9% of the time the product in my head does not become reality, but it is part of the process of preparing for the requirements session. From here I look at the development schedule and prioritize what I want to get out of the session so I can maximize the time of the participants. Here is where I can get tripped up and rely on my team and coworkers to help keep me focused on the goals for the session. My brain leans toward solutions and solving the problem rather than guiding the discussion to allow for self realization with the participants.

Self realization is central to a successful requirements session in our organization. Many of the stakeholders are web savvy and offer great ideas with regard to how they expect to sell their business online. With the context of the goals of the project and available time for development we gently hold there hand as we walk them down the scenic path.