Unblurring Lines: Clarifying the Scope of Your Project
A friend was recently trying to clarify the scope of a vendor’s activities on a project for one of her clients, and she asked me for ideas. We frequently bounce ideas off one another. I’m “project management boy” and she is “governance girl,” a dynamic duo in a symbiotic consulting relationship that benefits our clients and us.
She explained that a systems integrator was helping the client enhance an existing system by providing staff augmentation (tech bodies for rent). I immediately keyed in on the word “helping”—a fine word, but one that can blur lines of responsibility. Some of the biggest disaster projects I’ve reviewed had contract language in which a vendor was responsible for “helping” a client do amazing things, but the extent of the help was a source of confusion.
Project and subproject boundaries can be challenging because people have different assumptions about exactly where the boundaries are. Reasonable people can disagree, and some may not have thought through the implications of their beliefs. A facilitation tool that can be helpful in this situation is using “is/is not.”
Let’s imagine you are implementing a new payroll system. Reasonable people will believe that some things are clearly in scope for your project, such as calculating payroll for employees, and some things are clearly out of scope—for example, your project is not intended to build a robot that will explore Mars.
These obvious cases aren’t interesting, and some people get testy because there are many things that aren’t in scope (most of the universe). What is interesting are things on the fuzzy border. For example, will your payroll project create a written guide for those who will maintain the system?
Some will say yes, and others will say, “I don’t think anyone asked for it, and we didn’t include it in the budget.” What you have now is something on the border. These borderline items are often a source of confusion and must be addressed.
To use the “is/is not” technique to help clarify project scope, first, brainstorm with your team on yellow sticky notes all of the things you can reasonably imagine the project might entail in the categories of analysis, design, development, testing, training, online help, documentation, interfaces, and backup and recovery. Think about different project stakeholders and consumers: What might they want from the implementation? Be specific and don’t filter ideas.
Then draw a circle on a whiteboard or flip chart to indicate the realm of the project’s scope. Work with the team to place the sticky notes either inside or outside the project boundary.
Listen carefully for disagreements and negotiation on the border. These boundary items need special attention and should be reviewed with project sponsors and documented as clearly in or out of project scope.
