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."

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).

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.

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:

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 15^th century standards. As for Edward, he retained his crown and ruled England for the next twelve years.

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.