Now that we have collected requirements, let us see how to define scope…. from… requirements.
Yes! Requirements are the first input to this process, which is the output of Collect Requirements process.
By defining scope we are basically developing a detailed description of the project and product that it creates.
You can download a sample project scope statement template at the end of this post.
Exam pointer: The easiest way to remember sequence of process (exam requires you to remember the sequence) is to understand how they are related. To understand how does output of one process become input of the other.
For instance,
With this you have logically deduce all processes of Project Scope Management Knowledge Area!
[continue reading…]
In the previous post we looked at some of the tools and techniques for collecting requirements in a project. Let us look at the remaining ones – 6 items on the left side of the mind map below.
Decision making as a team
These are used when many alternatives are available on a particular requirement and you need to decide on one based on inputs from collective intelligence of stakeholders. These are also called collaborative decision making techniques.
The main advantage of this method is – when individuals make decision they are influenced by their liking, risk taking appetite and abilities, whereas when a group takes decision it is more practical and not influenced by individuals characteristics.
(click on the image to open in a new window)
[continue reading…]
Take a quick look at the interesting and very useful tools to Collect Project Requirements.
In this post we shall look tools on the right side of this mind map.
Let us look at an example, first.
Acme Hospitals wanted to build a patient health data management system. Alpha Software Solutions got the project and put Dean in charge of the project as project manager. Dean got the project charter, got hold of stakeholder register and started of on collecting requirements.
[continue reading…]
Take a moment and Google up reasons for project failure.
What is the common reason you would find in top few?
Articulated in different words, meaning the same – lack of clarity on requirements.
Ulad Shauchenka analyzed various failed projects and wrote the book ‘Why Projects Fail’. He shares some of the findings from research surveys in this book.
Three out of five research findings have reasons related to requirements –
- Unclear goals and objectives that change during the project (Coverdale Organization research)
- Incomplete requirements (Chaos Report)
- Poor articulation of user requirements (OASIG Study)
Sample these findings from some of other sources –
- Failure to adequately identify, document and track requirements
- Poor or No Requirements
- Unclear goals and objectives
- Loose definition of project scope and management
- Vague requirements [continue reading…]
Scope management plan ensures that the project contains all the work that needs to be done, and not anything else.
Here second part is as important as first part. Any effort put to do something other than the scope, is a waste of time, resources, and it may even upset customer. Project manager needs to continuously keep a tab on the work and course-correct whenever team starts doing work out of defined scope.
In this context there are two ways in which team may end up doing more than what is scoped.
Gold plating and Scope creep
Consider the example of a web-based hotel room booking system.
An over-enthusiastic developer decides that it is ‘cool’ to display an additional page with luxurious amenities in the hotel just before committing a room booking transaction by the guest. This additional work takes him two more days of implementation effort. QA team does not have a requirement to really test this feature, so they just test by themselves and deliver the product.
When customer looks at the product she is surprised to see this additional ‘feature’. She knows that the most important goal for business is to make customer book the room in the shortest possible time on the website. Any additional ‘delay’ results in cart abandonment 15% of the times. And this ‘cool’ feature defeats that business objective.
She rejects the deliverable as it violates their business rule.
What is happening here? [continue reading…]
Knowing the difference between product scope and project scope is vital, and can be confusing.
Dictionary meaning of Project is “an individual or collaborative enterprise planned and designed to achieve an aim”.
Product is defined as “a good, idea, method, information, object, or service that is the end result of a process and serves as a need or want satisfier”.
Keeping these definitions in mind, let us look at scope of project and scope of product from the perspective of PMBOK®.
Scope of a Product refers to the features, characteristics and functions of the product, service or result.
When you look to scope the product, you will think from end user’s perspective, and plan for all the features that are useful to end user. Outcome of a project is a product, service, or result.
[continue reading…]
