Scope Management in Software Development Project

1.       The Story

I used to observe one project which was planned to be completed within one month. However, after more than four months it’s still in progress of fixing and implementing the demands which the client thought they should have been implemented. The team had been working so hard release by release and the client kept escalating but it’s still incomplete.

The project was to port one application written in VB6 + Ms Access to Web application + SQL Server. Initially, Project Manager (PM) said we only needed to map one to one from the VB6 application to the Web. One business analysis was assigned to write down the “software requirement” for all functionalities of the current application. The project was scheduled and controlled very well and the development of the new application was completed on schedule within a month.

1^st Release: After just some playing around with the Web application, client decided to stop testing and gave feedbacks on the new application, most of them were not really relating to the current functionalities of the current VB6 application but related to the common behavior of Web application such as:

1.       My working environment is IE6 (an old version) and some functionalities don’t work on it. (all had been tested in Firefox successfully)

2.       The theme of the Web application doesn’t look right. I will send my environment web theme.

2^nd Release: PM took these feedbacks and put together into another release plan. He and his team had worked hard to complete this plan and then delivered the application to client for the 2^nd round of UAT. However, just after running a few test scenarios, client decided to stop testing and went back with other concerns:

1.       I am able to edit pre-defined data such as positions, departments in MS Access database, now I can’t do it with the Web. If I have to open the console of MS SQL, it’s not right to do.

2.       How is about my existing data? It must be migrated to the new platform.

3^rd Release: The next plan was defined and implemented and then the 3^rd round of UAT still had problems:

1.       Why doesn’t the search function support wildcard?

2.       Tab order is very inconvenient for business user.

3.       When two users edit the same record, why is there no warning?

4.       The function of “export to CSV” existed in the VB6 application, why is it missing in the new Web application?

4^th Release: This release seemed to be OK;, however, client had their technical team to review the source code and continued to raise concerns:

1.       Why don’t code comments follow a common style?

2.       Why is a 3^rd party library used?

3.       Why does the application use system users to login, instead of application defined users?

4.       I need to look at the system architecture and basic design for main functionalities.

2.       Background

2.1.    Scope Definition

According PMBOK v4 with scope management, there are two kinds of scope: Product scope and Project scope. Now, let’s see what they are in software development projects.

2.1.1. Product Scope

It is functional requirement and non-functional requirement. Nowadays, functional requirement comes directly from client and is often written in Use Cases, but there’re still many other forms for writing functional requirement. Non-functional requirement comes from constraint from client and also comes from the expertise of project team or process asset. Common areas of non-functional requirement should be ready in the process asset of an organization. For example, for a Web application, the project team should consider common non-functional requirement as below, even if client doesn’t request.

GUI requirement: Is there any specific theme required? any layout standard required? etc. Interacting with external systems: Performance: Any requirement on response time, concurrent users, etc. Security: Any constraints with client’s system environment, is Single Sign-On required? Etc. …

2.1.2. Project Scope

The product scope mentioned above is quite important, but the project scope which is being mentioned here is a lot more important. However, Project Managers who are lacked of training often miss this resulting in failure in term of time of delivery, cost of delivery and quality. Now, let’s see what the Project scope is.

In theory, project scope is activities which are required do to and how much the team needs to do with these activities to create products and provide services. In software development, project scope defines which activities the project team needs to do such as whether unit test script is required and how much test coverage is expected. Let’s take a look at the below example.

Activity	In or out of scope?	Requirement
Requirement	Yes/No	Which level of requirement document is required?
Architecture	Yes/No	Which level of architecture is required?
Detailed Design	Yes/No	Which level of detailed design is required?
Implementation	Yes/No	Which coding convention is required?
Unit Test	Yes/No	How much test coverage is required? Is it required to be automatic?
System Test	Yes/No	Similar to above
Build and release	Yes/No	Similar to above
Acceptance Test	Yes/No	Similar to above
Project management	Yes/No	Similar to above
User support	Yes/No	Similar to above

2.2.    Scope Management

Once the product scope and project scope are defined completely, they must be “signed off” by client and sponsor, or we call it is baseline. Then, we manage scope to make sure that we deliver what we committed, no more and no less. Lacking of scope management will result in:

·         Scope creep: requests keep occurring and the project is likely never finished.

·         Incomplete delivery: the application is delivered but some of the requirement is still not implemented.

Project scope management with WBS: (refer to WBS here)

When project scope is defined carefully, its required activities become first level of project WBS. From this, PM manages to break down to have smaller work packages and tasks. Managing WBS and planning to complete it seems to be fundamental for PM so when the project scope is done in the right way like this, there shouldn’t be a problem. However, the challenge is how to manage the product scope.

Product scope management (or Requirement Management in software development projects): Once the product scope (or software requirement) is signed off, there are two things we need to manage. Firstly, we have to make sure any change occurs must go into the Change Control process. Secondly, we have to make sure all of the software requirement will be implemented fully.

What I want to emphasize here is how to make sure what is defined in software requirement is fully implemented.

Back to the story at the 3rd release, the problem #4 is demonstrated for missing implementation. The “Export to CSV” requirement was mentioned as one bullet in the software requirement, however, developers missed it and the testers also missed it.

Instead of depending too much on project team members, there is  another tool which helps to track the implementation subjectively. It is the Requirement Traceability Matrix (RTM)which is as simple as the table below:

User requirement	Software requirement	Architecture	Detailed Design	Implementation	Test Cases	Build	Release	…

The output artifacts of the activities are filled in this matrix. For example, with the functionality “Log-in”, where it is architected, where it is designed, which source code it is implemented, which test cases it is written in and so on. One user requirement is only completed when all other columns are filled fully. The product is completed when the matrix is filled fully.

Imaging one project which contained 1,500 rows of user requirement, broken down to many releases within one and a half year. Without using this matrix, how could we sleep well at every release time. But by using it, we can early detect the missing activities and correct them in time.

3.       Lesson Learned

Back to the story of this article, the root cause obviously is lacking of scope management. All the problems/concerns reported by client should have been defined before going to execution phase of the project. Most of the times, Client’s need just focuses on the functional requirement which is simply porting all features from the old application to the Web application. However, it is the responsibility of PM to manage the scope beyond what client requires and this is why the PM Job exists.

Let’s take an analysis, we can map problems/concerns to the product scope and project scope as below:

Release	Concern/Problem	Root cause/Missing
1st	·         My working environment is IE6 (an old version) and some functionalities don’t work on it. (all had been tested in Firefox successfully) ·         The theme of the Web application doesn’t look right. I will send my environment web theme.	Product scope definition Non-functional requirement
2nd	I am able to edit pre-defined data such as positions, departments in MS Access database, now I can’t do it with the Web. If I have to open the console of MS SQL, it’s not right to do.	Product scope definition Functional requirement
	How is about my existing data? It must be migrated to the new platform.	Project scope definition User support
3rd	·         Why doesn’t the search function support wildcard? ·         Tab order is very inconvenient for business user.. ·         When two users edit the same record, why is there no warning?	Product scope definition non-functional requirement
	The function of “export to CSV” existed in the VB6 application, why is it missing in the new Web application?	Product scope management Missing RTM
4th	Why don’t code comments follow a common style?? Why is a 3rd party library used?	Project scope definition Requirement on Implementation and architecture
	Why does the application use system users to login, instead of application defined users?	Product scope definition non-functional requirement
	I need to look at the system architecture and basic design for main functionalities.	Project scope definition Architecture and Design

4.       Conclusion

There are many areas which PM needs to do well to succeed in managing projects. Scope management is one of the very important areas because failure in defining scope and managing scope will result in failure in delivering project even if other areas have been done well. Scope management can be summarized as below:

Scope definition	Note	How to manage
Product scope		Use RTM
Functional requirement	Product features required by client
Non-functional requirement	Constraints required by client or seen by project team
Project scope	Activities required to deliver the product	Use WBS