Software projects can become very complex because they often involve many people working together at a time. The people working together include developers, designers, analysts and clients.
All these groups of people have to come together to realise the finished software product. Whilst some projects finish on time, many often go beyond the initially estimated time and budget. According to Mackinsey, about 45% of software projects go over budget and 7% go over time.
One of the main reasons this happens, is a phenomenon called scope creep. Scope Creep (also called Requirement Creep, or Kitchen Sink Syndrome) in project management, refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins.
Scope is what is initially agreed as deliverables for a project, which specifically defines what needs to be delivered, over which time frame, and at what cost. Scope creep is a big risk in most software projects, and has to be carefully managed.
Whilst clients are the most obvious source of scope creep, it should be noted that scope creep can arise from factors both internal and external to a software development project. Development team members, project managers, third party development agencies, and users can also be sources of scope creep.
Operational efficiency is what takes the biggest hit from scope creep. Any prudent project manager would specify the deliverables in a comprehensive document, ideally signed by both the client and the developer. The specification would specify all that needs to be done, and the necessary timelines, as well as cost.
Unfortunately and quite often, the client would find that, they have a new requirement that they forgot to mention initially, or were not aware that they needed it. Whilst it might appear simple to just add the new requirement to the project; it can at times be difficult.
Adding a new unscheduled feature might mean having to redo some parts of the project, which means the project will likely go over time and budget. These necessary changes affect operational efficiency, and should not just be added to the project, without rewriting the project specification.
Not having clear scope, and not having clear agreement to what constitutes the scope is a major cause of scope creep. It is crucial to set out the scope in a specification document, and have both the client and the developer agree to it, and sign.
Without this, there are no clear guidelines, to clearly indicate to the client, when their request is out of scope and the developer may not easily realise when scope creep is occurring.
Another cause of scope creep, is not involving the client throughout the project, and also not raising issues proactively. It isn’t a good idea to wait weeks or even months, before showing the client the work done.
A good approach is to involve the client every step of the way, and proactively raising issues with them as they arise. An Agile approach is a good way to do this. The blog post titled, Agile vs Waterfall Software Development, is a good article that goes into detail on the this approach.
Quality Assurance and testing can at times take longer than initial estimates which results in scope creep. It is important to set out the guidelines on how testing will be conducted, early on in the project initiation phases. Diligence should also be applied when making estimates, rather than relying on wild guesses.
Not prioritising features can also cause bottlenecks, and result in scope creep. To mitigate this effect, it is important to identify features that are necessary to release a usable product, and then prioritise accordingly, if the Agile approach is being followed.
Just as it is important to involve clients early in the project, actual users of the software should also be engaged early. A mechanism should be in place to incorporate user feedback into the product, at every step of the development process.
Change management is no easy affair, and can result in significant scope creep. It is important for all stakeholders involved, to agree on a clear way for handling change. Clearly defining change management guidelines, will avoid a lot of headaches in the future of the project.
Since scope creep is a common occurrence in software projects, it can be a source of dread for most project managers. Even if this is the case: I say it should be anticipated and prepared for accordingly.
It should be prepared for, because it represents change, and change can be a good thing. The important thing is to make sure the client is aware that, feature requests that go beyond the previously agreed terms, will require a change agreement to implement them.
Preparing for the reality of the existence of scope creep, makes project managers more prepared and better able, to tackle the complexities of project management. By anticipating scope creep, with the understanding that all that is required is preparedness, project managers will be able to confidently step into their roles.
Want to hear some more from the Webmobyle Blog? Please
Leave A Comment