Scope Creep

Although the meaning of this phrase is fairly obvious, it is important to think seriously about scope creep. It is natural to feel the urge to expand the size of a project. As much as PMs work to avoid additions to project scope, changes will occur. Think about projects that you have worked on in the past. At the end of the project, how closely did the result match the expectation at the beginning? If the answer is “barely,” then the project initiation and scoping activities need to be improved on future projects.

There are a lot of valid reasons why scope creep occurs. As a matter of fact, you should acknowledge that there will almost always be some scope changes when planning project work. There will always be new information that becomes available during analysis that will cause you to vary from the plan. How will you handle the new information and how much do you allow the plan to change? This is the real question. Just because new information comes to light doesn’t mean that it must be acted upon. It should be carefully considered and its impact forecast into the project. How would the project change if this new knowledge was incorporated? What will the impact be if the knowledge is ignored or not included? Does this new information give reason to believe that there will be even more new information exposed as the project moves forward? Was a major area/component of the business understanding missed?

Legitimate causes of scope creep are:

• The business changes while a project is under way (e.g., a new customer requests a custom product or demand increases or decreases suddenly)

• Outside regulatory change

• Analysis uncovers a part of the business that will be impacted but was not included in planning

• A new business stakeholder comes into the business area

One of the most important uses of a diagram to represent project scope is the visual reminder that it provides for the team. The scope diagram should be prominently displayed during requirements elicitation sessions and referred to often. When the group starts to get out of the project boundaries, reviewing the scope diagram will bring everyone back to focus. If a change to scope is requested and approved (via a change control process), update the scope documentation to reflect the change.

Summary of key points

It is critical for the successful BA to understand and be able to explain why his or her project is important and why stakeholders should be excited about the ultimate goal of the project. Knowing the ultimate objectives of a project will drive the direction of the analysis work. As BAs learn about the reasons for project initiation, they may be asked to develop a business case, cost/benefit analysis, or feasibility study. A BA should also understand how his or her project aligns with the organization’s strategic plans. BAs may not be involved in creating strategic plans or business architecture, but they must be aware of them and make sure that all of their work aligns.

Much of the work performed by a BA is within the context of a project. Some is not. Regardless of whether or not you are working on a project:

• You should know why the project is being done. The most important word here is why.

• You should always know what you and your team are doing to help the organization achieve its long-term goals.

• When you are faced with a situation where someone is recommending a choice that would not be aligned with the high-level strategic plan, you should be able to explain why this idea does not align and how it would negatively impact the organization as a whole. This is a great opportunity for a strong BA to shine.

• There are many reasons why a project is initiated, including a government mandate, response to competitive pressure, or a clearly cost-justifiable change. Most software development projects are being funded in the hope that productivity will increase and improved competitive advantage will be the payback. It is critical for you to understand why the project is being funded.

• Project initiation involves working with the project sponsor and PM to define the boundaries of the project and plan for its completion.