Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

Improve Project Success with Better Scope Management

~ By Avneet Mathur

Black and white UML diagram

The Project Management Institute Project Management Body of Knowledge (PMBOK) defines product scope as the features and functions that are to be included in a product or service. It defines project scope as the work that must be done to deliver a product with the specified features and functions. Project scope management is defined as the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.

Problems with Project Scope

The problems that may arise with the Project Scope are:

Ambiguous

Ambiguity in scope leads to confusion and unnecessary work. To avoid this, the scope needs to be clear and to the point.

Incomplete

Incomplete scope leads to schedule slips and hence finally cost overrun. To avoid this, the scope needs to be complete and accurate.

Transient

Transient scope leads to what is known as scope creep which is the primary cause of late deliveries and potentially "never ending" projects. To avoid this, the scope document needs to be finalised and remain unaltered for the duration of the project. Changes to the scope need to be made through a formal change process.

Uncollaborative

A scope that is not collaborated leads to misinterpretations in requirements and design. To avoid this, the scope document should be shared with all stakeholders.

Capturing Project Scope

The defence against all these problems is to clearly define the project's scope at the beginning. Once defined then validate that scope with all the key stakeholders, getting their buy in and consensus on the scope before charging ahead.

Some tools and techniques useful in capturing the project scope are:

  • Define the project need
  • Identify key stakeholders
  • Identify project drivers
  • Develop operational concepts
  • Identify external interfaces

1. Define the Project Need

When scoping the project it very important to define the need for the project. Mistakes are made here because most of us define implementation rather than the need.

Buying a car is an implementation but getting from point A to point B is the need. Implementation can change based on the need but the need should remain unchanged. Over time the implementation can be taking a bus based on various factors such as cost or available resources but the need remains the same (getting from point A to point B)

If the need changes over time, you might not know what is really needed and you cannot build a product to meet a moving target.

2. Identify Key Stakeholders

The PMBOK defines stakeholders as: individuals and organisations who are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or successful project completion.

The aim of inclusiveness makes the identification of stakeholders important; excluding an important stakeholder can undermine the process. No hard or fast rules exist to tell us whom to involve and how. What we do know is that stakeholder involvement is context-specific; what works in one situation may not be appropriate in another.

Stakeholders in a project can include people those who:

  • Buy it
  • Sell it
  • Use it
  • Train others to use it
  • Design it
  • Develop it
  • Test it
  • Market it
  • Maintain it
  • Expect to profit from it

3. Identify Project Drivers

Organisations are driven by many outside influences, e.g., regulations, standards, laws, and other considerations. A major driver for many organisations is the set of existing equipment, software, or processes. Other drivers include security and safety concerns. Depending on your type of business you may be affected by an overabundance of regulations from external organisations.

4. From Needs to Requirements. Develop Operational Concepts

Operational concepts bridge the gap between product scope and formal requirements. The operational concepts are plain-language descriptions of user product/system interactions in the life of your product for both nominal and off-nominal conditions. How will it be used, manufactured, tested, installed, maintained, stored, and decommissioned? Operational concepts may be use cases, operation plans, scenarios, or other methods of uncovering gaps in knowledge and scope.

Many great products start with an intuitive operational concept. High-level operational concepts will help in the creation of the project scope. In the beginning, there may be several alternatives the project could select to meet the project need. In fact, the operational concept may exist before the need statement. Scenarios allow different operational ideas to be explored. Then the feasibility of each scenario is examined and more ideas are explored. A needs statement can be written after the scenarios capture the true need. The operational concept, like all other parts described above, is iterative. A single alternative must be selected and reflected in the project scope to ensure that key stakeholders share the vision before requirement capture begins.

5. Identify External Interfaces

Serious problems arise at interfaces. The project is particularly vulnerable to interfaces with other products over which you have no control.

External interfaces fall into two broad categories:

  • User (usually a human being) and
  • Everything else

User external interfaces include buttons, levers, handles, straps, warning bells, safety labels, and displayed information. Non-user external interfaces include command, data, operating system, computer system, and existing equipment used with your product.

There are several external interface considerations that should be made prior to writing requirements, including the need to interface with a non-standard product, lack of interface documentation, and the risk of changes to products out of your control with which yours must interface. All of this information is vital to the project's risk assessment and change management processes.

There are different classes of interfaces you must consider: First, there are fixed interfaces that are well known and unchangeable. Second, there may be existing interfaces that can be changed, either to save money, or because that interface is being updated. The third type of external interface is one that does not currently exist. In both the second and third cases, negotiation must be completed and agreed to as part of the process.

Conclusion

More than seventy percent of projects fail. When projects fail, it's rarely technical. Over eighty percent of those projects fail due to project management. Projects, like business, often fail because they are not properly managed. Scope creep is a major aspect of project failure. This can be mitigated by following simple procedures such as having a scope document that all the stakeholders agree on and on having a change management plan if there are supposed to be modifications to it. Manage scope and make your project a part of the successful thirty percent.


Avneet Mathur works for Zeratec, Inc. which provides utility computing solutions to individuals and companies, as their Chief Technology Officer managing various projects for the organisation. He is a Certified Project Management Professional, as awarded by the Project Management Institute. Avneet holds an MBA in General Business Administration, with an emphasis in Entrepreneurship and Finance, with an additional Master's Degree in Computer Science and Networking from University of Missouri, Kansas City. He also has a Bachelor's Degree in Computer Science from the Aurangabad University, India. He can be reached at Avneet_mathur@hotmail.com for further questions.


Comments

Be the first to comment on this article.

Add a comment



(never displayed)



 
2000
What is the sum of 1 + 4 + 4?
Notify me of new comments via email.
Remember my form inputs on this computer.

The Risky Business of Project Management

Three red dice reading: Manage your risk

It is important at the beginning of any project to go through the risk identification process. Not all project risks are obvious, so here's how.

The Mythical 50% Resource

Red blocks with the percent sign on a white background

Most managers of software development projects have had an encounter with a resource who is committed to their project some percentage of the time.

How to Get the Most From Your Project Team

Project team in a huddle

Project management is people management. Here's our reminder of how to make sure you get the most from your project team.

A Brief History of SMART Goals

Set your goals written on blue paper

In this history of SMART goals, I look at where the acronym came from, who developed it, what the critics say and why it has become popular.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Deb McCarthy commented on…
The Role of the Project Manager
- Fri 4 October 5:57am

Ed Rushman commented on…
MoSCoW Method
- Mon 30 September 5:11pm

Shawn Robert Vance commented on…
Better Coaching Using the GROW Model
- Sat 28 September 6:41pm

Latest tweets

General Project Management • Re: Building a UK Community https://t.co/v3vt0mYyE7 about 4 days ago

General Project Management • Dissertation Survey - Please help https://t.co/XwtF8pERkX about 14 days ago

MOSCOW Method https://t.co/uctlvoR733 some questions to ask the user and then the users will decide themselves if M, S or C. #projectsmart about 16 days ago