Importance of Scope in a development project

According to the Guide to the PMBOK,

"Project Scope Management includes the processes required to ensure that the project includes all the
work required, and only the work required, to complete the project
successfully. It is primarily concerned with defining and controlling
what is or is not included in the project."

This is not as easy as it sounds. It is probably the most important reason why projects succeed (do not finish on time, cost more than budget, etc.) The reason is probably because of the way the computer programs are written.

As it usually happens in any software project, the team working on the Application requirements is a team from another organization/vendor (Outsourced most of the times). Of course, the Customer has already signed the contract with his vendor for a fixed budget, based on a 50,000 feet user requirements.

The Business Analyst (BA) of the Vendor is given the mandate to write a requirements document to book train tickets. Now, all the necessary scenarios to book tickets are envisaged. The BA comes up with his thoughts in a document (called as the SRS – Software Requirements Specifications) and submits it to the customer for review. It is very imperative that there is a representative from the Customer-side to participate in the document preparation.

The Customer, usually in a rush of time, has no time planned to do the review of the document. Lack of Dedicated time to do reviews of vendor deliverables has often resulted in a gap of understanding between customers and vendors. He/she does a high-level glance of the document and if he feels it is around 75% of what he feels is right, asks the team to start further work.

This is where the first assumption occurs between the Customer and the Vendor – the Vendor thinks that the customer has agreed for the scope to be ‘as-is’ specified in the document. The Customer thinks that this is a representation of the system – he/she feels that there is always an opportunity to detail on the nuances of the requirements that have been documented. These assumptions are never discussed in the open. Probably, it is not intentional most of the times.

The team then starts off further work (design and later development/testing) on the application, always assuming that the SRS document is final. The initial Business/User Specifications is no longer refered to (which is fine if you consider the Vendor’s assumption).

In a RUP process, the Customer sees the end-product only during the latter stages of the development life-cycle. This can lead to surprises in the testing phase. The Customer sees what has been delivered to him and hell breaks loose. He starts raising defects mentioning that these features were expected to work in a certain way. Now, the vendor team looks at the ‘defects’ and rejects them, calling it as ‘Change Requests’. They refer the Customer team to look at the SRS document and point to areas where the extra logic should have been present. This is where the assumptions play a big role. Because of the assumptions, there is a conflict at this point between the two teams. Early Access to the deliverables is one way to counter this risk. This will ensure that the customer has visibility to the application progressively. It will not give him a huge surprise after a long period (typically 6 months). This is one of the reasons Customers are tilting towards Agile development methodologies.

At this stage, it depends on the negotiation capabilities as well as the strength of Project Management skills of both the individuals involved at both sides to finalize on what is a Change Request and what is a defect. The stronger of them wins and based on the win, it is a change/defect.

This eventually leads to a delay in the schedule, thereby overshooting the initial deadlines. Cost is increased because of additional people involved for a longer period in the project. There is a huge pressure on the Vendor team to complete all the issues (whether defects or Change Requests) on time specified by the Customer. This results to a large number of defects in the code, thereby having an adverse affect on the quality of the application. By now, the project gets into a downturn – each defects affecting the morale of the developers, taking more time to fix them, delaying the deadline further and most importantly, reducing the confidence-levels of the customer.

Thus, Scope Control is an important component in any software development project.


Tags: , , ,

7 Responses to “Importance of Scope in a development project”

  1. ahmad Says:

    i totally agree with you, people mostly undermine the importance of a clear and consise scope and hence fail to get a good start at projects. This is specially true when dealing with the information technology projects. There is a misconception that scope can be managed along the way while developing the small IT and web based applications like website design, portal designing, and other web applications and the hurry to start up with the project without giving time to documenting its scope actaully leads you to big hassle and undesired wastage of time .

    we follow good project management practices at Eawestec Emerging Technologies

  2. PM Hut Says:

    As you said, in the case of development projects, Agile is probably the solution to this problem. One the other hand, Agile has its limitations, one of the most important points to remember is that “It has to fit within the organization culture”.

    I also do have to say that Scope Creep is a major issue when the customer thinks that specs are merely an idea of what s/he wants while the vendor thinks that they’re binding and anything outside those specs should be handled by a change request.

  3. Risks in Project Development « My Thoughts on Technology, Management, … Says:

    […] Front Page ← Importance of Scope in a development project […]

  4. Maggie’s Blog » Blog Archive » Importance of Scope in a Development Project « My Thoughts on … Says:

    […] “Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. It is primarily concerned with defining and …Continue […]

  5. Importance of Estimation in Software Development « My Thoughts on Technology, Management, … Says:

    […] mentioned earlier, scope is very critical for the success of a project. Once the scope has been frozen (or at least […]

  6. Collective Project Planning « My Thoughts on Technology, Management, … Says:

    […] the scope of the […]

  7. PocketCake Says:

    Great post. I am facing a few oof these issues as well..

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: