Since I’m an interaction designer, I don’t normally produce documentation not directly related to design. In most of my projects there is at least a project manager, and a business analyst who handle most of the heavy lifting when it comes to documentation at the start of a project. This is not always the case however and the duties of producing up-front documentation falls to those that don’t normally do it. In other words, me.
I don’t always have the luxury of working with a fully staffed project team. This is not just the case at my company where nearly all my work is geared toward internal clients (our own employees) but happens often at consulting agencies where team members are called upon to wear all sorts of hats or places where staff size is small and money is tight (who hasn’t felt this?). When this is the case, I or others on my team (of three!) need to step up and get things started.
One of the first things that we’ll produce is a Project Work Scope. In many cases a project work scope only gets written when the project charter has been given a green light by some person above you who parks their Mercedes in their reserved spot in the parking garage. The project charter is a very high-level document that gives enough information about the intent of the project and the problem that it’s trying to solve. Boring.
Even though the project charter and project work scope aren’t necessarily page-turners, the project work scope is a crucial piece of documentation that serves several purposes:
- succinctly states the background and the problem that needs to be solved
- describes the specific ways in which this problem is going to be solved
- gives rough estimates of how long each thing will take
- lists the people that will be involved
- specifies dependencies – what is required in order to be successful
- specifies constraints – what things might stand in our way
There are other things that are also appropriate for inclusion in a project work scope but may depend on what your project is trying to accomplish. For instance, I don’t have to worry about budgets since I don’t bill any clients, but time-frame is still important. Include only those things that you know will truly impact your project and leave out the things that won’t. Some other things that you might want to include only if it makes sense for your situation:
- capital expenses (e.g. hardware, software licensing)
- organizational impact: will this require resources from other projects or outside of your immediate dept?
- work alignment: how does this project align with other initiatives already happening in your organization?
- stakeholders: who is either driving this initiative or who will be directly affected by it?
- project approval: get sign off before starting the work.
- items out of scope: this is the yin to the in-scope’s yang. Also good to get down on paper.
The bottom line is keep the document as short and to the point as possible. Once everyone who is involved reads and agrees to the work, you’ll hopefully never have to look at it again. If you do though, it won’t require much effort to look it over.
When would you look at it again? When the project is getting off track or is suffering from scope creep. Put those ideas into a feature list to be prioritized later. Let everyone know that you’ll get to the ideas, just not now. The project work scope is a good way to remind everyone why you’re engaged in the project in the first place.
Here is an example of a recent project work scope that I put together for a small-scale engagement with another project team (also the motivation for this post): Project Work Scope Example
For more information than you ever wanted on this topic the following might be useful (in order of anal retentiveness):