Danielle Takes Scope Definition to Heart

I purposely scheduled all my meetings for the beginning of the day on February 14. I always buy Pam a dozen roses for Valentine’s Day, and I like to leave work early to stop by the florist. I wanted to leave especially early today because I was also planning a romantic dinner for the evening. My last appointment was with Danielle Bartlett, a young, single woman who had been with the company for about 4 months. She was wearing a black sweater and black pants, and looked a little glum when she entered my office.

“Why all black?” I asked as she sat down.

“I hate Valentine’s Day,” she said, trying to smile. “Actually, let me rephrase. I hate being single on Valentine’s Day!”

Danielle seemed like a nice enough woman and I wanted to offer her some reassurance, but I didn’t know her very well, and I didn’t think anything I said would make her feel better, so instead we talked about work. She was beginning the early stages of a construction cost-estimating system for the Facilities Department, and she had e-mailed me a draft of her Project Definition document. I thought a few areas needed more work, including more definition and clarity around the project scope.

“Danielle, I’ve heard different people talk about the benefits of this cost-estimating package and it seems like everyone has a different idea about what the final solution will look like. But, when I read your scope statement, it left me with more questions than answers.”

“I’ve defined the scope as best I know it,” she replied. “I’ve stated that we will be implementing a tool to help estimate costs on major construction projects. It seems pretty clear to me.”

“Well, I wonder if it is clear to the people reading the Project Definition,” I said. “First of all, are you clear on whether the tool will be available worldwide or just in the U.S. division?”

“That’s an easy one,” she answered. “Other countries have different construction rules and regulations. Initially, we will use the tool for U.S. construction projects. It may be customized for other countries later.”

“Okay,” I said. “Your business client is the Facilities Department. But I’ve also heard that the tool might be of use in the Capital Accounting Group, so they can allocate costs more effectively to the appropriate capital accounts.”

Again, Danielle had the answer. “My sponsor said I did not have to worry about the accounting implications. If they want to leverage the package, they will need to wait until the initial implementation is completed.”

I had one more question to drive home the point. “I also heard people like the idea of being able to use the tool on their laptop. Then they can enter information when they are at the construction site and update it in real time.”

Danielle was getting the picture. “Actually, the standalone capability will be available in a subsequent upgrade product. By the way, I get your point. Given the different expectations people have for this project, I guess the original scope statement was pretty vague.”

Lesson #9—Define the Many Aspects of What Is In Scope and Out of Scope

Scope can be thought of as a box defining the boundaries of a project. The work your project is responsible for is inside the box. The work you are not responsible for is outside the box. If you showed a box to people and asked them to describe it, some people would just say it was square. Those who were more geometrically inclined might say it was a cube. However, you will also find some observant people who would describe the size of the box, the color, the thickness, and what the box is made of.

Managing scope is one of the biggest challenges project managers face. It is much harder, in fact maybe impossible, if you have not done a good job defining scope to begin with. When you define the scope of your project, you are defining the characteristics of this “box” and what is in it. Further clarification of scope can be accomplished by clearly stating what is out of the box as well.

A good project manager would be wise to remember the box analogy the next time he or she needs to define the scope of a project. The scope definition should make it clear to the reader exactly what the project is trying to achieve. It should also clearly articulate what is out of scope, especially if there are areas of potential confusion. The project manager should think about the aspects of scope where people may have questions, and then identify which aspects are in scope and out of scope. Since Danielle is defining an IT project, she might also define scope in the following terms:

• What specific deliverables are in scope and out of scope?

• What organizations are in scope and out of scope?

• What major capabilities will the solution enable, and what are some obvious ones the project will not address?

• What data or databases are in scope and out of scope?

• What will this specific project deliver, and what will be delivered in subsequent related projects?

• Which business processes will be addressed and which ones will not?

Danielle’s scope statement is very typical of how some project managers define project scope. It is brief and to the point, but it also leaves questions in the minds of the readers. Remember, the purpose of defining scope is to clearly articulate what you are taking responsibility for delivering on the project. You don’t want to define your project, gain sponsor approval, and then still have questions arise later about exactly what is included in your project.

Based on the little I know of Danielle’s project, I have already identified three areas where she should further clarify what is in scope and out of scope. There may be more as well. The good news is she knows the information. However, she is not sharing the information and being clear to the reader. She should be much clearer about what locations and organizations will be included in the initial deployment. Because there is some confusion in other related organizations, she should state specifically that the accounting group and other groups are out of scope. She should also be clear about the major features and capabilities that will and will not be included. The scope statement is not the place to put requirements, but the question of whether the solution can be used with a laptop sounds like it is an area of potential confusion. By being clear in the up-front scope definition, Danielle can better manage expectations and better manage the scope change process during the project.