requirements engineering

Article - The Project Management Perspective: Why Do Technology Startups Really Fail?


If one googles this question, he will find the following reasons at the top of the list:

  1. Market Problems
  2. Business Model Failure
  3. Poor Management Team
  4. Running out of Cash
  5. Product Problems

I have to agree that these root causes could be attributed to the early-stage startups, but in this article I want to talk about the scenarios where venture capital companies have already examined the company and its product(s), checked for points (1), (2), (3) and (4) and still chose to finance these enterprises. Since VCs are the most experienced organizations out there in the startup assessment business, we have to assume the best vetting process possible.

My Experiences

I have worked with a lot of tech startups around the world over the course of last twenty years. All of these companies have been in the “post VC financing” stages and here are the somber facts:

  • The vast majority of them failed (roughly 9 out of 10 which aligns with scientific data)
  • In almost all of the cases the product, business model and cash situations were in a reasonably good shape

So, what happened?

Company grew getting more and more customers. Customers were getting bigger in size. Contracts they signed were getting larger and larger. Companies were becoming more and more profitable. And at one point of time (usually when the said organizations reached approximately US$10 million in revenues threshold) the company just couldn’t handle one of the two (and frequently both) things:

  • Product development that was sophisticated enough to handle the demands of the markets
  • Professional services: ability to deploy their software/hardware at the client’s site

Reason? Complete disregard to all aspects of project management and requirements engineering

And no matter how many times you would tell the C-level people  

“Guys, roll up your sleeves and work harder approach does not work any more! You need to invest in project managers, business analysts and proper project management methodologies”

no one was willing to listen.

Case Study - What Went Wrong with the Most Expensive Warship?


The project to deliver the most expensive warship in the world is $2.3 billion over the budget and 2 years (and counting) late. The US Navy’s newest $13 billion aircraft carrier is still not ready for combat because of mechanical delays that have already put it two years behind schedule, according to the Pentagon’s top weapons tester.

The USS Gerald R. Ford (see Figure 1 for more info) was supposed to be ready by September 2016, but Michael Gilmore, the Defense Department’s director of operational test and evaluation, said in a June 28 memo that the warship had ongoing launch and recovery problems.

Figure 1

USS Gerald Ford_0.PNG

The construction of the ship started in November 13, 2009 and is still ongoing. Click on the video below to watch the time lapse.

Video - USS Gerald Ford Construction Timelapse


The Problems

Table 1


The Root Causes

Let us try to analyze the root causes first.

"Unrealistic business cases, poor cost estimates, new systems rushed to production, concurrent design and construction, and problems testing systems to demonstrate promised capability"

Chairman of the Senate Armed Services Committee Senator John McCain

However the some officials indicated that missed deadline can be attributed to the decisions made when the Pentagon committed to building the advanced ship in 2008.

"The decision to proceed with these three systems was made many years ago, prior to their maturation, when transformational approaches to acquisition were a DOD policy,"

Mark Wright, a Defense Department spokesman.

Let us try to make some sense out of the information presented above:

Article - How to Prioritize Project Features and Explain the Process to the Stakeholders


When the Requirements Specifications is complete, the project manager (or the business analyst) must inspect the document with all the stakeholders in order to (along with other very important things) prioritize all of the project features and/or requirements.

Project features have to be prioritized for the following reasons:

  • Prioritization eliminates unnecessary, frivolous scope items added to the project scope
  • It decreases the project scope thus potentially saving time, money and resources
  • It allows you to focus is on the truly important items

However, the prioritization exercise could become a very painful process, especially when the project manager is working with the stakeholders who are not very familiar with the core principles of project management. As a result they frequently tend to counter every prioritization request with phrases like:

Everything in this document is equally important!

Statements like “this is a low-priority feature” are not culturally accepted at our company

We have a “yes, we can” attitude at this firm!

And my favorite:

Well, you ARE a professional project manager. Can’t you deliver all of these items on a tiny budget and a ridiculously aggressive timeline?

To address this problem I usually start my prioritization exercises by showing the stakeholders the following table (see Table 1):

Table 1


Usually the dialogue goes something like this:

Me: OK, now to the “Rear-view Camera” feature … How important is it?

Stakeholder: Very important! Definitely a “Must-Have” item!

Me: But if we throw it out, does it mean we have to abandon the entire project?

Stakeholder: No, not really … How about be assign it a “Should Have” status then?

Me: Is it of same importance as the “Passenger Seat” feature? In other words, if it came to deciding whether to cut the “Passenger Seat” feature or the “Rear-view Camera” feature, would you think for too long?

Stakeholder (with an audible groan): OK then, let’s go with “Nice-to-Have”

Jamal's Musings – The Role of Psychology in Project Scope Management


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.


News - "Project Scope Management" book (with free Google Preview) is now available at the CRC Press website!

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:

Project Scope Management book

Jamal's Musings - The Story of One Word That Destroyed A Project


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?

Jamal's Musings – Who Is A Requirements Analyst?

So, who is the requirements analyst? He has to perform several roles at once. He has to be a translator, since he is responsible for capturing the requirements expressed in the language of the user or customer (typically a non-technical language) and translating it to the language understood by the technical project resources.


For example:


"The car must be really fast"


 converts to:


"The car shall be able to travel at a speed of up to 100 mph"


She has to be a keen observer, since she has to observe the work performed by the user from the user's rather than from the technical resource's perspective.


The requirements analyst has to be an interpreter of the work to be performed; in other words he should be able to reveal the essence of work, not its incarnation.


For example:


"The bottle opener must be rectangular in shape"


converts to:


"The bottle opener shall be able to open bottles with both round and rectangular necks"


Very frequently the requirements analyst is someone who invents better ways of performing the work described by the user.


For example:


“The dryer should have different drying cycles to accommodate for different types of loads”


converts to:


“The dryer shall have three different drying cycles (small, medium and large)”


“The dryer shall have a dryness sensor that will shut the device down once the laundry is completely dry”


Requirements analyst is also a scribe who should be able to record the results of her analysis in the form of stakeholder-understandable requirements specifications and analysis models that are necessary, verifiable, attainable, unambiguous, complete, consistent, traceable, concise and prioritized.


For example:


Jamal's Musings - Project Management in History: The University Construction

A government of one of the countries in the Gulf region decided to embark on a project of building a multi-campus university in several - at times remote - locations. It was decreed that the said project should take five years to implement and the cost should be around US$200 million. It is not completely clear even after talking to several people actually involved in the endeavour right from the very beginning whether these constraints were just "dropped" from the very top of the government levels or if these were at least a very high-level estimates generated by a qualified party.

The scope of the project, at least at a very high level, was also thought to be well-understood. It included the following requirements:

  • Engineering design of all five campuses (both conceptual and final)
  • Construction of classrooms and lab training facilities
  • Construction of dormitories
  • Procurement and installation of all necessary equipment
  • Setup of a new IT infrastructure including several data centers
  • Design, development and delivery for over100 new courses,
  • Setup and customization for a web e-learning portal

The primary contractor has decided to proceed with five different vendors to be responsible for different parts of the scope of the project. As a result, each vendor was requested to provide his version of the solution with respect to their vertical area of expertise. The primary contractor decided to simply aggregate individual scopes provided by the vendors into one united program scope. Consequently no thought was given to the proper integration between different scopes.

Finally, it turned out that the original RFP issued by the customer neglected to mention that the university will be constructed in an open desert with no water, electricity, sewage or roads. And since the primary contractor neglected to verify the existence (or absence, to be more precise) of all these ingredients, the budget and duration for the project mentioned in the original contract were, to say the least, inadequate.

Article: How To Define Scope on Software Development Projects: Functional and Non-Functional Requirements

The Story Of A2LL

A2LL – the German social services and unemployment software system was developed over the course of several years by T-Systems - a software department of state telecommunications company – along with ProSoz, a smaller company of about thirty developers located in the town of Herten.

The final product was delivered in the last quarter of 2004 and went live on January 1, 2005. The system consisted of the web browser front end, while the back end was based on 16 servers with 4 processors each.

Upon the deployment of the system at several large German cities including Cologne, Hamburg, Frankfurt and Berlin, the users at the welfare offices started reporting serious problems with the software.  Some of the problems encountered are listed in Exhibit 1.


Exhibit 1

System Bug Description

Type of Requirement

If data entered into the form was incomplete (e.g. someone missed one of the many questions) the system automatically deleted the record after about three or four weeks


Account numbers that were less than ten digits in length were filled with zeros at the end of the string rather than at the beginning (e.g. 3225223 became 3225223000 instead of 0003225223).



System was not capable of producing an “Analysis of Variance” report


System was not capable of producing a “Persons Who Received Too Much Money” report


System did not include the functionality to deal with the deductions for income from small jobs


News - “Project Scope Management” book to be released in the Fall of 2014

Just spoke to my publisher at the CRC Press. It looks like my new book “Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects” will be released in October of 2014.

The book page can be accessed here.

I will keep your posted regarding the updates.

P.S. The cover picture you see in this release has not been approved yet. Hopefully very soon I will obtain several cover versions produced by my publisher and we can vote on the best option. Looking forward to your feedback!