Thursday, August 27, 2009

Project Scope Management - Few Learnings...

Scope management is one of those areas that can ruin a project, if not properly managed. Unfortunately, It is also very difficult to manage. I have given below a few lessons that I have learnt so far– in my journey as a project manager.

Before going into the lessons learnt, I have given definitions for few important terms used in this post.*

Domain: Field of study.
Domain Knowledge: In software engineering, domain knowledge is knowledge about the environment in which the target system operates
Scope: The sum of the products, services, and results to be provided as a project.
Requirement: A condition or capability that must be met or possessed by a system, product, service, result or component to satisfy a contract, standard, specification, or other formally imposed documents. Requirements include the quantified and documented needs, wants and expectations of the sponsor, customer and other stakeholders.
Business Requirements describe, in technology free terminology, the business process used by people to achieve business goals.( Payment processing, expense report approval …) .
Functional requirements are those that define specific behavior or functions of a system using technical and system terminology . For e.g. create voucher, edit address and approve Voucher
Non Functional Requirement (NFR) is a requirement that specifies the criteria that can be used to judge the operation of a system, rather than specific behaviors. create voucher process should take less than 10 milli seconds or Monthly Expense Report should be generated within 2 seconds for a division or the system should be available for 99.98 % of the time. For more information on what all can be a part of NFR, refer to the section “non functional requirements area” here.

All of the above can be linked together as shown below (from the top most level to the bottom most level)

Domain--> Scope--> Business Requirements (Product) & Services -> Functional Requirements and Non Functional Requirements.

If the above can be represented pictorially, it will look something like this.

Now over to the lessons learnt, having burnt my hands as a developer and a project manager. There is no specific order in which the lessons are shared.

#0 In Project Management every task represents money (directly or indirectly). As a manager, we have a certain budget allocated for the project and we usually also have the person days and calendar days to be spent on the project. If we are not sure on what tasks we have to do as a part of the project or how much time we have to spend for the tasks, then we will easily over run the budget provided and the overshoot the effort and go way beyond the calendar timelines. Hence a project manager should never forget this.

#1 Business Requirement is not Functional Requirement. Business Requirement as the above link shows is related to the domain. For e.g. the purpose of the project may be design and build an ATM machine. The functional requirements may talk about the kind of cards serviced, exception handling. It is easy to Business Requirement and Functional Requirement and lose track of the project. Business Requirement should always be broken down further to come up with requirements hence is not directly code-able. Any project that takes the effort estimated based on the Business Requirement, as the final estimate is doomed for failure.

In one of the projects I was a part of, we estimated for a developing a report that simulates an agreement’s performance (taking into consideration, past data) – around 6 days. Atleast that was the effort I was given, when I took over as the project manager. But we actually ended up spending around 60 days to develop. And later found out that it was impossible to test it properly without sufficient data. The last time I checked, the business users were still using the excel sheets they originally used and not this report. The mistake we did was that we scoped the report based on a business requirement and not functional requirement,

#2.Business Requirement has two components – Functional and Non Functional requirement (NFR). When a Business Requirement is broken down further, it should always be broken down in to functional and non functional requirements. If a project has only one of them and not the other, that means the project is asking for more trouble.

#3 Non Functional Requirement – If not handled properly can doom a project and do more damage. NFRs are a very important aspect for any commercial product/Application. Since NFR plays an important role in acceptance of any enterprise application, lack of proper follow-up and implementation on NFR has doomed the outcome of many a project. I am giving below the mail I got from a colleague - of a real life incident – of a multi million dollar deal lost- because of not concentrating on NFR. For the sake of confidentiality, project names and people names have been changed.

I had enquired about a project that I know of – as it didn’t give specific importance to NFR at all - and this was the response. This colleague worked as a part of oracle performance fine-tuning team.

One Friday evening, there was a mail from the Senior PM to my boss - the mail said that there were some DB performance related issues and my boss was supposed to iron out these problems over the weekend b'cos the app was going live next week. They are specialists in last-minute boss analyzed the DB at length
My boss was barking up the wrong tree - he talked to me at length about init.ora parameters, osp', views and other clutter. I asked him what the precise problem was?...
he said that the system was able to cater to only 80 users or so.....on addition of more clients, the system was hanging....(the target was 300 concurrent users)

We visited the project team and on again asking for the precise problem the same statement was made. I immediately countered that scalability issues were traceable back to screwed up architecture and could not be resolved looking at the DB performance. The PM responded with a sheepish grin that the clients had expressed the same opinion in one of the uat meetings. But dev team was unable to address the problem thru the architecture and were desperately looking at a possible shortcut through the DB side. Bingo!

I guessed that the old pass-the-buck game was being played - the architecture team was trying to foist the scalability issue on the DB side - they had their own limitations – anyway, my boss and I sat thru a non-value-added exercise of statspack analysis and later sent out a mail in which I insisted that he guard his statspack observations with the clear statement linking scalability to architecture and relieving DB of the fault.

Dead silence from the team in the weeks after that ......... later I heard that they had somehow scaled the system to 120 users but were unable to get further. .........

To cut a long story short, the Senior PM resigned immediately after this happened and the company lost a 15 million USD contract which depended on the success of this project.

#4.Follow breadth first approach to efficiently manage the scope: When it comes to managing the scope of the project (assuming the domain to be a vast terrain), It is better to have a breadth first approach and then dig deeper. This means that we first ear-mark the area that we will be covering and then dig deeper into it. This way we ensure that we don’t leave anything out. Even if we don’t get everything that has to be covered as a part of the project immediately, trying to draw the lines will ensure that we reach there sooner than later.

#5 Digging deeper leads to applications that are feature rich (if it gets implemented): Once we have drawn lines and ear-marked the area that we will cover, depending on the time and money available, we can dig deeper to come up with an application richer in feature. I call it as requirement mining. The more you mine and implement, richer will be the features of the application.

#6 Define what ‘Done’ or ‘Finished’ means: It is better to define and agree on what the product of the project will look like, once requirements are implemented. This will help to ensure product acceptance is made easier.

* Few more definitions below
Deliverable: Any unique and verifiable product, result or capability to perform a service that must be produced to complete a process, phase or project. Often used narrowly in reference to an external deliverable which is a deliverable that is subject to approval by the project sponsor or customer.
Product: An artifact that is produced, is quantifiable, and can be either an end item in itself or a component item.
Service: Useful work performed that does not produce a tangible product or a result, such as pefroming any of the business functions supporting production or maintenance.
Result: An output from performing project management processes and activities. results include outcomes ( integrated systems, revised process, etc,) and documents ( policies, plans, etc.)

No comments:

Post a Comment