project scope management

I frequently employ an exercise when teaching my courses; I ask the audience members to think for one moment of their idea of a "dream home". I ask them whether they thought about this before and the majority of them agree that yes, indeed over the course of their lives they have given this topic a lot of thought and can envision this building pretty well.

Then I tell them that they now have to sit down with me - and I am willing to invest as much time as needed - and describe the house to me in detail, down to the type of flooring in the kitchen and living room, colour of the walls in the master bedroom including the exact shade, specific type and model of faucets in the bathrooms, molding in the dining room area, etc., etc., etc. The goal of this exercise is that at the end of it I should have a detailed blueprint of the building and the bill of materials including product SKUs I can go to, say, Home Depot with and purchase all the necessary supplies.

After a couple of minutes someone in the room exclaims,

“But that is impossible! How can you expect us to know all the little details about the house?”

Why am I telling this story? The reason is that thinking that one can easily come up with a complete list of detailed requirements at the beginning of the project is a self-deception. Requirements elicitation is a long and at times painful process of probing, asking questions analyzing the preliminary results, coming up with more questions and investigating again.

Furthermore, once the technical experts sit down to have any kind of requirements elicitation interaction with customers or users, they (the users) do not necessarily provide the analysts with a structured model of requirements that follows a predefined taxonomy. In other words, the customers rarely start these conversations by saying, “I will cover all of the high-level business requirements first, followed by product features. And at the very end I will provide you with all the functions and attributes of the product".

The requirements management domain is by far the most advanced in the technology field where the requirements are (see Figure 1) traditionally broken into:

• Business Requirements (or problems, or objectives)
• Features (epics in the Agile world) and
• Functional and Non-Functional Requirements (user stories in Agile)

Requirements analysts in the IT and software development fields also have tools like use cases, constraints, business rules and data definitions to better define the detailed level requirements.

Here is an example of such hierarchy. Let us assume that a small business producer of, say, scented candles decided at one point that she wants to sell them online. What is the resulting Business Requirement?

• BR 1.0 “We need to sell our products online”

Features that naturally flow from it include but are not limited to:

• F 1.1 "Customer Login"
• F 1.2 “Product Catalog”
• F 1.3 “Search Function”
• F 1.4 “Shopping Basket”
• F 1.5 etc.

The features are later broken into functional and non-functional requirements. For example Feature 1.4 (Shopping Basket) can be broken into the following functional and non-functional requirements:

• FR 1.4.x “The user shall be able to add products to the shopping basket”
• NFR 1.4.x “The process of adding a product to the shopping basket shall not exceed 1 sec”

Hi all,

I have had a chance to chat with Cornelius Fichtner of Project Management Podcast. We were discussing my new book "Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects" and in the course of the interview I was asked to answer the following questions:

1. What is project scope management?
2. What is the state of project scope management nowadays?
3. Why did you decide to write a book about it?
4. What makes this book unique?
5. Who is this book for?
6. What are the main processes in the project scope management?
7. What is the state of project scope management in the IT and software development industries?
8. What is the state of project scope management in construction, product development, engineering?
9. What is your perspective on project scope management in multidisciplinary or enterprise projects?
10. How does project management play into this?

The interview has already been downloaded more than 27,000 times from the PM Podcast website.. Hope you enjoy it as well.

About the Author

“If you don’t know where you are going,

you’ll probably end upsome place else.”

Yogi Berra

Tip #1: Understand the Importance of Requirements

Five out of the top eight reasons why projects fail are related to scope definition, according to the Standish Group. These include:

• Incomplete requirements
• Lack of user involvement
• Unrealistic customer expectations
• Changing requirements and specifications
• Customers no longer needing the features provided

Further analysis of causes of “bad” requirements yielded the following results (see Table 1).

Table 1

 A study conducted by Barry Boehm (one of the leading thinkers in the field of software development) involved an analysis of 63 software development projects in companies such as  IBM, GTE and TRW and determined the relative costs of fixing an error at various stages of the project.  Results from the study, demonstrate a phenomenal increase in the cost of a mistake from one dollar at the Initiation stage of the project to $40-$1,000 range at the Closeout (see Figure 1).

Figure 1

 While this information is based on the software development industry, this trend, to a certain extent, holds true for most other industries.

The scope problem is not rooted in our inability to come up with detailed blueprints, bills of materials or design and architecture documents. The predicament lies in the initial stages of the projects, when we need to elicit a high-level initial set of customer problems, issues and needs, and propose potential solutions.

Another absolutely crucial aspect of requirements elicitation that, in the author's opinion, requires a complete overhaul of one's brain. The problem here lies in the fact that sentences and expressions that would appear to be absolutely normal and acceptable by regular people, must be met with a due portion of skepticism and questioning by the project managers.

I always joke with my project management training attendees that by the end of the first day they will all be turned from "homo sapiens" into the "homo projectus" because they will undergo a psychological breakthrough and develop certain allergies in the course of the class that will be considered abnormal by the rest of their coworkers and family members. Let us look at some examples.

Unspecified Information - Does the phrase "we get sales reports" seem like a normal and acceptable thing to say? After all we do hear it all the time when we chat with executives, sales, marketing and business development people all the time.

Imagine now that you are in charge of developing a system that will among other things provide the business development department with sales reports.  A "normal" person upon hearing the phrase "we get sales reports" will probably just nod his or her head, write down something along the lines of "provide sales reports to the business development team" in her notebook and move on to the next questions.

"Home projectus" on the other hand will (and should) explode with the following questions upon hearing that statement (see Table 1).

Table 1 - Unspecified Information

We ask these questions because we need to know:

• Who specifically will be getting these reports
• How and in what format will these reports be transferred to the readers
• What constitutes a sales report and how many types of reports exist

The readers of this article are encouraged to examine Tables 2 and 3 for some further examples - by the way all taken out of real project management documents - of unspecified comparisons and generalizations.

Table 2 - Unspecified Comparison 

Hi all,

I have had a chance to chat with Cornelius Fichtner of Project Management Podcast. We were discussing my new book "Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects" and in the course of the interview I was asked to answer the following questions:

1. What is project scope management?
2. What is the state of project scope management nowadays?
3. Why did you decide to write a book about it?
4. What makes this book unique?
5. Who is this book for?
6. What are the main processes in the project scope management?
7. What is the state of project scope management in the IT and software development industries?
8. What is the state of project scope management in construction, product development, engineering?
9. What is your perspective on project scope management in multidisciplinary or enterprise projects?
10. How does project management play into this?

I have already received some very positive feedback regarding the interview. Hope you enjoy it as well.

About the Author

Hi all,

Just wanted to let you know that my new book "Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects" is now available on Kindle (click here to preview the book and read the editorial and customer reviews).

Here is what one of the co-authors of the first PMBOK had to say about it:

"The book unites the best practices of scope management from the fields of traditional project management, information technology, software development, engineering, product development, architecture, construction, and multidisciplinary projects. It is based on the most advanced and popular works by prominent authors and contains the latest advances in project scope management. It also concentrates on the hands-on practicality of tools and techniques rather than focusing on their academic prominence. Best of all, Jamal’s book is easy to read and uses informal, nonacademic language to explain all the key points."

—R. Max Wideman, P. Eng., FCSCE, FEIC, FICE, FPMI

The book also already has three very positive reviews on Amazon!

Cheers,

Jamal Moustafaev, MBA, PMP

Another field that is utilizing the latest developments in psychology is - surprising to many people - e-commerce. We all shop on the Internet for books, clothing, tools and electronics but very rarely do we realize how the site designers manage to manipulate and direct us using subtle but very powerful psychological tricks. Here are some of them:

• "Buy" and "Add To Cart" buttons - ever noticed how large and colorful they are? Do you really think it is just a design quirk of the user interface specialist? And yet it has been proven that color, size and even irregular shape have a proven, measurable impact on products added to cart, checkout initiation and checkout completion.

• Free Shipping vs. Savings - do you think that $10 in money saved is always better than $6.99? The conventional answer to that question is "yes", but a professor from Wharton School of Business found that consumers preferred free shipping worth $6.99 in savings over a $10 discount on the product. And smart e-commerce retailers take full advantage of this irrational behavior.

• Lump Sum vs. Distributed Payments - by the same token, when offered to buy a warranty for additional $15, most of the customers declined that offer. But guess what they did when they were offered to pay $2 per month for the next 12 months for the same warranty?

• Usage of "Will" - the e-commerce psychologists argue that the following statement "Shampoo X will calm itching and will reduce redness" is much inferior to "Shampoo X calms itching and reduces redness". Some peculiar processes in our brains forces us to believe the second type of statement way more than the first one.

As was mentioned earlier, this technique could probably be quite useful in software and product development, although it is possible to employ it on certain multidisciplinary projects as well.

My second book "Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects" is now available on the CRC Press website!

Incomplete or missed requirements, omissions, ambiguous product features, lack of user involvement, unrealistic customer expectations, and the proverbial scope creep can result in cost overruns, missed deadlines, poor product quality, and can very well ruin a project. Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects describes how to elicit, document, and manage requirements to control project scope creep. It also explains how to manage project stakeholders to minimize the risk of an ever-growing list of user requirements. Read more

Read the first several dozen pages of the book for free via Google Books Preview 

Here is what Max Wideman, one of the first project management gurus had to say about my second creation:

The book unites the best practices of scope management from the fields of traditional project management, information technology, software development, engineering, product development, architecture, construction, and multidisciplinary projects. It is based on the most advanced and popular works by prominent authors and contains the latest advances in project scope management. It also concentrates on the hands-on practicality of tools and techniques rather than focusing on their academic prominence. Best of all, Jamal’s book is easy to read and uses informal, nonacademic language to explain all the key points.

—R. Max Wideman, P. Eng., FCSCE, FEIC, FICE, FPMI

And finally, the full table of contents for you perusal:

I remember one instance when I was teaching my “Project Management Masterclass” for the executive team of a North American port authority. The purpose of this class was to introduce this group of people to the core fundamentals of the project management science and convince them to seriously consider implementing this methodology at their organization.

This workshop has been highlighted by many interesting discussions and even heated arguments about the domain of project management, the value of planning and the role of the project manager. However the most interesting – at least in my humble opinion – exchange took place when I started describing the “dos” and “don’ts” of requirements gathering and analysis:

Me: When documenting requirements the project manager should always make sure that words like “fast”, “acceptable”, “efficient”, “flexible”, etc. do not appear in project management documentation.

COO: And why not?

Me: Well, you see, although these words are perfectly acceptable in “normal life”, they are considered to be ambiguous in the domain of project management …

COO: And?

Me: OK, let me share a very simple example with you. For instance, if the requirement states, “The car shall be fast”, it can later be misunderstood by the project stakeholders. Some of them will think 100 km/hour is fast enough, while others will insist on a speed of 300 km/hour. And yet, another group will ask for a speed of 500 km/hour. This will most likely create an unnecessary confusion and lead to conflict in the middle of the execution stage of the project.

COO: But we always use these words in our documents!

CEO: (interrupting the COO) Do you, guys, remember what happened on our recent “New Cruise Ship Terminal” project? We claimed in the project charter that we would build a state-of-the art facility and let that word slip into all other documents …

Me: And what happened?