Thursday 28 April 2011

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.
1st 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.
2nd 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 2nd 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.
3rd Release: The next plan was defined and implemented and then the 3rd 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?
4th 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 3rd 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

Monday 25 April 2011

Earned Value Management – A Very Simple and Effective Tool for Project Managers

Every morning waking up, have you ever asked yourself the following three questions which of PMs/TLs are responsible for? Firstly, where are you on project schedule? on time, late, how late, how early…? Secondly, where are you on the budget? currently using more than or less than estimated? How more and how less? Thirdly, where are you on the work completed? How much completed?

I got someone answered like below:
“Most of my project tasks completed as scheduled, so I am on track”
“Just a few tasks behind schedule, so I am ok”
But how about when many tasks are behind schedule, when and how to take corrective actions?
By using Earned Value Management (EVM), you will be able to answer like I’m currently ahead schedule 10% now, I’m over budget 25% and so I need to analyze to find corrective actions now, etc.
This article helps you to quickly understand the method which you can start using immediately. It will not go through all concepts of EVM.

1.       Background
EVM method is simple (actually so simple) because you only need to remember three elements:
·         Plan Value (PV): How much you plan to archive up to date.
·         Earned Value (EV): How much you have actually archived/earned up to date.
·         Actual Cost (AC): How much you have spent up to date.
Let do not think too much on these 3 elements now, just remember there are 3 elements, PV, EV and AC.

2.       Case Study:
I have trained EVM a few times, I realize one case study which is very good to get started. Let’s take a look on the article telling about Bill Gates’ 10 advices to young people
There’re totally 51 sentences in the article and I want it to be translated to Vietnamese and here are what happened:

Step 1 (Estimating): I asked groups of 4 trainees, including the project manager (PM), to estimate how much it cost with assumption that cost per minute for a normal translator is 1 dollar. Then:
·         The best estimate would take 40 minutes to complete
·         Total cost of the project then would be 40 dollars.
·         Unit cost per sentence would be 40/51 = 0.78 dollars.

Step 2 (Resourcing): PM of the selected group had to pay for other 3 members with rates as below:
·         Intermediate level of English would be paid 1 dollar per minute, two of them were at this level.
·         Advance level of English will be paid 2 dollars per minute, the remaining member was at this level.

Step 3 (Planning): PM planned to use only one member at Intermediate level to do the whole work. She committed to me to deliver the Vietnamese version after 40 minutes. This meant she planned in every 5 minutes, she would complete a number of sentences which worth 5 dollars in average. I was the project sponsor and I agreed with the plan which meant the plan was baselined/agreed and it looked like below chart.



Step 4 (Implementing): I requested to stop translation every 5 minutes and report the result of how many sentences were translated.
After the first 5 minutes, 5 sentences were completed translation, let’s take a look at the three elements at this point:
Firstly, PV = 5 dollars as planned above.
Secondly: there were 5 sentences completed translation and so I would pay some money to PM (or PM earned from me some money) and this was where we calculated for EV: EV = 5*0.78 = 3.9 dollars
Thirdly, PM had used one member for 5 minutes, she had to pay salary and this was where we calculated for AC: AC = 5*1=5 dollars
Similarly, every 5 minutes PM collected and recorded the three elements and after 15 minutes she had the below result:



What did it mean at this point?
PM planned to complete 15 dollars while she only earned 9.36 dollars, this meant she was behind schedule.
PM spent 15 dollars for paying salary while she only earned 9.36 dollars, this meant she was over budget.
At this point, she needed to do some corrective actions to be able to deliver the project on time. She decided to add the member at Advance level of English. After 5 minutes, the result looked like this:

She seemed back to track now with schedule because what she earned was more than to what she planned. However, she was still in trouble with budget when spending too much more comparing with what she earned. She believed the first member at Intermediate level learned some experiences from the last period, so she decided to use only one member to continue. After 10 more minutes the result looked like this:

She spent all approved budget, 40 dollars for paying salary, but she needed to continue to deliver the project on time. However, there were only 4 sentences left to be translated and her member only needed to spend 2 minutes to complete everything and here was the final result.


It was still good when she could deliver the project on time, she only run out of budget 2 dollars which meant 5%, an acceptable variation.

3.       Lesson learned:
Although I composed the above case study with some markup, it showed that by using EVM, we can see the project health in term of cost and schedule very early to take corrective actions in time.
Moreover, this method not only tells us the potential issue of project but also gives us an objective judgment of how much critical the problem is quantitatively. At the minute 15th, PM was behind schedule 30% = (7.02-10)/10 and over budget 42% = (7.02-10)/7.02. This helped PM to take corrective action to put more resource to speed up the schedule.
Similarly, at the minute 20th schedule PM was back to track and it was about time to focus on cost to get it back on track and this was why she reduced the resource by keeping only one member. At the minute 30th, she decided not to use the working member for 5 minutes, but only 2 minutes to save the cost.

4.       Follow up
This article aims to help you to understand the 3 fundamental elements of EVM (PV, EV and AC). Once you understand them clearly, there shouldn’t be any problem with using other elements like CV, SV, CPI, SPI etc. For all concepts of EVM, below are some references: