project scope management

Jamal’s Musings – What is Wrong with Project Scope Management?

An observation of project management practices in various industries confirms that in many instances the scope management in general and scope definition in particular ends to be viewed as exclusive technical areas, which leads to several of very legitimate questions frequently asked by many of my colleagues:

  • "If the project manager is to lead the project should he also lead the product definition stage?"
  • "If scope size and complexity have a direct impact on project timing and budget, shouldn't the project manager be aware - at least a high-level - of how the technical team arrived at the current scope in order to be able to make trade-off decisions?"
  • "Our engineers (designers, developers, architects, etc.) are very good at design, but not very skilled at interacting with customers and extracting the requirements from them. What should we do in this scenario?"

Finally and most importantly, what about enterprise or multidisciplinary projects? With the size and the complexity of projects growing it is not unusual now that the project scope encompasses the entire organization. Let us look at a couple examples from different industries. Note to the reader: these are the two of the five projects we will analyze in detail and create project scope management documentation for throughout this book.

Port Authority - The Container Terminal Construction Project

The first one is the - as it was initially labeled by the senior executives - "construction of the new container terminal" project. The logic at the top of the port authority literally was, "since this is a construction project, there is no need to worry on our end; we will just outsource the construction part to the contractor."

Jamal’s Musings – Requirements Elicitation Is Not Easy - ATM Example

Let us consider an example that is very familiar to practically all the readers who at least once in their lives used and ATM to withdraw money, deposit cheques or pay their bills. Here is a very provocative question, does the reader (especially those not familiar with application development) think that creation of the ATM software is an easy or a very complicated project? Typically the answer - just as in the case with the airport check-in kiosk - is that this project shouldn't be too complicated. One inserts his card into the slot, enters his PIN and gets the money. These are seemingly simple tasks that we have done numerous times, but let us examine them step by step (see Table).

 

Identify yourself

  • Is it one card per account or can the user have several accounts linked to one card?
    • If yes, then who will create and administer this mechanism?
  • What happens if the PIN entered is incorrect?
    • How many incorrect tries do we grant per user?
    • What happens if the user takes back the card after two attempts and then reinserts the card again? Do the first two wrong tries still count?
    • If the user exceeds maximum allowed number of wrong attempts, do we take his card away or just prevent him from using the machine again?

Options for the user

Jamal’s Musings – Dangerous Words To Avoid in Project Documentation

Dangerous Words

What To Do About Them?

Examples

“Acceptable”, “adequate”, "satisfactory", "suitable"

Define acceptability and how the product and stakeholders can decide what is acceptable and what is not

 

Before: House of adequate size

After: House area shall be between 2,500 and 3,000 square feet

“Efficient”, "capable", "economical", "ecologically aware", "helpful"

Explain how efficiently the product performs operations or how easy it is to use

 

Before: Efficient engine

After: Engine with a mileage of at least 100 km per liter

“Fast”, “rapid”, "swift", "speedy"

Specify minimum, maximum and desired speed

Before: Fast car

After: A car that is capable of speed of at least 350 km/hour

“Flexible”, "agile", "easily adaptable", "variable"

What specifically should the product do in response to specific changes in the environment or business objectives

Jamal’s Musings - Criteria For Good Requirements

Once all of the requirements have been gathered, it is time for the analyst to write the requirements specifications document. Let us discuss the best practices that are applicable to all types of the documentation (see Table).

Each requirement listed in the document must be necessary. While it may sound somewhat silly to question the necessity of scope components since the stakeholders asked for them specifically in the first place, industry studies show that as much as 50% of requirements can be cut from the scope of the project by asking a simple question like, “Do you really need this feature?” or, “Would a project be a ‘no go’ without this component?”

The necessity of the requirement can also be checked in the following fashion: if one can trace the requirement back to the parent business problem via the parent feature and the relationship is still logical, then the requirement is most likely indispensable.

Each requirement must be verifiable, which implies that the requirement can be tested. This criterion is strongly related to the ambiguity that will be discussed a bit later in this chapter. In general, if the requirement is not measurable, it is very unlikely that it would be verifiable. For example, requirements like:

  • “The building shall be sustainable”
  • “The system shall be efficient”
  • “The light bulb shall save energy’

are not verifiable since different people can – and most likely will have a different understanding what “sustainable”, “efficient” and “save energy” mean. On the other hand, statements like:

  • “The building shall generate 50% of the energy it needs”
  • “The system shall decrease the account opening process from 27 to 4 operations”
  • “The light bulb shall have a luminous efficacy of at least 55 lumens per watt (lm/W)

are completely verifiable because it is very easy to test whether they conform to the requirements imposed on them by the stakeholders.

 

Criteria For Good Requirements

Criteria

Explanation

Training - Project Scope Management: A Practical Guide to Requirements Elicitation, Analysis, Documentation, Validation and Management For All Types of Projects

Course Overview

Business requirements elicitation (i.e. the initial phase of product scope definition) is underdeveloped in today’s project management science with the exception of IT and software development sectors, where scope definition (aka business analysis) is although relatively advanced, but excluded from the project manager’s domain of responsibilities.

As a result, most industries have a very prominent knowledge gap in project scope planning. A gap that starts some time after the Project Charter has been completed and approved and ends somewhere around the point when the work commences based on the detailed blueprints, technical drawings and bills of materials.

And yet, scope definition remains the key ingredient in the success of any project. After all, as one of my clients used to say, “If one does not understand completely what he or she is going to build, what is the point of engaging in scheduling or budgeting?”

This workshop is dedicated to the requirements elicitation, analysis, documentation and planning on the engineering, product, IT, software development and enterprise projects.

Why You Should Attend?

Recent studies indicate that only 32% of our projects can be considered successful, while 44% are challenged (i.e. grossly over the budget and/or late) and 24% are outright failures (i.e. cancelled by the customers before they are even completed). Further research shows that the lion’s share of this lack of success can be attributed to poor requirements elicitation, insufficient planning and inadequate project control.

This course will demonstrate to the participants how to perform these tasks properly and efficiently by teaching them skills, tools, techniques and economic principles that transcend various company structures, environments and project management philosophies.

Benefits of the Course

Every course participant is expected to understand how to improve the quality of the products delivered on their projects, decrease project durations and budgets and improve both internal and external stakeholder satisfaction levels by learning the following techniques:

Article - Defining the Detailed Scope: How and Where Do You Find Requirements?

Roses, Stars and the Sun

Medieval England. War of the Roses. On April 13th, 1471 Yorkist troops, under the command of the king, Edward IV, and Lancastrian forces led by Richard Neville, 16th Earl of Warwick and John de Vere, 13th Earl of Oxford met near the town of Barnet some twelve miles North of London. At four o'clock in the morning on April 14th the soldiers of both armies were awakened and started preparing for the decisive battle. Warwick's army heavily outnumbered Edward's, although sources differ on exact numbers. However, according to some historians, Lancastrian strength ranged from 10,000 to 30,000 men, with 7,000 to 15,000 on the Yorkist side.

The major problem that both armies had to deal with was a heavy fog that covered the entire battlefield thus making any kind of monitoring or communications with their units somewhat problematic.

Medieval battles have never been known for their orderliness and organization; however because of the heavy fog, the confusion that existed on the field on that particular day dwarfed anything that was seen in military campaigns before and since that memorable day. In this mayhem at one point of time John de Vere's forces ended up behind their allies, a part of Lancastrian force led by Warwick's younger brother John Neville. Neville's regiments for reasons to be explained a bit later mistook their comrades-in-arms for enemies - Edward's reserve forces - and unleashed a volley of arrows on them. De Vere, in his turn quite logically assumed treachery and attacked Neville's troops ... The cries of treason quickly spread throughout the entire battlefield and as the fog started to dissipate, Edward saw the Lancastrian centre in disarray and sent in his reserves, hastening its collapse. One by one, first John Neville, then de Vere and finally Warwick were killed by Yorkists.

Some historians claim that as many as 6,500 Lancastrians perished in that engagement - a mind-boggling number of casualties by the 15th century standards. As for Edward, he retained his crown and ruled England for the next twelve years.

Article - Kick-Starting Your Projects; What You Should Know about Defining Scope

M 247 "Sergeant York" story

In late seventies the US Department of Defense (DOD) outsourced the development of the self-propelled anti-aircraft (AA) weapon which featured twin radar-directed 40 mm rapid-fire guns to Ford Aerospace. The project was assigned the name of ”Sergeant York”, after the World War I US army hero, who undoubtedly would not have appreciated this dubious honor had he been alive in 1979. The weapon was intended to replace the M163 Vulcan Air Defense System and fight alongside the M1 Abrams and M2 Bradley fighting vehicles in the U.S. Army, and was similar in concept to successful Soviet and European systems such as the ZSU-23-4 and Gepard

 

In essence it was an air defense weapon mounted on the surplus M48 Patton tank chassis, provided by the Army, which were held in large quantities in their depots. The main job of the weapon was to sit on the front lines and automatically target and shoot down enemy aircraft, especially helicopters. As a result it was designed to hone in on metal parts rotating in the air (i.e. propeller blades).

The final test of the AA gun involved a demonstration involving a prototype weapon shooting down a hovering helicopter on one of the US DOD proving grounds somewhere in the desert in the southern part of the United States. The cost of the project at that time was approximately US $1 billion.

According to the legend cultivated in the aerospace and defense industries there was a portable toilet installed not far away from the testing grounds. Because of the hot climate, the toilet cabin had a small electric fan in it …

You probably managed to guess the rest – the billion dollar piece of equipment “decided” to ignore the much larger target – the helicopter – and targeted the unique signature of the “port-a-potty’s” electric fan!

Further tests revealed that the AA gun had the following deficiencies:

  • The radar could not track low flying targets due to excessive ground clutter
  • The radar could not distinguish a hovering helicopter from a clump of trees
  • Turret traverse was too slow to track a fast crossing target
  • The radar can be jammed very easily

As a result, the project that began in 1975 was finally cancelled by then Secretary of Defense Caspar Weinberger in 1985.