Tag Archives: specifications

What Are We Building Again?

When I first started project management classes in 2007, I came across this article and I saved it on my favorites folder. I want to share this experience with you.

Below are some situations I have run into working on projects. Have you ever experienced anything like this?

      New items proposed for the project require hours of excruciating debate because “I can’t tell from the scope document whether that is in scope or not.”
      The project team is convinced that one of the requirements will be very painful to realize. So they determine it is out of scope based on an incredibly obscure interpretation of the scope document.
      When confronted with a change request, the project team resists via slavish devotion to the scope document. (“Yes, that seems like the best place to implement that requirement, but changes to that system were not in scope, so we’ll have to create this really nasty workaround instead.”)

Ok, I may have exaggerated a little, but truth be told, stories like that play out on projects every day. For some reason, not knowing what a project is really supposed to accomplish is a common problem. Scope issues can lead to bigger problems down the road on the other two sides of that infamous Iron Triangle—schedule and budget.

All We Have to Do is Define a Detailed Scope…

Scope is notoriously hard to define in a useful manner, mainly because when it is initially defined the team does not know much about the project yet. Usually, someone with influence identifies the need for a project. They speak with the appropriate people or fill out the appropriate forms, with a flowery story explaining why this particular initiative is the most important activity the organization can do in the next twelve months. A project team is assigned to the initiative. They in turn talk to the requestor, and other experts identified by the requestor, to find out what the initiative entails. A large wish list is created that usually serves to confuse rather than illuminate the problem space. Some of these items are extremely specific, but most of them are very general; mainly because the project team does not have sufficient information to be extremely precise.

After some work down this path, the team looks at the ever-growing list and realizes that if they do not limit the items in some way they will never complete the project. They begin to make arbitrary divisions in the work: they limit the locations to which the project results will be made available, the business units provided access to the project results, the deliverables that will be provided, or a combination of these and others. Meanwhile the customers of the project are frantically dreaming up all possible deliverables, situations, and scenarios in the hope of getting them on the list before the scope is “frozen.” After all, nobody wants to be a scope creep.

Any client requested work falling outside the scope of this contract will be billed at €xxx.

While the divisions in the work seem to make sense at the time, they are usually based on factors related to how difficult (or more often how easy) it would be to deliver particular groupings. What teams often fail to take into account is a rather crucial piece of information—the vision of the project.

Clarifying that Blurry Vision

For those of you that I just caught in mid groan at the mention of the V-word, stop. The vision I am speaking of is much more practical than the Mission, Vision, Purpose discussions that organizations sometimes find themselves in. Stated simply, the vision seeks to capture what the project is supposed to accomplish. Or in other words, “What are we supposed to build again?”

Consider for a minute a project undertaken by an organization’s internal IT department. The vision of this project simply identifies the business problem the project is trying to solve. This statement does not have to be long; in fact the more concise that it is, the better it is. But here is the key: everyone involved in the project has to understand, support, and believe in the ultimate vision. How do you get to that to happen? You gather the entire project team together and ask them to collaborate on a shared vision.

On planning – What is truth today may be falsehood tomorrow. Never confuse your plan with truth. – Woody Williams

Gathering the entire team together to build a shared vision has several benefits. First of all, the job of communicating and achieving buy in of the vision is much easier. Even better, the entire team has a better picture of what the project is actually supposed to accomplish, so determining and working within scope is that much easier.

You want this vision to be understandable and very concise. These characteristics make defining the vision difficult, and as a result the conversations in these sessions become rather illuminating. The project team must focus on the really important aspects of the project so there is some inherent prioritization. But it is prioritization that is based on what is most important for the business.

So How Do We Get There?

Once the team has established their project vision, they need some guidelines for accomplishing that vision. That’s where scope comes in. Scope is a conceptual description of what the project will deliver in support of the vision. If described in the terms of problem and solution, the scope describes possible solutions and constraints on realizing those solutions.

So even with a vision established, how do you avoid the scope traps described above? First of all, the vision provides some general guidelines as to what should even be included in scope. If an item is brought up that seems like a great idea but does nothing whatsoever to accomplish the vision, do not include it “in scope.” In the same vein, if something comes along that is obviously critical to achieving the vision, that particular item will more than likely take on a higher priority.

The next trick comes in the way you represent scope. Remember those long lists that project teams get lost in and manage to interpret in ways that allow them to avoid annoying activities? Those lists are usually made up of statements formatted in a variety of ways and sourced from emails, conversations in the hallways, previous scope lists from failed projects, and pronouncements from various members of the organization’s leadership. The statements are vague, and often not very useful. One way to get around that problem is to define some structure for recording the scope statements. The format I find useful was originally suggested by Mike Cohn as a way to record User Stories, a form of recording requirements used in agile software development. (See User Stories Applied for Agile Software Development.) The format is straightforward:

So for example, in a project focusing on a new payroll system, the following could be an example scope statement:

AS A Payroll administrator

I WANT to be able to manually adjust payments for miscellaneous reasons
SO THAT I can process payroll in a timely manner
Sure, this statement is still pretty vague, but at least there is some information regarding who wants the feature or deliverable and why they want it. These types of statements are intended to be placeholders, reminders of future conversations that need to take place, which makes them a perfect format for capturing scope.

Wait a second, you say, that looks an awful lot like requirements. Yep. Requirements typically define the scope of a project, so why should they be defined separately? Save some time and record scope as you would requirements, expecting to further flesh out the information as you proceed with the project.

The final trick in avoiding the scope traps above is to take an iterative approach to realizing the scope items. Instead of trying to deliver all of the scope items applicable to a particular geography or business unit, pull those scope items into a “phase” list. Then break the effort into deliverable-focused iterations. Select a subset of scope items, deliver them, and learn from that experience. Then select the next subset of scope items and repeat the process, applying the lessons. This approach allows the project team to react to new understandings and adjust what they are doing accordingly.

Trying to manage a project without project management is like trying to play a football game without a game plan. – K. Tate

I Can See Clearly Now…

Project Vision and Scope should be great tools that help the project team accomplish what they are really trying to achieve. Unfortunately these tools can also distract from focus if it takes an inordinate amount of time to create them, or if the discussions and results cause more confusion than clarity. Relying on an unfocused, Easter egg hunt approach to gathering scope statements virtually guarantees these problems. The key is for the project team to define together what they are really trying to accomplish, and to maintain focus on that vision while identifying the details of how they are going to get there.

Reference: Author Kent McDonald

Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”