- A New Perspective on Scope
- Classic Scope Control
- Managing Scope Change
- Common Scope Headaches
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Common Scope Headaches
Most day-to-day problems with scope are caused by weaknesses in the project definition process. While you work to create a methodology for managing scope that is high on concept, keep an eye out for these nuts-and-bolts breakdowns. This section describes the most common headaches, along with the cures.
Problem #1: I Sketched the Site Out on a Napkin—Is that Okay?
It's difficult to draft project specifications if the initial requirements were poorly defined by the customer in the first place. The "cocktail napkin blueprint" can be used to memorialize a moment of inspiration, but it is not a valid input for your specification. Sure, you can "wing it" and attempt to fill in the blanks for your client, but this guessing game usually ends in dissatisfaction with an end product that doesn't match your customer's expectations.
Symptoms
There is no creative brief or written document signed off by the client that states the scope of the project and its features.
There is a creative brief, but it is vague or poorly written.
The project stakeholders are new to the Web or inexperienced with user interface design.
The developer has numerous questions about the specifications.
Solutions
Build a feature inventory by asking the client to list all the items that appear on each page.
Build out a use-case scenario by walking a hypothetical user through the application and asking the following questions. What are the user inputs? What sort of output should users receive? What are all the possible actions a user might take?
Find an example of a similar site that can be used as a model. Ask the customer how her vision differs from the example or how the model should be modified.
When all else fails, take a stab at designing the application yourself. E-mail the specifications to the project owner with the alternate features and design choices presented as a series of questions highlighted in red. As the client answers the list of questions, he effectively builds the specifications.
Circulate early versions of the spec to a tech lead for a brief review and obtain a list of questions for clarification.
Problem #2: It's Nice, But It's Not What We Had in Mind.
So you did a great job writing a 20-page specification, using plenty of technical jargon to impress the developers. Unfortunately, your project is in trouble because your nontechnical client didn't "get it" until round one of the design popped up on her monitor. The fateful words "We didn't know it was going to work like this" spell disaster for your deadline. In order to prevent drastic revisions late in the game, steps need to be taken right now during scope definition.
Symptoms
The client signed off on a feature summary but never reviewed the detailed specifications.
The client has very few questions about the specifications.
The client makes radical scope change requests late in the design phase.
Solutions
Conduct a face-to-face review of the spec where each feature is discussed in detail. Many project stakeholders do not read through e-mail attachments.
Be aware of different comprehension styles when you present the final specifications to your client for sign-off. Convey your concepts visually, orally, and in writing.
Include visual mockups in your specs in addition to text explanations.
Identify all the project stakeholders and have them sign off on the specifications.
If your project owners are inexperienced, do not sign off on the specs until there is a demo/front-end prototype or finished design mockups. Build an HTML skeleton or "shell" of the application and walk stakeholders through the demo. Many inexperienced stakeholders don't understand what they are getting until they see it on their monitors.
Problem #3: Just One More Tiny Little Change . . .
The cost of changes tends to increase as the launch date approaches. However, your client may not realize that creative brainstorming and "tweaking" just isn't appropriate during system testing!
Symptoms
The project deadline is repeatedly pushed back.
The client can submit feature changes without incurring any cost.
Solutions
Draft a detailed scope document or specification and require a formal sign-off before any work begins.
Break payment schedules into a series of installments for each itemized deliverable rather than a single payment for the finished product.
Create a formal change order procedure and assign a cost to change orders by making arrangements for additional fees or deadline extensions. Require change orders to be authorized by the ultimate project sponsor.
When drafting your documentation, include features that are not required. Ask stakeholders to identify categories of requirements that will not be included, like credit card transactions or personalization features.
Circulate updates to the project plan and specifications after each change order.
Try an approach that employs rapid prototyping techniques. Shorten the release cycle. Establish an open-ended "burn rate" fee structure, and invite the client to provide continuous creative input.