Project Management Software
Specialists in Project Infrastructure
Scope Creep is not only Inevitable – It’s Natural
Every IT project is executed with a set of deliverables, and has an expected closure time. Prior to this closure period, there are a predetermined set of tasks and activities to complete the project successfully. These tasks constitute the scope of a project. Since a project schedule is closely tied to the delivery time line and the scope, a little variation in the scope can affect delivery and in turn affect the success of the project.
This inching forward of scope to introduce more requirements that are not included in the initial planning of the project whilst maintaining the same time frame for project delivery, is called Scope Creep. Scope Creep is the pejorative name given to the natural process by which clients discover what they really want.
The scope creep can be classified based on the users who creates these changes:
Business Scope Creep
In an IT project, regardless of whether it is outsourced or built in-house, the project team works with the client to gather the requirements. This requirement definition analysis phase involves meetings, interviews, and questionnaires with the client about the current system and their future needs. In most cases, clients are unable to specify exactly what they want in the beginning until they see the product. It is also often difficult for business users to visualize how the new system will be until they see it.
When the users do see the new system for the first time, changes may be needed because any new applications will be initially unfamiliar to users. Most of the times, the user perspective is to always look for things that won’t work, rather than the things that do work in the system. The approach the business users have in mind is that,
“We’re spending so much time and money anyway, so let’s add this during the testing phase”.
This expands the scope way beyond what you can accomplish or really need.
Solution to Business Scope Creep
Technology Scope Creep
The scope creep created by the technologists can be broadly classified into two categories –
The project team or an individual who wants to please the customer and is reluctant to say “no” to a change in the requirements.
1. The project team’s responsibility is to let the business know that the requested change is considerably different from the requirements approved during the project scoping process. The team should provide the business sponsors with the options and explain to them how these changes could impact the budget, timelines and resources. The options are
2. Since the user can visualise the system, perform a visual walkthrough session during the requirements phase to define what the client wants before the system is built. This iterative Prototyping Approach or Joint Application Development (JAD) session with the client can help the team to identify the features and can deliver a final product close to the client’s needs and will result in project success.
The programmers/developers who adds features and functionality that have not been specified in the approved requirements definition. The reason for these changes could be the business requirements are lacking the details or the programmer is a perfectionist.
The conclusion from this article is that “scope creep” is always a change or growth of project scope. Instead of preventing the changes completely, we should work as a team to effectively manage the changes by not affecting the project timelines and budget.
Suresh Babu is an architect specializing in SOA (Service Oriented Architecture), Web Services and FDLC based (Feature Development Life Cycle) project management. He has more than seven years of experience in all phases of software development life cycle and provided various J2EE based solutions in consumer banking business. His area of expertise includes Object Oriented Analysis & Design, UML, J2EE/J2ME, XML/XSLT, WebSphere, EAI and FileNet. You can reach him at email@example.com.