Abwehr, the German military intelligence organization has been created in 1921 as a part of the Ministry of Defence. It remained small and consequently not very important part of the Wehrmacht until on January 1st, 1935 it was taken over by the soon to be Admiral Wilhelm Canaris.

In a fairly short period of time Canaris was able to reorganize his agency into one of the most efficient intelligence gathering organizations in the world.  Abwehr's activities spanned through the entire world including United States, Canada, Africa and Europe including England and Russia.

With the opening of the Eastern front Abwehr was tasked with establishing Abwehr schools on the occupied territories of Poland, Baltic states and Western parts of Soviet Union. These organizations were responsible for recruitment, training and deployment of commando-style agents whose primary purpose have been the reconnaissance and sabotage behind enemy lines.

The aforementioned recruits were typically hand-picked by the Abwehr officers among millions of Soviet POWs who were captured in the first several months of the invasion. Some of them were convinced to enlist in the intelligence schools because they could no longer bear the horrible living conditions in the German POW camps, while others did this for ideological reasons, not the least of which was the hatred of Stalin's tyrannical regime in Russia.

After undergoing extensive training that included hand-to-hand combat, target practice, interrogation and intelligence gathering techniques, as well as radio operations to name a few, the graduates were  supplied with absolutely the best documentation provided by  Abwehr's Department 1-G responsible for false documents, photos, inks, passports and chemicals. It is important to note that German technology of producing counterfeit documents was probably the best in the world at the time. After all, they mastered the production of British pounds and US dollars that perplexed the most experienced experts on either side of the Atlantic.

The Burj Al Arab (The Arab Tower) hotel was built in 1999 in Dubai, United Arab Emirates. This project was conceived at the very top of the UAE government as a venture that would assist in transforming the country and the state from the exclusively oil-based economy to the trade and tourism-based market.

The ruling family of Dubai gambled – and by all accounts won – that the conversion into international hub of trade and tourism should start with a “wow-type” project that would demonstrate to the rest of the world that the Gulf country can:

• Undertake ambitious projects and see them to completion
• Has a rich cultural and historic heritage
• Has the supply of and the demand for luxury hotel accommodations

The project that lasted for five years – from 1994 to 1999 – delivered a 321 m (1,053 ft) structure that is now the fourth tallest hotel in the world. Burj Al Arab stands on an artificial island 280 m (920 ft) from Jumeirah beach and is connected to the mainland by a private curving bridge. The shape of the structure is designed to mimic the dhow’s (type of local boat) sail. It is very frequently referred to as the world’s only seven-star hotel; although the company managing it refuses to even acknowledge the fact that they were the ones who started using this epithet.

Burj Al Arab is one of the most photographed buildings in the world and definitely played an integral role in putting both Dubai and the United Arab Emirates on the world map.

The purpose of this case study is to attempt to take this enigmatic and grandiose product and try to reverse engineer the requirement elicitation process from the few high-level business requirements to general features to detailed technical requirements. Let us start with what the business requirements for this project may have looked like (see Table 1):

Table 1

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

The definition of portfolio’s strategic alignment is fairly simple and straightforward: all of your projects must in one form or another assist the implementation of your company’s strategy. A very simple statement that at times is very difficult to explain. In order to do that, let us examine several examples of the project alignment and non-alignment.

At one point of time the executives of Société Bic (commonly referred to just as Bic), a French disposable consumer products company known for their razors, lighters, ballpoint pens and magnets made a very interesting decision. The company decided to enter … the ladies underwear market by designing, producing and selling among other things ladies pantyhose. Needless to say the company failed miserably with this project since the consumers were unable to see any link between Bic’s other products and underwear, because of course there was no link at all.

Although, as the urban saying goes “hindsight is 20/20” let us nevertheless try to assess this initiative from the strategic alignment perspective. Here is a list of potential questions one could direct at the Bic executives who proposed to add this project to the company portfolio:

• We manufacture disposable products made from plastic. What the heck do we know about ladies underwear?
• All of our production facilities are built based on the injection-molded plastic technology? Where will we get the equipment to manufacture underwear?
• People, especially females, perceive us as producers of cheap disposable lighters and pen? Would they be interested in purchasing our lingerie products?
• What about the distribution channels? Retail outlets that trade disposable razors, pens and lighters usually do not sell underwear. Does this mean we will have to acquire a brand new group of retail channels?

It is obvious that none of the answers to the above questions were very encouraging had they been asked at the time of project initiation. Indeed, there was little or no alignment between the proposed endeavor and the overall company strategy.

An interesting conversation clearly demonstrating the value of the portfolio balancing happened once when I was teaching my Project Portfolio Management Masterclass in the Gulf region. Among other attendees there were two high-ranking representatives of one of the largest construction companies: an owner (and a CEO) and his general manager. The following exchange took place between us:

CEO: This portfolio balancing theory is great but I can hardly imagine how it would apply to my business. We are basically very similar to a professional services company. People come to me and say, “Build me this!” What am I going to reply to them? “Sorry, your project does not fit into our portfolio balance model?”

Me: Well, let me finish the module on balancing the portfolios and we will have a chance to chat about this topic at the end.

CEO: (staring at Burj Khalifa visible through our conference room window) Wait a second! I think I get it! I am fairly old and close to retiring in a couple of years. Your presentation made me think; what kind of legacy am I going to pass on to my son, who will take over our business? Right now our entire portfolio consists of very low-risk, low reward projects. We basically build shoebox types of buildings with a very low margin of profit. I would like to have that (points to Burj Khalifa) on our company brochures!

GM: Forget about Burj Khalifa, we have conducted some calculations and if we get into HVAC business, our margins will go up from 5% to 25-30%. And if we somehow manage to get into the energy management business, we can raise our profit margins to 50-75%. Too bad we don’t have any internal expertise at our company.

CEO: Why don’t we hire several specialists in the HVAC and energy management and start a couple of projects from those domains next year? These projects will represent maybe 5% of our total portfolio, but this share will grow with time.

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.

Hi all

I have created a “Downloads” page on my website. You can find a variety of project management, portfolio management and requirements engineering (scope management) templates and sample documents there.

Feel free to browse and download. They are free!

Cheers

Jamal

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East.  Read Jamal’s Blog @ www.thinktankconsulting.ca

• Please follow me on Twitter: 
• Like our page on Facebook: 
• Connect with me on LinkedIn: 
• Subscribe to my RSS feed: 

Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.

Introduction

Our company was commissioned to take over a large portfolio including several regulatory projects ($50,000 to $250,000) and a flagship infrastructure overhaul project ($15,000,000). Also Thinktank Consulting was requested to provide its expertise and assistance in the rollout of the mew project management methodology and the establishment of the Project Management Office (PMO).

Problems

There were several problems associated with the above-mentioned goals. Firstly, the company culture and organizational structure (functional) provided the newly-hired project managers with a very complex environment. Furthermore the new PM methodology developed in the European headquarters needed fine-tuning for the local conditions.

Constraints

Most of the bank's IT portfolio consisted of the regulatory projects mandated by the various North American, European and international governing bodies. One of the main aspects of such projects is that the scope and deadline is fixed by the government leaving little room to “manipulate” the project management triangle. In addition the number and the size of the IT portfolio has grown by approximately 50% compared to the previous year while the technical team has grown by only 10-20%. This factor has obviously increased the pressure on the management team with respect to project resource allocation.

Solution

Thinktank Consulting determined that the only way to deliver the regulatory project on time and with the limited resources was to concentrate on quality Requirements Engineering, Project Prioritization and Project Management. Special attention was dedicated to the involvement of our business counterparts in the requirements gathering and management processes.

Our company has also participated in the deployment and fine-tuning of the new project management methodology. The work, among other things, included enhancing the standard Requirements Document, adding several sections to the Project Plan and collaborative development of the Project Roadmap document.

We have also provided several training sessions in the areas of Negotiations, Estimation and Requirements Engineering.