Tuesday, March 27, 2007

Quantifying Scope Creep using Scope Creep Index

Background

Over a period of time the software industry evolved its ways of managing software development projects with increased maturity by devising, and adopting the methodologies and recommendations of various best practices mentioned in process standards like CMM/CMMi, ISO 2000:9001, TickIT, Spice and BS standards. The organizations adopted these practices in order to manage the projects in a mature way and gain competitive advantage while doing pre-sales. However, the software engineers found it hard to complete the plethora of documentation imposed upon them with these methodologies in addition to their prime deliverable—working software code. The main problem in adopting to these documentation practices was the need to update the documents and records timely with each change request consistently.
The industry found a solution to this problem with “Agile Manifesto”. Agile Methodology was developed with the philosophy to develop software with the least amount of documentation (doing only the ‘needed’ amount of documentation) and accommodating ‘change requests’ with open-arms. This philosophy was found to be fruitful and is actually very effective in getting the working ‘production ready’ software. The Agile practitioners appreciate this ‘sex appeal’ of accepting and doing changes as and when proposed with least documentation. However, in doing so the ‘intellect’ of managing the change implied in Agile Manifesto is lost somewhere. This leads to project delays and failures at times.

The followers of traditional SDLC who try Agile Methodology with a great understanding of the ‘sex appeal’ and less thought about its implied ‘intellect’ reject Agile Manifesto with the claims of project delays.


Managing Scope Change

I have burnt my hands a couple of times with the Scope Creep – the name given to the phenomenon of frequent scope changes – leading to some of the project delays.

With a deeper understanding of the situation, I have tried to device a way to manage scope changes in a better way by using Scope Creep Index.

There is no standard term prevailing in the industry with the name of Scope Creep index. Neither I could find any practised way of monitoring Scope Creep quantitatively in various resources on the internet. I therefore coin the term of Scope Creep Index for my own use and for the benefits of the interested readers.

Scope Control Vs Scope Monitoring

Working in the offshore software development project for the requirement specified by the client involves two different aspects of Scope: “Controlling” and “Monitoring”.
Sitting at the offshore location working as a contractor for client’s project and performing as per the scope indicated by the client, we can only “Monitor” the scope changes. “Scope Control” can be done by the client only. We as a contractor can (and should) provide an indication of a scope change by ‘monitoring’ it quantitatively, so that the client can ‘control’ it at her end.
This is the basic premise with which I planned to device the Scope Creep Index.

Factors included for Scope Creep Index

As per my observation of the past few projects, the following factors affect the scope creep: 1. Baseline Deliverables, 2. Supplementary Work Items, 3. Scope Impact (& its weight), 4. Phase of Change Inception, 5. Estimated Effort, and 6. Additional Effort.

1. Baseline Deliverables: The agreed upon deliverables listed down in the initial Work Breakdown Structure at the start of project. The baseline deliverables indicate the initial scope of work.

2. Supplementary Work Items: The additional work item that may be requested as an associated deliverable along with an existing Baseline Deliverable OR and additional Work Item requested to be delivered over and above the Baseline Deliverable. The weight of the Supplementary Work Item can be actually the weight assigned to the Phase of Inception.

3. Scope Impact (SI): The Impact of the requested Scope Change can be classified in any form. I have used the plain and simple ‘Low-Medium-High’ classification. Each classified Scope Impact value can be assigned a weight to it. Ex: Low=0.3, Medium=0.6, High=0.9.

4. Phase of Change Inception: We follow Agile Scrum approach wherein we divide the project work in multiple ‘Sprints’. Each ‘Sprint’ is then divided into multiple Sprint Phases. We use ‘Design-Code-Test’ phases in each sprint. The sprint phase in which the scope change request is raised, affects the difficulty of accommodating that change within that sprint with an increasing trend. Therefore, it made sense for me to assign weight to each sprint phase for evaluating its impact on project schedule. It is easy to accommodate change during Design phase while the change requests coming during Test phase are quiet hard to accommodate. Therefore, I assigned Design=0.1, Code=0.4 and Test=0.8 weights.

5. Estimated Effort (EE): The effort required to develop each Baseline Deliverable Work Item in person hours.
6. Additional Effort (AE): The effort required to develop each Supplementary Work Item in person hours.

Scope Creep Index: Calculations
Supplementary Work Item Weight (WT) = Weight of Phase of Inception.

Scope Creep Index =
Additional Effort (AE) / Estimated Effort (EE) * (Supplementary Work Item Weight (WT) + Scope Impact weight (SI))

Assumptions: In case of a completely new work item being gives as a Supplementary Work Item, the Estimated Effort would not be available. This would make the Scope Creep Index calculation impossible. Therefore, I assign Scope Creep Index a value of 100 for such mutually exclusive Supplementary Work Items. This is a hard-coding for a special case in this formula.

Accommodating Change Vs Spill Over

The decision to accommodate change within the sprint or to take it as a spill over for next sprint can be made by assigning a threshold limit for the Scope Creep Index. For example, we have decided to accommodate the changes within the sprint if the Scope Creep Index value is less than or equal to 0.35. If the Scope Creep Index exceeds the value of 0.35 we consider it as a spill over for the next sprint.

Project Managers at the client side can benefit greatly by using this simple metrics since it raises the flag as soon as the change request is made. Also, it helps in evaluating the time/phase/state of the project during which change requests are raised. Proactive decisions can be made based upon this metrics easily.

Since it is a completely indegenious way, I welcome all sorts of comments/criticisms/feedbacks/enhancements/inputs/recommendations from everyone who is reading this.

Tuesday, March 06, 2007

A New Feather: Harsh Vardhan PMP

Well, as usual after spending around an year of post-MBA boredom, I have succeeded in breaking the pattern. Yet again!

Harsh Vardhan, PMP is the new title I have acquired now.
Well not discounting the MBA, I would prefer to be called Harsh Vardhan, MBA PMP now onwards.


Sounds like too much of whistle blowing, but it is required.

Now a new set of qualifications, new set of revised aspirations and a new job hunt. This is the saddest part. I always wanted to start on my own, but Personal family commitments have reduced my risk taking abilities. Few more years of working for others! phew.
:-)
 
Where are you going? Create your own travel map!
View Harsh's TravBuddy Profile