How Do You Troubleshoot Scope Problems

by Jamal Moustafaev, PMP

Skills Issues

Poorly Trained Professionals

One of the key problem areas of project scope definition is the lack of properly trained professionals who have knowledge and ability to elicit the right requirements from the project stakeholders. Some people might argue that this situation is slightly better in the IT and software development industries where scope definition responsibilities have been removed from project management and assigned to a group of professionals called business analysts.

Unfortunately, this problem isn’t limited to the lack of properly trained professionals. Scope definition in many industries implies the creation of blueprints and bills of materials, thus ignoring the preliminary work that has to be done in collecting and analyzing the business requirements for projects.

Technical Experts versus Scope Experts

In many organizations, management frequently assumes that a technical expert (e.g., architect, engineer, designer) automatically qualifies to collect, build, and analyze project scope. While this approach sometimes works on smaller ventures, assigning untrained technical people to build scope on larger, sophisticated projects can prove to be a very challenging task indeed.

This issue is, unfortunately, quite common. It brings to mind a conversation with a group of executives at a government agency involved, among other things, in several construction megaprojects. The debate involved project scope definition and its place in the science of project management. The problem this organization faced was fairly similar to the issues encountered by many architecture and engineering firms. The pure construction element of the project represented only a fraction of the overall scope.

Other elements that needed to be considered included public relations, environmental cleanup, legal, real estate, IT, security, engineering, and logistics, to name a few. This organization typically assigned such projects to one of the functional team members in the construction department, such as a senior architect, and time after time the scoping issues would arise as soon as the execution phase began. The conversation went as follows:

CONSULTANT: So, how does the scoping process work on such multi-departmental projects?

EXECUTIVES: Well, the representative of the construction department is responsible

for creating the construction scope.

CONSULTANT: And what about other areas—PR, environment, legal, etc.?

EXECUTIVES: They are supposed to produce the scope of their areas.

CONSULTANT: OK, but who unites all of these scopes into one document? How do you know everything has been covered? How can one identify inconsistencies between scope items originating from different departments? How can you prioritize them? Who is responsible for arranging peer reviews and document walkthroughs?

EXECUTIVES: This is where our main problem lies. It is impossible to find one person who is an expert in public relations, law, construction, engineering, IT, etc.

CONSULTANT: Have you considered assigning a department-independent project manager and providing him with proper training in the scope definition area? He can be responsible for business-level requirements, while technical experts will take care of the detailed technical design.

EXECUTIVES: Interesting idea. By the way, what the heck is a walkthrough?

What Can Be Done?

First, come to grips with the fact that it is absolutely essential for any organization involved with larger, more sophisticated projects to properly train their project managers in the areas of scope definition and management. Second, do not make the mistake of assuming that a great technical expert in a specific area can easily become a scope definition guru.

Remember, scope definition does not imply technical design involving detailed blueprints and bills of materials but rather high-level and detailed-level business requirements. If a technical expert expresses interest in the requirements elicitation area, one need not discourage his interest. Simply make sure that that person receives proper training before assigning him to elicit scope from the stakeholders (see Table 11.1 for a summary of methods described in the skills issues section of this chapter).

Table 11.2 Product or service problems

Product or Service Issues

Product or service issues are sometimes discovered when a product or service is delivered, and the client voices her dissatisfaction with it or even rejects it outright. In other cases, the products are delivered to the market and receive poor reviews or do not sell as well as expected. A partial root cause of these problems can lay in insufficient interaction between the real customers and the project team members who are responsible for scope definition.

In other words, customers or users were unavailable during the planning stage, or they were too high in the company hierarchy to be bothered with inquisitive scope elicitation questions, or the organization decided to save some money on focus groups. This lack of interaction and, more importantly, insufficient education of the stakeholder can lead to the development of unrealistic customer expectations.

What Can Be Done?

Recognize that the involvement of customers at all stages of a project is absolutely essential to a product’s success. They need to be involved at the initiation and planning stages in order to help define the high-level and detailed-level scope of the project, respectively. Their presence is required at the end of the planning and at the beginning of the execution phases in order to validate scope and detailed design documentation.

Furthermore, customer expectations should be continually managed all the way to the close out stage of the project in order to avoid the dreaded expectations gap that seems to happen every time the project manager decides to limit his interactions with the customers. A more detailed discussion of stakeholder management procedures is provided in Chapter 13.

There is another possible root cause for poor product performance once it hits the market. Unfortunately, that problem lies well beyond the scope of project team responsibilities. This is, of course, referring to project portfolio management, which will be discussed in detail in Chapters 15–18. In short, this root cause can be described as a bad project idea generated by the executives—an idea that can’t always be fixed by applying technical or other abilities of the project team. For example, when the Ibaraki prefectural government in Japan decided to build a $268 million airport that no major airline was planning to use, whose failure was it that the product was not successful: the project teams that delivered the airport on time and on budget or the politicians who initiated this project without any regard to the economic and demographic realities of their region? See Table 11.2 for a summary of methods described in the product or service issues section of this chapter.

Project Management Issues for Architecture and Engineering Firms

External Pressure

Too often project managers are pressured to start the execution stage when the scope definition effort is far from being completed. Sometimes it happens because management thinks that investing more time and effort in gathering project requirements is a waste of valuable project resources. Sometimes (and this happens more often), the firm deadline for the project is set before the scope definition or even initiation phase is completed.

In these scenarios, the unpredictability factor in the project-related estimates is completely ignored, and the release date is imposed while all of the estimates are, at best, in the +75 to – 25 percent range. What typically happens is that management realizes that the project cannot be completed on time if the scope elicitation efforts continue. This forces a shift into the execution phase, which is often guided by the foolhardy motto: we shall start building and figure out our scope as we go. This decision leads to omissions that reappear later when it costs a lot more to fix a problem than if the issue had been addressed at the scope definition stage.

Too Much Scope

In some cases, the project team agrees to deliver too much scope for a given budget or timeline. At a certain point in time, the stakeholders realize that the project cannot be completed on time or within the specified budget. The resulting responses vary from company to company. In some cases, the project team is ordered to roll up their sleeves and work harder.

And what happens when a group of individuals gets overworked? They get tired. What happens when people get tired? They make mistakes. What happens to the cost of making a mistake as one progresses through the project timeline? It grows exponentially. What is management’s response? Work harder. What happens when people work 16-hour days? It’s easy to see that it becomes a self-feeding cycle of doom that destroys project results and employee morale.

Quick De-scoping

In other cases, management finally gives in and orders a quick and frequently unorganized de-scoping of the project. The interdependence of various scope items, and the fact that dropping a scope item requires extensive fact gathering followed by analysis, often gets ignored.

Another variation of the agreeing-to-deliver-too-much-scope problem is a change in project constraints (e.g., slashed budgets, shortened timelines) while the scope remains the same.

What Can Be Done?

First, project teams should not sacrifice scope elicitation efforts for the sake of speeding up the project. These shortcuts are almost never successful. Second, project managers should avoid firm commitments to deadlines and fixed budgets, whenever possible, before project scoping is completed. Also, using various negotiating techniques to obtain additional degrees of freedom, as discussed in Chapter 4, is a powerful tool at the project manager’s disposal to alleviate these problems. Furthermore, stakeholder education about the risks of rushed shifts from planning to execution phases of the projects is absolutely essential. See Table 11.3 for a summary of techniques described in the project management issues section of this chapter.

Table 11.3 Project management problems

Scope Elicitation Issues

Frequently, the project team and other stakeholders discover that important project requirements have been missed when the project is well into the execution stage.

Lack of Communication

Sometimes these missed requirements are caused by customers and users who do not have a very clear idea of what they really need. In other cases, poorly trained project managers are responsible. Another cause is the lack of communication between different departments that leads to the omission of important details.

One project manager described an extreme case of this type of miscommunication. The case involved two departments in a government organization: the logistics department, which was responsible for building and maintaining roads, and the engineering department. At one point in time, the engineering department decided that it would be a great idea to implant special devices into the surfaces of roads leading to a local port in order to monitor and forecast the truck flow to the terminals.

It was indeed a great idea because the employees at the terminal frequently complained about unpredictability of incoming traffic. The engineers acquired these fairly expensive sensors and the software required to analyze the data then proceeded to embed them into the road surface. Closer to the end of the year, at a department heads’ meeting, the director of engineering reported on his team’s accomplishments and proudly mentioned the sensor project as one of the highlighted achievements of the year.

To his great surprise, the director of logistics started laughing uncontrollably, and it took a couple of angry stares from other executives to calm him down. Still struggling to control himself, the head of the logistics department was finally able to explain his reaction. His team was scheduled to resurface these same roads in the coming year. Thus, the engineers’ efforts along with a hefty sum of taxpayers’ money were basically wasted because of the lack of coordination between the two departments.

Scope Imposed by a Higher Authority

Another frequent problem with scope definition is that the requirements are imposed by a higher authority without any regard to whether they truly represent the needs and aspirations of real users. A variation of this problem occurs when functional managers prevent project managers from communicating directly with the customers.

Absence of Prioritization

Yet another issue that can jeopardize the scope definition process takes place when the scope items are not prioritized, or all of them have high priority. What happens in this scenario is that a team’s flexibility in cutting scope is severely limited if it turns out that the initial time and budget estimates were overly optimistic.

What Can Be Done?

Missed or overlooked requirements can be avoided by the customers’ active involvement in the scope definition process, proper training of project managers in scope elicitation techniques, and thorough document walkthroughs and inspections. In addition, the project manager should ensure that people responsible for scope definition get access to the real customers and users.

Finally, all of the scope items must be prioritized and assigned to must-have, should-have, and nice-to-have categories. Education of the stakeholders about the importance of prioritization is another important factor when battling scope elicitation issues. See Table 11.4 for a summary of procedures described in the scope elicitation issues section of this chapter.

Table 11.4 Scope elicitation problems

Documentation Issues

Undocumented Scope

In some scenarios, different and sometimes competing groups of stakeholders cannot arrive at a consensus of what the final product should look like. Consequently, the decision is made to start working with what is currently available and to hope difference can be reconciled in the future.

In some extreme cases, the decision is made to forego the documentation effort altogether.  As mentioned previously, sometimes the eagerness to begin the construction of the product can compel the project manager, voluntarily or unwillingly, to transition to the execution stage of the

product while there are still open issues remaining with respect to the project scope.  And a poorly defined scope can be a byproduct of a lack of appreciation among the stakeholders for the importance of well-defined requirements.

Vague Scope

A common complaint expressed by technical team members responsible for building products is the ambiguity and vagueness of the scope documentation. Left uncorrected, this can lead to other serious issues including project failure. These technical people might take it upon themselves to independently follow up with various stakeholders in order to gain some understanding of the vaguely stated scope items. In some cases, they might end up talking to the wrong stakeholder (e.g., an internal functional manager) rather than a real customer.

Even if they do end up talking to the right person they might, and probably will, forget to update the project documentation. And if they do remember to update scope documents, they could fail to consider the impact of their particular interpretation of a vague statement on other requirements and project constraints. In an even scarier scenario, the technical experts might decide to forego consultations with stakeholders regarding the stated requirements and rely on their own interpretation or, God forbid, imagination.

In the best-case scenario, technical team members will continue harassing the project manager by complaining, and justifiably so, that they are unable to work with documentation of such poor quality. This will, in turn, lead to repeating the scope definition process with one unpleasant twist—it will be taking place in the middle of the execution stage.

Lack of Measurability

Lack of measurability easily could lead to the same kind of behavior described in the last section. Statements such as the new container terminal shall be of a sufficient square footage to accommodate load requirements in peak times might again compel the engineers or architects to either independently contact the stakeholders or decide what sufficient square footage means according to their own perceptions and imaginations. Needless to say, customer expectations very frequently turn out to be somewhat different than the opinions of the technical team members.

What Can Be Done?

Once the first drafts of the documents have been completed, they should undergo several rigorous examination processes including peer reviews by experienced project managers who are preferably unrelated to the project in question, inspections with technical teams, and walkthroughs with customers. Only several iterations of these processes will enable the project team to remove all the discrepancies from the scope description and provide the technical team with quality documents that will become the foundation of the detailed designs including blueprints and bills of materials.

And as mentioned previously, proper training in the scope definition area is absolutely essential. See Table 11.5 for a summary of techniques described in the documentation issues section of this chapter.

Table 11.5 Documentation problems

Scope Management Issues

Finally, the last group of problems typically starts after the scope of the project has been finalized, and the team has moved into the execution stage by starting to build the final product. In almost any venture, there are several problems associated with this particular stage.

Customers Communicate Directly With the Technical People

The first problem is that the customers, either due to the lack of understanding of scope control procedures or because of some more sinister reasons, start talking directly to the technical team members responsible for building the final artifact. This occurs through informal one-on-one conversations, phone calls, or e-mail messages while circumventing the project manager and other key project stakeholders. The technical team members might then be pressured into making changes and adjustments to the scope, bypassing detailed impact analysis of the requested modifications and their benefits. As a result of such manipulations, several issues most likely will surface:

• Uncontrolled modifications and additions can have a negative impact on other project features

• The quality of the final product might suffer as such changes are rarely assessed and documented

• Project scope will increase while time and budget constraints remain the same

• New risks can surface because of ad hoc improvements to the project scope

• Technical team members will be distracted from their assigned duties, thus jeopardizing the overall project schedule

More information on uncontrolled project changes and how to deal with them is provided in Chapter 13.

Scope Changes Frequently

Another problem is that the customers change their opinion about what the final product should look like after the specifications documents have been baselined. This can happen for the following variety of reasons: stakeholder lack of understanding of technical difficulties of changing scope, especially on larger, more sophisticated ventures; poor scope definition efforts during the planning stage; internal strife among different stakeholder groups; and even political, economic, or technological shifts in the marketplace. If left unattended, these frequent changes will have exactly the same effect on the project as the ones described in the previous section.

Table 11.6 Scope management problems

What Can Be Done?

One of the techniques available to project managers who are determined to gain control of the project scope is the education of project stakeholders on the inherent dangers of making unplanned modifications to the project scope. The project manager should find a way to explain to all parties involved that uncontrolled changes can lead to increased exposure to risks, low product quality, and can have detrimental effects on budgets and time lines.

Implementation of proper change control policies is an essential step in harnessing the scope management process. It should, among other things, incorporate a very thorough examination of the necessity of a proposed change, the technical impacts, and the effects on timeline, budget, and risk exposure. All stakeholders should be making their decisions regarding the validity of the change based on the following formula:

Is the value of implementing the proposed change minus all of its negative impacts higher or lower than the cost of not carrying it out?

For more information regarding assessment of the changes and modifications of the project scope, please see the section in Chapter 13, What Is the Impact of the Change? Table 11.6 contains an overview of techniques described in the scope management issues section of this chapter.

Summary

One might have noticed a definitive repeating pattern while reading this chapter. Certain suggestions kept reappearing in the how to fix them columns of the tables. It probably would be more efficient to highlight all the key methodologies for battling scope problems according to their importance rather than to group them by the problems they address.

The most important ingredient in preventing scope issues is the training of scope definition experts, either project managers or people holding other titles (e.g., business analysts in IT or software development industries).

Ongoing involvement and communication with all stakeholders in general and customers and users in particular is another cornerstone of the scope elicitation, definition, and management process.

Educating the stakeholders about project management, scope definition, and the overall impact of their decisions on the budget, duration, resource requirements, quality of the final product, and potential risks is also very important in avoiding serious scope issues.

Project managers should resist any attempts to sacrifice scope elicitation and definition efforts in order to speed up the project’s progress. Invariably, such endeavors result in serious problems with quality, missed deadlines, and overblown budgets.

Making any firm commitments with respect to project budget, timeline, or resource requirements before the entire scope has been finalized is also not recommended for project managers and other project team members. Project managers are also strongly encouraged to extensively use the negotiation techniques described in Chapter 4 when discussing various project estimates and commitments with other stakeholders and key customers.

Finally, scope management is another key methodology in preventing scope creep and unapproved change in the scope that can affect the success of the project.

Jamal Moustfaev is president and founder of Thinktank Consulting.  He is a certified Project Management Professional and holds an MBA in finance from Simon Fraser University in British Columbia.  Editor’s note: This article is drawn from Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management by Jamal Moustafaev, PMP