Requirements

Project and Portfolio Management Experts

Jamal Moustafaev.jpg

@ThinktankConsul on Twitter Thinktank Consulting on Facebook Thinktank Consulting on Google+ Thinktank Consulting on Linkedin Thinktank Consulting RSS Feed Thinktank Consulting on YouTube sudemylogo.jpg

Jamal is the author of three books and many online courses dedicated to project, portfolio, and scope management:

Phone: +1 778 995 4396

E-Mail: jamal@thinktankconsulting.ca

Below you will find ten symptoms of a company that is in dire need of project management and/or project portfolio management. Read through the list and count how many of these characteristics can be attributed to your organization:

  1. Unexpected issues and problems arise in the middle of projects
  2. Communications seem to be ad-hoc; too often important stakeholders are not informed about key decisions
  3. Project's requirements are never clearly defined
  4. Project managers and functional managers (department directors and managers) constantly fight over resources.
  5. Priorities of the projects initiated by the executives constantly change, resulting in quick resource reassignments.
  6. There is a chronic shortage of resources at the organization. Employees are constantly complaining about being overworked, while the managers insist that they must roll up their sleeves and work harder
  7. Projects are frequently late and/or over budget and/or do not deliver the full scope promised and the quality of the project product is low
  8. Even if the strategic idea is implemented, the company sometimes fails to achieve the expected improvement or fails to receive any value from the said project at all
  9. The strategic plan – even if the company has one - is presented as a list of projects, but the cause-effect logic tying those initiatives to the company’s mission, goals and the strategy is absent
  10. The list of company projects is not prioritized. Therefore it is assumed that all of these initiatives must be started and implemented more or less simultaneously

Did you count more than three symptoms present at your company? We can help! We offer project management, project portfolio management consulting and both live or online training services to help get your business back on track.

Please contact me directly via email at jamal@thinktankconsulting.ca or by phone +1-778-995-4396.

I look forward to hearing from you.

Jamal Moustafaev, MBA, PMP

President & CEO

Thinktank Consulting, Inc.

project-portfolio-management-book.jpg

Article – How to Categorize IT and Software Development Requirements

 

learning-platform_0.jpg

 

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.

IT-SD-Reqs.JPG

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”

 

Joke of the Day – When Requirements Elicitation Fails

 

This is the best example of a failed requirements elicitation I have seen so far!

 

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

Jamal is an author of three very popular books: 

  1. Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management 
  2. Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects
  3. Project Portfolio Management in Theory and Practice: Thirty Case Studies from around the World

Case Study - Kashagan Oil Field - A Fiasco That is 11 Years Late and $100 Billion Over Budget

Introduction

The Kashagan Oil Field has been discovered in 2000 in the Northern part of the Caspian Sea (see Figure 1). It was quickly confirmed that it was the world's largest discovery in the last 30 years, combined with the Tengiz Field located nearby, with a projected output close to that of the Ghawar field in Saudi Arabia. The recoverable oil reserves of the Kashagan Filed were estimated to be at 19-20 billion barrels.

Figure 1

Caspianseamap.png

The consortium consisting of several global energy players along with the government of Kazakhstan was formed in order to develop the reserves. The number of players and the make-up of the conglomerate changed several times over project lifecycle (we will come back to this fact at a later time), but as of 2012 the group consisted of the following players:

  • Eni (Italy) - 16.81% stake
  • KazMunayGas  (Kazakhstan) - 16.81% stake
  • Royal Dutch Shell (UK/Netherlands) - 16.81% stake
  • Total S.A. (France) - 16.81% stake
  • ExxonMobil (USA) - 16.81% stake
  • China National Petroleum Corporation (China) - 8.4%
  • Inpex (Japan) - 7.56% stake

The Project

The project started in 2001 with an expected completion date of 2005. The allocated budget for this venture was US$10 billion. The oilfield was expected to become operational around 2005 and produce anywhere between 90,000 and 370,000 barrels (at peak production) a day. Needless to say, this project was viewed in Kazakhstan as one of the most important initiatives for the young country and was expected to generate considerable income for the government.

However the project fell 8 years behind the schedule and ended up costing a bit more than the original forecast. Depending on who one chooses to believe, the cost of the venture as of 2015 was either US$50 billion (official number provided by the government of Kazakhstan), US$115 billion (CNN Money's estimate) , or close to US$150 billion (number being mentioned in some publications).

Article - Top 5 Strategies to Protect Your Project from an Evil Vendor

 

Several posts ago I published an article titled "Top 6 Ways Your Vendor Can Screw You On Your Next Project". Today I wanted to follow up on this topic with a list of strategies geared to help a company deal with the tricks and ploys of irresponsible vendors. All of these methodologies have proven themselves in my project management consulting practice, especially on the troubled project recovery assignments.

Strategy #1: Pay More Attention to Your RFP

Spend more time and effort writing your Request For Proposal. The more complicated the project is, the more precise and detailed should your request for proposal be. In which of the cases below do you think the contractor would have less "wiggle room"?

Jamal's Musings - How One Simple Question Can Cut the Project Budget from 500K to 2K

Today I wanted to share a very interesting story that, in my opinion, demonstrates the importance of asking questions while working on the projects. This example comes from my personal experience while working at an IT department of a very large international financial institution.

My boss: “Risk Management is having problems with their desktop statistical analysis software. They are asking for an Enterprise Edition of the software and a dedicated server. Our initial ballpark estimates for this project are at $500,000 and we have neither the money in our budget, nor the resources to accomplish that. You mission is to explain to them that they are not getting this stuff in the next couple of years!”

Me (going over to the Risk Management Department): “What is the problem?”

Risk Management people: “We have to store files on the shared server because of the privacy laws and access them through our desktops. Processing times are very slow. We have to upgrade to the Enterprise Server Edition and get a new server”

Me (calling Network and Infrastructure people): “But why is the processing slow? Is it the network issue or the overloaded server?”

Network people: “We checked the network and it does not appear to be overloaded”

Infrastructure people: “Are you kidding me?! The entire building is using this server. Of course it is overloaded and slow”

Me: “So, what can we do?”

Infrastructure people: “We will give them a dedicated NT server; we have one lying around here somewhere …"

Result: The $500,000 project was diminished to a $2,000 server and 3 man-days of work-problem solved.

Article - 7 Tips for Successful High-Level Requirements Elicitation

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

Article - 3 Real-Life Examples of Critical Thinking When Eliciting Requirements

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 

"Project Scope Management" book is now available on Kindle!

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

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