Why Projects Fail
Introduction
There are three primary categories of project failure or delay. The first objective of turning around a failing/delayed project is to identify causes. Once causes are understood potential remedies can be planned and implemented. Below is an outline of typical causes and/or symptoms of failure or delay.
Technical Development
There are many reasons for failure/delay in technical development whether hardware, software or service products.
a. Has the value proposition been identified?
i. You can’t design a product or process without a firm definition of what marketing has determined as the customer need and how the organization will satisfy this need. Fundamental.
b. Has product usage been identified? Sounds obvious but can be difficult in specialized niches or a new use for an existing product.
c. Poor customer definition.
i. Who’s the customer/user…the nurse, doctor, patient, purchasing, housekeeping, or other?
Hint 1: Everyone from the purchasing agent to housekeeping (disposal) is a customer/user. Does it meet their needs? If a hospital incinerates its trash can the materials be burned?
Anyone and everyone who touches or has to experience the product is a customer/user. And yes, unit and shipping packaging is part of the product. I’ve witnessed a medical disposable product launch get off to a very slow start because of product presentation (the method used to package). Current products on the market were presented on rolls for use where multiple units could be hung on an IV pole by the bedside for nurse’s use and convenience. This new product delivered individual units in a box. The box had to have a home in a drawer or on a shelf which was not always bedside. The product itself was a winner but acceptance slow due to expediency. BTW, the company made a change to rolls. This took several months with changes to parts, tooling, sterilization validations, and production.
Hint 2: Make a value stream process map on one axis showing the who, what, and where of the potential product flow from mfg. to hospital (vs. home vs. outpatient center vs. ?) through to disposal (trash vs. incinerator). On the other axis show/describe customer/user process flow for each user and location from diagnosis to therapy or want/need to supply. The axis should cross where customer/user meets product/service.
ii. Has the customer/user been formally defined?
Even if one of the users is the Doctor, has the type of Doctor been identified? The needs of an OB/GYN vs. a General Practice vs. a Nurse Practitioner are all different. Where are they located? Answers to these questions drive product requirements.
d. What is the product?
Is it hardware, software, service, combination, other?
e. Poor product definition
i. Without a. above being defined this cannot be done.
ii. Does marketing keep changing their mind as to features/benefits?
f. Poor product/customer requirements definition.
Need to answer who, what, and where in order to identify requirements.
g. Poor Engineering Requirements (ER) definition.
i. ERs must first be translated from product/customer requirements to ERs.
ii. ERs must be defined in a manner that can be measured or verified (NOT-Is this red enough?).
iii. Can you prove the product meets the requirements via facts (objective) as opposed to opinion (subjective)?
1. “Easy to carry” is not measurable and is a matter of opinion.
2. Product must weigh less than 10 lbs. is measurable and is a fact.
h. R&D not focusing on developing one ER at a time.
Several ERs are developed simultaneously thereby confounding the measurements necessary to determine which of the outputs meet the ER. This is particularly true when ER’s are at the opposite ends of the engineering spectrum, e.g. “Must be strong” vs. “Must be light” Q: How strong is strong? Requires defining tensile, cross section, etc. Q: How light is light? Requires weight definition. R&D needs to determine output individually or understand how the ERs relate.
i. Not understanding Key Input Variables (KIV) that drive ER output.
In systems there may be many KIVs that drive desired output. Most teams stop looking after they find 3-4 KIVs. Typically the other ones are found during launch when production variability via materials, process, and labor, are forced into the system. This may result in product slowdowns if product does not meet specifications or a recall if product makes it to market.
True story: I know of a medical disposable that had a designated activation force (ER). This device was made of several pieces of which two were rubber. One KIV to the system was the hardness of the rubber (durometer) for these two components. The company never measured durometer of this key component during production. Company received lots of rubber components that were too hard (high durometer). Product made it to market. Customers complained of high activation force. Company instituted a voluntary recall. Very costly in terms of dollars spent/lost and customer satisfaction!
Project Management
i. Forced upon team by executive management regardless of scope/costs
ii. No/Poor planning
v. No management control or feedback mechanisms
b. Scope/Quality
i. Scope is not defined or poorly defined (a top reason projects fail/delayed)
ii. Deliverables not defined
iii. Myriad scope changes without consideration of affect on Time/cost.
1. Marketing changes to
a. product requirements
b. Use requirements
c. Volume-from a 10k/mo to 1mm/mo.
d. Countries in which product will be sold
2. Manufacturing changes
a. Manual assembly vs automation
b. Mfg. location changes (from one plant to another)
3. R&D can easily add one more product feature
4. Regulatory issues
5. Legal issues
c. Cost/Resources
i. Resources shuffled around due to firefighting because of No project-program-portfolio management.
ii. Poorly trained resources as in “(S)he’s an engineer let’s make him/her a project manager!”
iii. Task/Skill level mismatched
iv. Key Skill sets assigned to too many projects (always and always a bottleneck)
Hint: Lookup Critical Chain project management if this is a regular issue
d. Management dictating all three elements of the PM triple constraints (cost/scope/time).
This is dictating the length of all three sides of a triangle. Sometimes the ends meet sometimes they don’t, e.g. two short sides and one really long side. This also happens more than we care to admit and usually with a hand wave, “Make it so….”
Business Management
a. Projects/programs don’t align with strategy
i. No strategy
ii. Constantly changing strategies
iii. Not keeping up with changes in strategy
iv. Executive pet projects (happens all the time)
v. No method to determine if projects/programs align with strategy
b. Management doesn’t understand business strategy requires an implementation strategy.
It’s easy to say we’re going to the moon but if you don’t have any idea of what it may take it’s only a dream (or is that nightmare?)
c. “Culture eats strategy for breakfast”
A famous quotation attributed to the late business management guru Peter Drucker speaking to the need to have a business culture that can execute the strategy or recognize the need to change the culture to align with strategy.
d. No project/program portfolio management
i. Too many projects (This gets my vote for the No. 1 reason projects fail or delayed and a key killer of company moral.)
Many midsize companies easily have 200-300+ projects they can identify across all disciplines, e.g. R&D, Software, Mfg., Regulatory, Medical, Customer Service, Field Service, Supply Chain, etc.
As a manager of an R&D group in a large company I had 40+ projects for my group alone including NPI, line extensions, and Sustaining Engineering.
a. Some are high priority and assigned w/resources and costs.
b. Some are assigned w/resources and costs but no one is sure of their priority.
c. Some are picked at and mosey along when someone can spend some of their very limited time moving them along.
d. Some are hidden using hard dollars and resources
e. Some are department or executive pet projects
f. Some are project names or concepts only, on the To Do list, and without definition, scope, or resources.
g. Most require multidisciplinary teams.
ii. Too few resources/too few key resources
iii. All projects are top priority (therefore none are)
iv. Executive pet projects (happens all the time)
v. Not knowing the difference between a project, a program, and a strategy.
e. No project/program sponsor.
f. Lack of key decision making resulting in lack of scope definition.
i. Legal issues
ii. Regulatory issues
iii. Other issues(?)
iv. Flip flopping on decisions dependent upon whose making them or stakeholders involved.
This may happen when key decisions are made and take a long time to implement. Over time a new leader comes in who is now responsible for the former decision and does not believe in that decision and changes it without consideration of downstream effects.
Summary
This is a short list of the more typical causes of project failure and delay. My vote for the top two causes are:
1. Too many projects (or not enough resources) resulting in regular shifts in resource assignment and priorities.
2. No or poor scope definition resulting in regular changes to project deliverables.
Either of the above, if done perpetually, results in extremely inefficient performance and low morale.
The challenge in curing any disease is to: 1) Acknowledge there is a problem and 2) Diagnosis. Once a diagnosis is made as to potential cause(s) adequate steps may be taken to address causes.
Have a look through the list again, reminisce, and see if you recognize those causes that have affected your projects.
Question: What will you do differently next time?
ALL3PM 