Success starts here

We’re now on our second stage of our process – the one where the deliverables of the project are agreed in formal documents: Define

You’re going to produce several documents in this stage, some (or even all) of which form part of the contractual side of the job (that is they are referred to in the contract and may even form its appendices):

• Statement of Works
• Functional Specification
• Project Timeline (or Project Schedule)
• Budget

There’s some debate as to whether the Project Manager is responsible for the Fucntional Specification. Many Information/User Experience Architects feel that this is a job for them, after all they’re responsible for detailing how the site will work.My personal belief is that the task can and should be a joint responsbility, with the top level specification coming from the Information/User Experience Architect and the Project Manager adding detail that would affect the technical build and at the same time consistency checking the previous input. At the end of the day this responsibility is owned by different people in different agencies – there’s no one way of doing it right (in fact in some cases you may even find the Client or Client Services writing the top level spec).

There may well be other documents produced at this point too but usually by, or in conjunction with, a specialist resource:

Again, depending on your organisation, you may be expected to produce all of these documents. You, as a Project Manager, should only do so if you are an expert in these areas. The chances are you’re not, and even if you are you should hand these tasks off anyway so that you’re not overloaded with too many things to do, a situation where you are likely to make omissions or mistakes that come back and bite you in the … well, you know where.

There are a few more documents you should consider creating at the start of the project too. They’re especially useful on larger projects as they help to control the job as it progresses, but on smaller projects they will either be over-kill or their content wouldbe agreed in a semiformal way (via email or in a meeting).

• Roles and Responsibilities - it defines who does what
• Communication Plan – who gets told what, and when
• Risk log – an ongoing record of present risks and their mitigations
• Change log – the way of recording spec changes after the sow, fs, Project TimeLine and budget have been agreed. You’ll also provide a summary of the impact predicted on the project for each change logged
• Issue log – this document is a record of the problems encountered in the project and their proposed or executed solutions of the associated costs to the budget and timeline

Back to your main documents, though.

The Statement of Work (or SoW) states clearly what is and is NOT included in the work to be performed during the project. As you can imagine defining what isn’t in the project can be more important than what is. It’s the nature of a Client to try to get as much as they can for their money, so this is the time to set the boundaries very clearly.

Where there is disagreement about the inclusions and exclusions of the SoW you’ll find either not enough questions and, almost certainly, not the right sorts of questions were asked. You now have the opportunity to ask the questions again, before you’re committed to the project in terms of resource, reputation and contract.

Once you have a clear SoW, you will now able to put together your next main document, the Functional Specification (or FS). There you describe how the end deliverable of the job will work. It often supplements the Information Architecture and User Journeys but if these are not present, for whatever reason, this document should clearly describe how every mouse click, every data capture or retrieval, every interaction should work, in detail whenever possible.

Again, any disagreement in the content of this document shows the gaps in the work done in the Discover phase. It yet again gives you the opportunity to work in amendments and corrections, and almost definitely will trigger the re-write of the SoW. Often the SoW and FS are presented to the client at the same time, allowing you to get any corrections to both done together.

Now you have these documents you should be able to define the resources you’ll need to get the job done, how often and for how long. More importantly you will be able to plan WHEN you’ll need them, creating your Project Timeline.

You’d probably use one of the many Project Management applications for this, like Microsoft Project or Project Kickstart.  Most of these have the function to allow you to enter the cost for using a resource into the software and, in many cases, calculate the price of the job as a result – your Budget.

Good software packages will highlight where you have project resource conflicts, specify task dependencies (or which tasks MUST happen in a specified order) and where you’ll need extra resources to achieve the project goal by any specific end date.

Some Project Managers will define their timelines in spreadsheet documents if they don’t have access to PM software, but whilst his is a perfectly fine way of doing the job, having PM software that is written to do the job will save the you a lot of time and effort.

As a final check and balance the Timeline and Budget offer the Project Manager one last opportunity to verify that the project has been properly defined. Any issues arising from delivery dates and/or costs will lead to conversations with the Client where the SoW and FS need to be redrafted, probably de-scoping deliverables either to a further, later project or even completely removing them.

This will lead to adjustments to the Timeline and Budget, and if necessary in several iterations, until the definition of the project is complete.

It’s normal, at the end of the Define stage, for the Client to be asked to ”sign off” the documents. This used to be a physical signature, hence the contractual nature of the products of the Define stage of the project. Nowadays an email confirming the Client’s agreement to the contents of the documentation is all that is required. Once you have that you ready for what most people see as the “fun” part of the project: Design.

Share/Bookmark