Managing scope is the key to any project’s success. Everyone looks for scope creep and tries to guard against it. What happens when the words we’re both saying describe a concept or outcome that are the same but mean something different to each of us? What if there is more complexity involved in an apparently “known” word? Even when we think we are starting in the same place, sometimes we aren’t. How can a project manager be more explicit in describing the scope of a project even when using words everybody “knows”?
Take for example a data quality project where everyone agrees that the key entities involved are Compound, Project, and Therapeutic Area. The business understands what they’ll be getting, IT understands, leadership understands, and everyone is in agreement.
As the project progresses, you find out that the definition of Compound changes at each development. Oh and wait, names have changed over time, as the business has in-licensed compounds and gone through a merger. Oh, and they need 10 different attributes of Compound, but you only onboarded two developers because you thought you only needed to model five attributes. Then the business says that Indication is just as relevant as the Therapeutic area, and it is as easy to include because it is “well-defined”.
You, as the faithful project manager, say to everyone that this is much more complex than we thought, but you hear back, “Well, the scope has never changed. After all, the scope is still Compound, Project, and Therapeutic Area, right?”
The team has more work typically in the same amount of time, the business thinks IT is just trying to justify being behind since, in their view, nothing has really changed, and you as the project manager look like you’ve missed something, when, really, the project complexity has changed.
A way to make this conversation a little less “he said, she said” and a little more structured is consider the following three points early in the project scope setting process.
- Write down quantitative descriptions for each of these entities up front. For example, for Compound, write down that you are planning for five attributes (e.g., chemical name, shorthand name, approved name, precursor name or project during discovery, and trade name) when available and two additional attributes of medium complexity. Also, you expect two to be simple, two to be medium difficulty, and one to be complex to manage. Document the assumptions in the appendix or supporting documentation. The design phase will resolve it. The important point isn’t “Do you have it exactly correct?” The important point is that you’re defining the size of the box to which you’ll compare future scope to show what has changed.
- Define complexity. Describing a complex attribute as one with three or more business transformations and two or more separate sources will help bring a quantitative view of the scope. If you have the drivers written down when you write down scope, then when you have the conversation that the scope has changed, you’ll be able to say, “Now we have ten attributes and three are complex, but we only planned for five attributes with one complex.” It isn’t that you know which five at the start; you just are trying to define a baseline in effort so you can show what has changed, even if at the high level everything looks the same.
- Document your resource assumptions based on what is to be built, not on the number of people required. Say an entity with five attributes requires six weeks in the build phase. Don’t say, “I need Jim for 6 weeks.” When you realize you have ten attributes for Compound instead of five, it’ll be harder to justify that you need “more Jim” if you don’t define up front what is driving Jim’s effort.
Including this level of detail and definition in the initial scope discussions will give you a way to describe what sounds different and is driving the change in scope – even when things look the same.
Is scope creep is a challenge with your projects? What tips do you have for preventing scope creep? Sound off in the comments!