1. What is Scope Creep
2. Project Development Statistics
3. How It Happens
4. The Impact of Scope Creep
5. How Can Be It Prevented?
6. How a Supplier (IT Company/Developer) Can Prevent It
7. How Clients Can Prevent Scope Creep
Management of IT design projects is typically dynamic in nature. Standard theoretical practices of successful Project Management prove ineffective, especially in the flux of real-time project development ecosystems. Usually, IT projects disrupt when they reach ‘critical mass’ because of non-aligned expansion of scope of the project and the inability to contain ‘scope creep’ at gestation stage of the projects.
We at Per Square Media, understand that each IT project should follow optimized development in a given life cycle. This paper addresses the dynamics of containing out-of-turn feature requests for a project and sustain ‘scope creep’ curve.
Life cycles of complex web and app design projects, often de-accelerate, due to inclusion of innumerable REQUIREMENT REQUESTS (to approved scope-list) that disrupt the TARGET SCOPE of the project. The range of additional requests that are added to a design project, at various stages, after the scope definitions are already established – disrupt the scope of the project – causing what is variously called as ‘Scope Creep’, ‘Requirement Creep,’ or ‘Feature Creep’ of the project.
The overburdening on the project leads to disintegration in the project (due to the strain of supporting tertiary features that are external to the immediate deliverables of the design). Alternatively, it could just become unwieldy, sluggish in performance and not achieve actual target scope that the project was originally designed for.
The uncontrolled changes included in a project scope leads to weakening of the focus and generally relate to lack of clarity in definition, documentation of the project.
Reports on IT project management by leading research companies, such as Standish Group, over the past decade and more, have revealed that the success rates of projects (as per 2009 survey figures) stand at a dismal 68%. Of these, 44% of the projects had several inherent challenges that impeded smooth flow, performance and goal-achievement of the project. The other 24% of the project failed to achieve deliverables the project was designed for. Only 32% of all projects surveyed matched client expectations, achieved deliverables and costs of development.
Chaos Report of 2009 by Standish Group found that 68% of all projects are not successful
Scope creep occurs when products, functions, and/or new features are added without logical increase in required resources, extension of budgets for additional resources and extension of time lines. This typically occurs when the deliverables for the design are already defined or approved and subsequently new features are added.
In 1994, only 16% of projects were considered successful. The success rates doubled to 32% by 2009. This is revealed in survey data from Standish Group. However, the costs of project development are highly inverted in comparison to final success rates achieved. This is largely due to the organic latency of ‘Scope Creep’ in every project life cycle.
When a project manager lacks the expertise, experience, foresight and the skills in clearly establishing control over a project, scope creep (feature creep) is most likely to occur. In such scenarios, there is no clarity on the project expectations and will usually include ineffective communication as well. The combinations of these two factors are often enough to set a project off-course and lead to development of drastic creep in scope.
One of the major scenarios of scope creep develops when there is inadequate preparation on the requirements of the project. Typically, this is due to lack of clarity amongst all the stakeholders. The client is unable to visualize the end result and would follow a very common syndrome of ‘I’ll know it when I see it’; while it requires a few weeks of lead time for project analysts, project team, users and the development team to familiarize themselves with functions and transactions of a business to develop desired software processes. During the process, the assessment of requirements becomes unstructured and leads to duplicity and lack of clarity.
A major drawback in development occurs when stakeholders are not involved in conceptual stages and pre-analysis stages. The requirements raised by stakeholders will formalize requirements and eventually lead to taunt design, with room for scalable components, as developers and end-users are on the same page on scope.
Quite often than not, the domain and the lack of involvement of SME on the niche leads to a lag that allows for mismatch on features and non-addressing of complexity of the industry. The lack of preparation of meeting complex features also builds up focus as well as feature creep.
Every project shall involve average changes and if there is no established frame work to support change, the control on the project will be lost and lead to poor design and poor work flows. Hence, documenting, analysing, approving and allocation of resources on a regular basis are very important.
In a bid to provide value added features, development team may attempt to expand scope that may not match client expectations and lead to low satisfaction. If these do not bring in business results, a client could be clearly disappointed as well as cost development team in terms of time and extension of budgets.
The ‘Inertia’ that eventually builds up or CREEPS into an out-of-scope project due to overlaying and over-modulation of features of a project leads to irrational lag in development across all aspects of the project.
The first fall out of scope creep is overlaying of features that will overburden and impact agility. Second, the time lines also go out of scope impacting its economic viability and opportunities for application of the project. Third, the costs of development would far exceed the earlier estimated costs and would not prove to be good Return On Investment (ROI). Fourth, slow-rated development sometimes also leads to product redundancy and may prove to be a futile exercise for the client.
Technology drives development, and innovation leads to newer technology. This perhaps has been the fundamental tenet on which development across all sectors has been nurtured. This is more defined in telecom technologies as resources are all dynamic in nature and instances occur in real-time.
Traditionally projects such as in manufacturing industry etc., have always met project deadlines by following proven pathways as the trajectory is always LINEAR and all components of such projects are tangible.
However, in software development sectors, since deliverables as well as the resources are intangible, life cycles of project development bloat due to uncontrollable expansion of scope of project leading to challenged projects.
To overcome feature scope or overloading of features for defined set of goals the project shall achieve, several approaches are recommended.
One of the earliest reports on project management was in 2005 by research group Forrester, where a survey of project development pointed out that out of 692 technology influencers, one-third were corporate software development shops, not only late in delivering custom applications, but also fell short on the quality of the apps that were finally submitted.
Nearly a decade later, the Standish Group’s 2011 CHAOS Report finds almost same scenario. Half of software projects conducted between 2002 and 2010 were defined as challenged or complete failures. The number of successful projects had grown marginally from 32% in 2009 to 37% in 2010.
According to the report, the success of a project was defined only in terms of achieving target scope within projected costs. It did not consider if the project could handle changes or accommodate future changes.
The most effective approach would be to create a Work Breakdown Structure. The WBS can then become the prototype, based on which any of the following approaches can be adopted for maximum optimization of the software cycle.
Analogous: This offers scope for similarly shaped WBS to be reused or expanded for other projects as well.
Top Down: This method is ideal when the goal of the project is well identified and the requirement is to meet and achieve the goal.
Bottom Up: For aggregation of work from the project team and identification of the WBS elements and drawing up of task flows.
Agile software products are what led core competency to application and do allow for easy expansion or scalability.
Therefore, professional software development service providers offer maximum work scope at low investments.
Fundamentally, the reins of success of a project are held by the client. If the client is ARTICULATE and FIXED on the deliverables and SCOPE of his project, development shops will pretty much deliver on the dot.
Clients will have to have the vision of the goals they want to achieve and taking a ‘when we see it’ approach would prove detrimental to the success of the project.
The bottom-line of a successful web and app design development project is that once the gridlines of a project are drawn- scope, technical framework, work process and technologies- then revisiting approved products and services with reinforcement features would prove to be counter-productive.
Instead, adopting a module approach: A second-line of scope for additional, refinement of features; would help in focused delivery of determinants, in time and within cost budgets.
Engaging service providers with proven track record, high-profile technical expertise and low costs of development, would prove to be the best combination for a successful high-ROI design project.
