Managing Web Projects, Part 2 - The Initiate Phase

The previous article in this series introduced the topic of the management of software development projects, including web projects. The fields of project management and software development were discussed, and I briefly outlined what I consider the major phases in a technology project. To review, these phases are:

- Initiate
- Analyze
- Design
- Build
- Deploy
- Review

This article will discuss in more detail the "Initiate" phase.

PROJECT SCOPE

Projects sometimes get off track. Clients or users can have unreasonable expectations. A development team can build something which works perfectly, but which wasnt requested. Friction can develop within project teams when these types of misunderstandings take place.

Inexperienced project managers sometimes see these issues as unavoidable, and simply accept "taking the fall" for project difficulties as part of the job. The truth is, by taking the proper steps at the very outset of a project, these types of difficulties can be largely avoided, and for those issues which can not be completely avoided, procedures can be put in place to deal with disagreements, so that they do not end up destroying the project.

The purpose of the Initiate phase is to determine the overall project "scope", and the primary end product (or "deliverable") of this phase will be the document known as the "Scope of Work statement" or the "SOW".

THE PROJECT PROPOSAL

Those who have worked in the consulting field should be familiar with the project proposal process. The consultant spends a period of time talking with the potential client, trying to put a box around exactly what it is he or she is proposing. The proposal lists, in "high level" but specific terms, the who, what, where, when, and how of what the project entails. The bulk of the proposal comprises a Scope of Work statement (the remainder of the proposal contains administrative things like executive summaries, terms of payment, and other items not directly related to the scope of work).

SCOPE OF WORK CONTENTS

I like to write my SOWs as a list of bullet points, totalling generally less than ten pages, succinctly addressing each topic. Examples of items in the scope of work include:

- the intended audience (potential customers, existing customers, the internal human resources department, et cetera)

- the delivery mechanisms (web-based, custom software, intranet, extranet)

- the business issues to be addressed, in as much detail as is currently available ("communicating marketing information to potential clients", "client needs to sell books; client has three warehouses in NY, CA, and MO; client wants to support customer relationship management functionality")

- a description of the primary "use cases" or functionality to be implemented ("user will be required to log in", "user can put books into a shopping cart and pay for them via credit card upon checkout", "customer service reps will receive e-mails when user submits a query")

- any "non-functional" requirements which can be determined at this time ("system must be available 24x7", "hosting must take place at XYZhost")

- this is very important, and very often overlooked, but what is specifically *out* of scope should be specified ("system will not connect to any external systems or databases", "graphics will be provided by client", "search engine submission will not be performed")

WORK WHICH IS OUT OF SCOPE

It is inevitable that a request will come in which falls outside the project scope. The SOW should state explicitly what will happen with change requests. For example:

- All change requests will be reviewed to determine whether or not they fall within the project scope.

- Those items which fall within the project scope will be added as amendments to the original SOW, and will not affect cost or schedule

- If we determine that a change request does not fall within the project scope, we will notify you, and cost and/or schedule of the current project may be re-negotiated, or the request will be deferred to a subsequent phase.

- In the case of a dispute, where we believe an item does not fall within the project scope, but you believe it does, we will convene a meeting between project stakeholders X, Y, and Z to come to a consensus on the issue.

ADDITIONAL ITEMS

Some of the items which may be included in the SOW, but which are not specifically necessary include:

- schedule estimates
- cost estimates
- human resource requirements

NEXT STEPS

When a Scope of Work statement has been produced by the consultant or project team and approved by the client or project stakeholder, the next step is to begin the Analyze phase of the project, where the business processes as they exist and as they are to be will be specified in detail.

FINAL WORDS

Some clients may balk at having the project team assemble a formal SOW. They feel that they know enough to guide you as the project goes on. This, however, is a recipe for a never ending project, and often, cancelled or failed projects. Having a formalized Scope of Work statement and scope management process ensures that, from the outset, both the client and project team know that if they satisfy all the items listed in the SOW, then they have successfully completed the project.

LINKS:

All the articles to date in the "Managing Web Projects" series, along with other relevant articles: http://groups.yahoo.com/group/jwcs

An article on Project Scope Management from Rational Software: http://www.therationaledge.com/content/nov_01/m_projScopeManagement_bl.html

Article Copyright © Jeremy Warach 2002

About the Author

Jeremy Warach is the Founder and Principal Consultant of J. Warach Consulting Services (JWCS), a full service software and web development consultancy based in the New York City area. He has worked in the technology field for over fifteen years, designing, building, and managing technology projects.

jeremy@warach.com
http://www.warach.com