Scope Change Management

Why have this section in this chapter given that you assume requirements, functions, and features are completely and clearly defined and documented just as in the case of linear strategies? Well, things aren’t always what they seem to be. Even though your assumption holds, the world doesn’t stand still for you. The business world changes and some of those changes can affect your project. So despite the fact that you weren’t expecting any changes, you shouldn’t be overly concerned that they will happen. The material that follows addresses just why this is so.

Warning

The customer has a very different view of change than does the developer. Customers tend to view change as simpler than the developer. They don’t see the system ramifications to what appears to be a very simple request. Developers, on the other hand, see all sorts of ghosts and goblins in even the simplest of requests. The request can indirectly affect all uses of the variables or parameters that are directly affected. The design is compromised and must be revised. The database design and layout is affected because longer character strings result from the change request, and so on.

Protecting the Incremental SDPM Strategy Project Against the Impact of Scope Change

There are two different strategies that I discussed in the Linear approach in Chapter 7 that apply to the incremental approach as well. The first is management reserve. The second is to change to an Iterative SDPM strategy. I want ...

Get Effective Software Project Management now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.