Project Scope Creep can make or break any project if not handled properly. Most project managers and Steering committees do not realize how potent the impact of changing scope is on the final result and deliverables. In this post, we will look at all aspects of the project scope creep.
This post will cover the following topics.
Definition
The project scope defines what is and is not included in the project deliverables.
These are defined in the requirements documentation and are linked to the project risks, assumptions and constraints. The main output of the scope definition process is a Project Scope Statement.
Project Scope Baseline
When the project scope and deliverables are changed continuously or in an uncontrolled manner after the project has started, then it results in project scope creep. This can have an impact on the schedule, cost and risk profile of the project.
The project scope and work is broken down into work packages and WBS (work breakdown structures). These become the level at which each change is evaluated. So, when cost change is evaluated, it is with respect to the work packages as well.
The approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary then represents the Project Scope baseline. Everything needs to be measured and compared to this baseline.
What does Project Scope documentation include?
Let us understand the project scope with the help of an example. This will help you see the type of information that needs to be included in the project scope documentation.
Sample Project and High-Level Scope documentation
We are writing the project scope in the following scenario:
- It is a project with an eCommerce Four business lines – Apparel, Office Goods, Cosmetics and Food. It has operations in 5 countries – US, Canada, Australia, China, and the UK.
- We want to implement an eCommerce site.
- This outline will define our scope in this project
Now we are ready with the outline to document the scope of this project.
- Overall Scope
- Geographical Scope
- Organizational Scope
- Functional / Application Scope
- Process Scope
- Technical / Systems Scope
Overall Scope
The corporation needs to create a contemporary, responsive, search engine optimized, store that supports customers throughout each step of their buying journey. The structure of the site should attract the customers and inspire them to explore the store and its products, resulting in upselling and cross-sell opportunities.
The page load speed should be a maximum of 1 second.
The product pages should include reviews from real people with genuine experiences.
The site should have deep social media integration with the ability to register and log in using Facebook, Twitter, and Google accounts.
Geographical Scope
The project site will enable geolocation functionality to have different location-specific features, products, currencies, and checkout designs and features for different geographic locations. This will enable customers to transact based on the location they are from, with the requisite taxes and legal functionality built-in.
Functional Scope
How many currencies/languages will you have on your website? The currencies supported by the eCommerce website will include – US Dollar, Canada Dollar, Australian Dollar, China Yuan, and British Pound.
User Roles that need to be configured are – Visitor, Registered Member, Administrator, Sales Manager, Pricing Analyst, and Finance Manager.
The user roles should have the ability to visit and work in certain pages. For example, the visitor profile should be able to
- View Home Banners or Slide Show Gallery
- Browse Products
- View Product Details
- View FAQs
- Become a Member through the Registration process
- View Static Pages
The Site needs to have integrations with other applications like SAP – FICO, SD, MM, BW, Vendavo modules; Salesforce, ServiceNow, and the Enterprise Data Warehouse.
The site will use the following payment gateways –
- PayPal
- Stripe
- Square
- SecurePay
- Worldpay
- Authorize.net
- 2Checkout
Process Scope
The process for the website should include details for:
- Scrolling and surfing through the site as a visitor
- Registering as a member
- Buying a product or series of products
- Checking out and paying for the products
- Returning the products and getting refund
Technical Scope
The product will be implemented using the Magento Enterprise version on the Amazon AWS cloud. The data for the products, features, users, and other details will be provided by business users.
The integration for the other applications will be created using TIBCO middleware.
Detailed Scope Requirements
The above list is very high-level sample scope documentation that shows the kind of information that should be there in the document. However, the scope document can also include other information that will help guide the project in more detail. Here is an example from Slideshare documentation for a detailed Project Scope Document.
Can Scope Change be good?
For most of the projects scope change – often happening carelessly – is very damaging to the project. But in some cases, the situation may indeed be changing over time and circumstances. In such cases, it would be suicidal to ignore the changing reality and continue with a goal or a product that has become irrelevant. For consulting companies and contracting staff of course, an additional scope is always equal to more revenue, so they may not necessarily object. However, consultants with integrity and professionalism will shun such a way to make their money.
In any case, there is no denying that there are times and circumstances where business processes, market opportunities, competing products, and technologies change during the project and it would be good for the project to add additional objectives or requirements.
Why Scope Creep Happens
Scoping is a complex exercise for every project manager and many often get it wrong. More than that, things change as time progresses and because of that new requirements may become necessary and critical to include.
What are the different reasons why a scope creep may seep into a project? Here are some.
Requirements may have been overlooked
The requirements may have genuinely been missed because of:
- Inadequate planning: If the planning did not have enough detail. Missing pieces or gaps in requirements and project planning can cause scope creeps later on.
- Poor requirements analysis: When the requirements analysis is not done properly, then one may not fully document or understand the ramifications of what the users want.
- Late user involvement: Projects really are to translate the requirements and needs of users into reality. That is why the users need to be involved from the beginning. If the users’ engagement comes later in the project, then that can have an impact on what needs to be delivered.
- Underestimating complexity: When the proper rigor is missing from the requirements gathering or analysis, then the complexities involved are not properly appreciated.
- Green-field projects: in new and green-field projects there are no benchmarks and examples. Therefore, the plans even when they are done diligently can be off due to unknown variables.
- Misunderstandings about SOW: The statement of work sets out what is to be delivered finally by the project team and/or consultants. If the complete boundaries and details are not understood properly by the project team, then their plans can be off.
Functionality enhancements that come up after the project start
This may be one of the legitimate reasons to increase the scope, IF it meets the selection criteria for scope change. Ultimately, the increase in scope should be necessitated by changed circumstances such that it makes financial sense and the changed scheduled can be absorbed. There is no point in sticking to a scope to building a floppy disk drive when no one is using that anymore. Additional features that appear in the form of:
- Enhancement requests from project drivers – these are the requests that come from those stakeholders who drive the project. These do not make the cut automatically. Ultimately they should go through the rigor of Change Control Board.
- Developer-included enhancements – These are the dangerous enhancements to be sneaked into any project. These can be very helpful, since the developers may be able to see inconsistencies in the system process, but these need special investigation by their peers, their managers and ultimately by the Change Control Board.
- Gold-plating – this practice is akin to playing the hero. Even when the requirements from the customers do not mandate it, some project managers and teams add more features in order to delight the customer. These are, sometimes, not required and have not been blessed by the Change Control Board or even the customers. It then becomes a dangerous situation for the delivery.
- Perfectionist attitude of developers/suppliers – This is akin to Gold plating, albeit more about getting things perfectly right and thus changing features and things on their own even when it may not be in the requirements.
- Consolidation of multiple projects – When some similar projects are added to the current one without proper rigor on the impact, things can mess up both the projects. Such consolidations should take into account the synergies.
- Desire to avoid conflict/customer-pleasing – There are many project managers who do not have the ability to push back. So what do they do? They hold the word of customers above everything without a counter. So, if a pushy customer wants something, whether it makes any sense or not, they accommodate it.
Changing times and situations may require a change in requirements
Times change and so do situations. In such an event, it may be important to change the set of requirements that the team is marching towards. So scope change becomes imperative. These situation changes may be triggered by anyone or even outside situations like legal regulations.
- Third-party products, supporting systems, and technologies – an application that the project may be working on, may be linked to or dependent upon other systems and technologies. If those systems, technologies, and applications change then obviously that will have a major impact on the delivery of the current application. In such cases, it will be important to be aligned with the new changes.
- Government regulations – When the government changes its regulations, specifically without much warning, then projects that are impacted by those regulations need to factor in the change. If they do not, they will keep creating things that are useless or ineffective
- Market and trend changes – so many projects and corporate initiatives fail because they fail to factor in the trends in markets and businesses. It is important to keep up with new changes in the world. If one does not have a clear future vision, then one’s products will wither away. For example, in the case of Polaroid, the whole product line went away due to digital cameras.
- Competitive positioning and emerging opportunities – As the competition changes and new opportunities emerge, the fundamental assumptions for the project may change as well. In such cases, the project may need to review its scope to deliver a meaningful outcome.
Famous Examples of Scope Creep
Berlin’s Brandenburg Airport was in the planning phase for almost 15 years before it’s construction began in 2006.
It was slated to be completed by 2011. And then it was supposed to open in 2019, which has now been moved to 2020 (“Eröffnung im Herbst 2020?”Garantien für den BER kann keiner geben”” [Opening in autumn 2020? No guarantees for BER to be issued]).
However, some sources are saying that it could very well be delayed until 2021 (“Tuev bezweifelt Zeitplan für BER” [Tuev doubts BER timetable-airport supposed to go online this year and go into operation next year – Tuev is skeptical]. airliners) – a full 10 years after the construction began!
Courtesy – OID.org
There are many reasons for the delay, one of the major ones is scope creep. The General Manager of the Airport Management company, Mr. Schwarz, wanted to plan for the increased forecast of increased air traffic and therefore added in a north and south ‘piers” which changed the main terminal from a rectangle to U shape and increase the floor space substantially.
He also added in a second-level for shops, boutiques, and food, like those in Dubai.
This sudden scope creep added to the delay and contributed to the project delivering a “ghost airport”! Here is a good video to understand the case study for the Berlin Brandenburg Airport project.
Conclusion
Project managers need a certain body of work to deliver. This definition of the work to be delivered is covered under the project scope. If the work to be delivered is a constantly changing moving target, then delivering anything to a schedule and cost becomes impossible. That is why Scope definition is critical. Any changes to the scope and defined body of work needs proper consideration. That is why a Change Control Board and its approvals become critical in managing the projects.
Scope Creep is, therefore, best managed by institutionalizing a process and rigor that has no ambiguity. For, any ambiguity in the process puts the onus on the project manager and his team to push back and manage to the ever-changing scope. That is unacceptable and not healthy. For, this ambiguity creates variations that do not help deliver projects consistently.
Understanding Project Scope Creep, its ramifications, and the mitigating project management processes is key to enhancing the quality of projects.
