Sharing tools and ideas for Portfolio, Program, and Project Managers

Archive for the category “Strategy”

Why Projects Fail


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

a. Time/Schedule

i. Forced upon team by executive management regardless of scope/costs

ii. No/Poor planning

iii. No schedule integration

iv. Death by a thousand cuts

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

6. On and on and on……

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.

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?



How Do You Plan With Your Team?

How do you plan your project?  How do you create, gather, compile, organize, and record your project plan and schedule (remember these are two different things…)?  Do you or your company have a procedure or is it ad hoc (“fashioned from whatever is immediately available…”)?  I’ve seen a range of planning, from:

1) the PM slapping together a Gantt chart,  then handing out the schedule with a few names here and there (think of this as resource planning), to

2) kickoff meetings where key items are discussed and recorded, to my favorite-

3) a full two and a half day planning session.

Each method above has its advantages and disadvantages.  I’ll touch briefly on the first two then describe why I believe the third choice is superior for medium to large projects.

In order of appearance above…

1) In the first method little upfront time is invested (low cost),  resources begin work immediately (hitting the schedule hard!), while true cost of the project ($$$) is determined later (and several times over) when all the project SCRAP is continually changing. (SCRAP- Strategy, Constraints, Risks, Assumptions, Parking Lot (unresolved questions)).   Comment: while the good news is they at least have a schedule my comment is this is a thinly disguised state of continuous confusion.  The PM and or management thinks they will meet the schedule because someone created one.  Meanwhile all the issues that plague projects will appear (they always do) and the schedule will be done over and over again until someone (PM, stakeholder, or business) runs out of money or time.

2) In the second method time is invested in determining or agreeing on Goals, Objectives, and Scope, perhaps at a project kickoff meeting.  Additional meetings are required to determine SCRAP one or more component at a time over the course of several days, if not weeks, maybe, maybe not.  My experience with this method is that teams tire of the additional meetings very quickly.  Getting team members to attend multiple planning meetings may be difficult especially if they are already attending the project meetings.  Key inputs may or may not be determined in advance.  In some cases they are dictated and not agreed upon by team members.  The good news is this method recognizes the need to obtain inputs from and communicate high value aspects of the project to team members.  Key decisions may be captured in a PM plan or at least captured in meeting minutes.  Discussions will evolve around typical project issues.  Time is limited to discuss full breadth or depth of project related matters.

3) As is the case in all these methods the purpose is to improve project definition, boundaries, understanding & strategy.  The multi-day planning session typically has higher up front time related costs.  8-10 core team members participate @ $50/hr for 20 hours = $10,000.  Plus meeting expenses, e.g. large meeting/conference room, food, projector, easels, etc.   Team members are introduced (team forming/storming/norming) and become focused on the project over the course of 2.5 days.   In addition to Goals, Objectives, and Scope the team defines and begins to understand project SCRAP.  Figure 1 below shows the agenda for this multiday exercise.Planning Session-Agenda

You should be familiar with many of the items listed on the Agenda.  Some of them are less traditional.  The slide titled  “Where are we?” is intended to capture what is currently known and perceived about the project.  Also the slide asks the additional questions “What do we know we don’t know?”, “What should we know that we don’t?” and “What don’t we know that we don’t know?”.  Also, when was the last time (or first time) you ever did a SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) on a project?  Some of this may be covered during Risk Analysis.   The idea here is to immerse the core team/key player or stakeholders into the thought process for this project to uncover many of the discoverable issues as soon as possible in order to address them.

Scheduling multiple meetings and handing out multiple agendas (method 2) does not typically allow for the depth and breadth of discussion required of key projects.  In the multiday session many of the discussions are done as exercises using flip charts.  These notes are hung as they are completed around the conference room and stimulate discussion in other areas.  Also, as the meeting progresses and decisions are made, new insights are gained then a finger goes up “That’s not on the list”  and someone goes over to capture the  new insight on the appropriate flip chart.  The immersion and visual notes (flip charts) capture more information quickly allowing for deeper,  broader, and focused discussions.

Once the meeting is completed all information is gathered, captured and placed into what becomes the initial Project Management Plan.  It doesn’t take but one day to type up the notes, place them into an outline and publish it to the team, stakeholders, and management for feedback.  There are typically unanswered “Parking Lot” issues/questions that require resolving.  The Project Management Plan will be modified based on the responses to those questions/issues.

I’ve both facilitated and been on teams using this approach.  The PM plans that results from this method are outstanding with higher quality inputs and less surprises during execution.   While  this method may be used at anytime it is not for every project.  With a high upfront cost it should be used for efforts that are of strategic importance, high cost, or high risk.

I have a slide deck of 40 slides I created to prepare and facilitate this multiday planning methodology.  It includes the slides and speaker notes to facilitate the meeting and what is needed to prepare for and execute the meeting.   Send me a request and I’ll forward the slide set to you free no questions asked.  This is another tool I’ve found to be extremely valuable therefore  the desire to share it and see it used by others.  I hope it does for you what it has done for me….execution of projects with fewer bumps and surprises and improved outcomes.

Basic Portfolio Management or “Doing the right projects.”

Basic Portfolio Management or “Doing the right projects.”

I’ve worked in organizations where everyone sets their own priorities.  That’s great as long as they are the only one in the entire organization.  Since that was not the case there were lost opportunities in maximizing outcomes.  This blog is an introduction into the idea, not a new one, in which you should understand all the projects and programs you have ongoing (the portfolio) and determine in some manner those that are of most value to the organization, value not necessarily meaning money.

Here’s the definition of Portfolio and Portfolio Management from PMI’s The Standard For Portfolio Management 2nd Edition:

Portfolio– A collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives.  The project or programs of the portfolio may not necessarily be interdependent or directly related.

Portfolio Management– The centralized management of one or more portfolios, which includes identifying, prioritizing, authorizing, managing, and controlling projects, programs and other related work, to achieve specific strategic business objectives.

Figure 1 Project Portfolio Flowchart

Figure 1 shows a basic process that describes a generic portfolio management method to prioritize a portfolio of projects.   Inputs and Outputs shown are lists or documents or information that is written down and agreed upon by those involved in the process.

Most businesses do portfolio management at some level even if they don’t call it that.  They go through a mental exercise of; Project A takes 2 years to complete, costs $500,000, and pays back $3 million. Project B takes 4 years to complete, costs $2 million, and pays back $4 million.  Most business would choose project A.  The key point is that they have identified three evaluation criteria in which to make their decision- Completion time, Cost, and Payback.  The trouble is that there are typically many evaluation criteria not a few.

Figure 2 Project Priority Categories

Figure 2 is a basic list of high level criteria that may be used to determine where the value lies in a project.  There are only nine categories in this example with some various values to give you an idea of what can be done. Some portfolios may use a system with dozens and I’ve heard of portfolios that have a couple of hundred or more evaluation criteria.  Typical use is to assign a value to a project for each category/line on the list and score the project based on its assigned values.  Since there are nine categories with five points being the highest value in each the highest project score would be 5 points x 9 categories = 45 total points.  I’ve also added a weighing column to give you an idea of other options.  Do this for each project.  High scores should be top priorities.  Now do a reality check.  If your highest priority project isn’t on the top of the list determine why! Are there additional criteria you’re mentally using that aren’t accounted for using the scoring method?  Is the high priority project a pet project sucking up valuable resources regardless of its value to the company?  This is not uncommon.  Use this information to make an informed and data driven decision!

Basic steps required to prioritize (per Figure 1):

  1. Determine the strategy for your organization.  Should be written strategy, goals, and objectives.
  2. Determine who will be involved in this process, president, VPs, director level?
  3. Determine the list of portfolio components (projects) with some minimal level of detail, e.g. How many components? How much will each cost?, How long to completion?, How many man-hours will this take?  What do we get in return (dollars, market share, mindshare) and how much?
  4. Assign values and rank each component.
  5. Balance components. Are you doing all new product introductions or manufacturing cost reductions or a combination of both?
  6. Approve your portfolio.
  7. Assign resources.  This means assigning resources be they people, equipment, or dollars to each portfolio component from the top portfolio priority until you run out of one of the resources because resources never precisely match your portfolio.  You can either use the leftover resources to work on projects farther down the list knowing these projects will be slow moving due to a shortage of required resources or you can use leftover resources and apply them to the projects higher up the list and previously resourced to expedite where possible.
  8. Execute.

It’s imperative that those portfolio components that are assigned full resources are monitored and controlled to effectively execute each of the project plans.  If you cannot execute your fully resourced high priority projects there will be a need for discovery as to why and how it fell short.  There should be some adjustment somewhere in your process.

Small companies and big companies do portfolio management.  Small companies and big companies don’t do portfolio management.  You can tell which one does or doesn’t after working there for a brief period. Companies that do portfolio management typically have higher worker moral and are more productive. Companies that don’t typically have lower moral and are less productive. This is because personnel are yanked from project to project fighting the latest fires that erupt requiring a refocusing onto the new high priority project resulting in lost time due to changeovers and the new learning curve required of new projects.

I urge any organization that has more than a few projects to use this simple outline.  Outcomes are higher moral, higher productivity, and better strategic implementation and performance.

SCRAPP™ Method or How To Integrate Your Schedule

  1.  Print out your project schedule as a NETWORK DIAGRAM.  Depending on the size of your project, this may take one “A” size sheet (8 1/2″ x 11″) or several “E” size sheets (34″ x 44″) .  Don’t be afraid of the amount of paper used.  I’ve literally covered all the walls in a large conference room using this method.  It’s money well spent.   Make sure the settings on your project software shows discrete lines between tasks. This usually means setting the software so it draws a straight line from task to task.  This is so you can trace each predecessor and successor tasks.  If it is set to only draw horizontal and vertical lines the lines will tend to run together and you’ll lose traceability.
  2. Write on each of SIX large sheets of paper (e.g. those 2 ft x 3 ft easel size Post-it® Notes) one of the following headers:  STRATEGY, CONSTRAINT, RISK, ASSUMPTION, PROBLEM (known problems), and PARKING LOT (issues to be resolved but need more info or are outside of project scope but affect the project).
  3. Begin your analysis by choosing and reviewing a starting task, a task with no predecessors. Using a yellow highlighter and a red pen, if the information is correct, highlight it in yellow to show that information has been reviewed and is correct.  Use the red pen for any corrections.  What you review for each task will be dependant upon the information you’ve chosen to show in your printout for each task , e.g. task name, resources, start date, etc.  Your project software should allow you to change this information.  As a minimum I would recommend Task Name, Resource Name, Duration and effort.  Start and finish dates are not important at this point as they will be driven by the final schedule and dependencies. If there are date constraints list them on the CONSTRAINTS sheet.
  4. Next, review the first task’s successor tasks.  If the relationship is true and the line connecting the predecessor to the successor task is correct, and going in the right direction, highlight the entire connecting line, not just a portion of it, in yellow to show it has been reviewed and is correct.  Mark any corrections or changes using the red pen. Thus if the dependency was incorrect crossout the incorrect line and draw the new/corrected dependency using the red pen.  Review the balance of the task information and mark as reviewed and correct (yellow) or corrected (red).
  5. As each task and dependency is reviewed, questions/issues/problems may arise.  If so, write them in plain English on one of the six SCRAPP sheets.   For example, if you could accomplish a deliverable three different ways, right down the one selected on the STRATEGY sheet.
  6. If during this review there are risks discovered and associated with a particular task or strategy write it on the RISK sheet.
  7. Tasks may have constraints, i.e. finish on or by a certain date or limited amount of funding, capture these on the CONSTRAINTS sheet.  Projects have many assumptions; capture these on the ASSUMPTIONS sheet.  Again, write these in plain language without all the techno speak. This is so others outside the project, mainly executive management, can read and understand it.
  8. Your project may face a known roadblock or problem.  List these on the PROBLEM sheet.  Any items that cannot be addressed immediately or require further research place on the PARKING LOT.
  9. As you work your way through the schedule every aspect of it should be discussed, e.g. “Should we proceed serially or create a parallel path?” (hint: capture it on the STRATEGY sheet).  Do not stop until ALL TASKS, TASK INFORMATION, AND DEPENDENCIES ARE HIGHLIGHTED YELLOW OR CORRECTED IN RED.  Any item not highlighted or corrected has not been reviewed.  You’ll know where you left off and where to pickup if this takes more than a day.
  10. Revise the schedule per the redlined corrections using a different filename for your schedule.  As you go through and make each correction in the software, use a green highlighter/marker and mark the red corrections on your printout to show you’ve inputed the changes.  This is because there are typically many changes and it is easier to keep track of where you’re at.
  11. Once all changes are input, printout the schedule a second time starting from step 1 above.  It typically takes 2-4 rounds before the schedule is finalized.
  12. Type up all SCRAPP paper and review with your team.
  13. Finalize and document your schedule.  Print out one page of  schedule milestones.  There shouldn’t be more than 12-15 key milestones on this page.  Combine this one page of milestones along with the SCRAPP paper. You should now have 2-4 pages, one page of milestones and the balance SCRAPP paper, that can be used as an executive summary. They should always travel together.  A schedule will never make sense unless the SCRAPP is known.
Fig. 1 Network Diagram before SCRAPP Method

Fig. 1 Network Diagram before SCRAPP Method

Fig. 2 Network Diagram after SCRAPP Method applied.

Fig. 2 Network Diagram after SCRAPP Method applied.

There are several advantages to this method:

  • It is a team building exercise with key inputs and decisions determined by the team.
  • Team members will have a higher degree of confidence that the project is achievable.
  • As circumstances change within your project you will be in a position to make better decisions because you will have previously discussed many strategies, options and details.
  • All elements of SCRAPP can and should be integrated into the Project Management Plan.
  • Lastly, when management asks for a schedule you can provide them with the SCRAPP paper and a single page of key milestones instead of 20 pages of a Gantt schedule that has little or no rigor or meaning behind it.

This method is best used for project types that are vastly different every time.  That is why this method has worked extremely well in the medical industry.  Well versed project types like construction, while able to take advantage of this method, may not extract the advantages of other project types.

How do you do schedule integration or do you?  I’m interested in hearing how others have approached this issue.

Post Navigation