Five Tips for Process Improvement Projects

Many small projects are focused on improving an existing business process.  The process works but it is slow, error-prone, and creates complaints and frustration.  Other higher priority projects were ahead of it, but now it is finally time to work on that process.  Here are some tips that apply whether it is a technology/system process, and administrative process, or an operations process.  Of course, you need to do the typical project management activities of planning the scope, schedule and resources; then tracking the activities to determine if you are on plan.  But these tips are to address some things that are unique to process improvement projects. 

1. Win Supervisor Support

We have all heard about the importance of top management support for a successful change project.  Top management support is great, but even more important on a process change projects is the support of the supervisors over the process.  They are the individuals who will help you to understand the major pain points and they are the individuals who will sustain any improvements that are implemented. 

Often these individuals are not supportive of changes to the process.  They have a very parochial interest in the process – it is their job to ensure it is performing well.  They may view a project to change it as an attack on their ability or authority.  These individuals are often suspicious of the change and will actively work to undermine it.  So as you approach the change, don’t attack the old process; which will be seen as an attack on the supervisor of the process.  Rather acknowledge the benefit it has brought the business in the past and focus on how the changes will improve the performance for the new conditions that the process must operate under.

2. Fix the Customer’s Pain

Often this type of project is subject to scope creep.  There are many things that could be done to improve the process; but the project team is constrained by money and resources to only implement a few of the potential improvements.  Prioritize the potential changes in two ways.  First prioritize by the pain the process is causing to the customer of the process.  Fix the major pain points first.  When there are multiple ways to fix a pain point, then select the approach based upon the most important project constraint, either time or money.  

When you start to work on a process, the individuals in the process often have great ideas for improvement.  Many times these ideas may be an improvement from the perspective of those working in the process, but they may have no impact on the individuals or organizations that experience the result of the process.  Ensure you have addressed the customer’s pain, and then accommodate all of the other changes that you can.

3. Use Current Proven Technology

Many of the process changes today will involve some level of technology or system implementation.  A difficulty with technology for processes is that the technology changes rapidly.  About the time that you get all the bugs worked out of a new system, it is obsolete and must be replaced.  So to minimize that companies will sometimes leap to the new leading edge technology hoping that the time until obsolescence is further off.  But with this leading edge technology, there are still many elements that are not well characterized or that are discovered while doing the improvement project.  So what is the answer?  Try to use current technology that has been proven through multiple applications.

Now that is not to say you can’t use brand new technology.  However, when that is the case, the project is a higher risk project. Project estimates should be adjusted and budget and schedule reserves should be allocated to the project because there will be unexpected technical problems that must be resolved.

4. The Changed Process Must Be Simple

When creating changes to a process, you should always be looking to simplify any manual steps or personal interactions with the process.  Simple processes will run faster and with higher quality.  The principle is known as Poka Yoke, or mistake-proofing.  It is not the same as “dumbing – down” the process.  I am not suggesting that you curtail any of the performance standards or options, but rather, that you examine each step and determine if there is another way to accomplish that activity that does not require manual interactions, or that makes it easier to accomplish that step correctly.

An approach I have often used is to determine what a “standard normal” run of the process would look like.  I then do two things.  First create a screen early in the process to determine if this is a “standard normal” run, and then simplify and automate the main process for that “standard normal” condition.  The non-standard runs go through a more manual process, requiring more interactions and decisions.  This approach will accelerate and improve the quality for the “standard normal” runs.  And allow the process operators to focus on the unusual and difficult items without slowing the others.   

5. Test and Test Again

One of the biggest problems I have found with process improvement projects is the verification test run that goes flawlessly, followed by the implementation and operational runs that are a disaster.  A process improvement is not demonstrated just because you were able to do it once in a row.  A pilot run is needed.  In addition, the pilot run is susceptible to the Hawthorne Effect which means that the improvement is because everyone is watching while our best people do the work.  When the attention is gone and the average, below average, or new worker is involved in the process; the performance improvement is not to be found.

I suggest a pilot run of the process with sufficient quantity to establish “normal flow.”  If it is a customer interaction process, you should develop customer use cases that span the range of normal customer interaction.  If it uses technology, should test it with all potential operating systems or applications.  Finding the problem now while the project team is in place and can fix it is far better than finding the problems after the project is over and success has been celebrated..

Following these five tips will bias your process improvement project for success.  

Choosing the Best Project Management Methodology

Despite some claims to the contrary and the desires of senior leaders, there is no single “best” project management methodology for all situations.  At its core, project management is a process of creativity and change.  Whether it is developing a new product, building a new facility, upgrading an existing process/system, or planning your summer vacation; it is changing the existing state of things into a new and better state.  And this is why there is no one “best” methodology.  The existing state could be stable or in crisis, the new state could be clear or ambiguous, there are varying levels of constraints on time and resources, and there are varying levels of complexity of the project results and required activities. 

A project management methodology brings order into this environment.  It clarifies activities and decisions.  It sets expectations and identifies problems and issues.  A project management methodology enables proactive management rather than reactive fire-fighting as the future state is created.  But the wrong project management methodology can make things worse.  It can create confusion, frustration, delays, overruns and ultimately project failure.

There seems to be hundreds of gurus and experts touting their project management methodology as the best.  In reviewing these, there are three categories of project management methodology that emerge.  Each of these has strengths and weaknesses.  Each of these is appropriate for some types of projects and not others.  Each of these has many variations as they are uniquely applied to different projects, different industries and in different organizations.  The three are sequential/waterfall, adaptive/concurrent, and agile/scrum.

Sequential/Waterfall

This is the approach most often associated with traditional project management.  In this approach, the project starts with a clear and specific set of requirements.  A detailed project plan is created where each organization or individual is assigned a specific task that is to be done at a set time and for a set amount of resources.  As one project task completes, the results are handed to the next individual or organization in the planned sequence. 

This approach relies on the development of a detailed project plan.  The classic project management tools such as a Work Breakdown Structure (WBS), Gantt Chart, Critical Path Analysis, Responsibility Matrix, and Earned Value Analysis are ideally suited for this type of project.  These tools are used to optimize the project during the planning phase in order to meet the requirements within the best overall time or cost.

This approach is well suited for those projects where the requirements are known and stable.  It provides order and predictability to project activities.  However, it is not very flexible.  In an unstable environment or when the requirements are only general in nature and not specific.  The project manager either cannot form a plan or they must make many assumptions, some of which are sure to be wrong, in forming the plan.  Changes to the plan with this approach are often time-consuming and expensive, so this approach should not be used with a highly dynamic environment.

Adaptive/Concurrent

This is the approach that is often used with complex projects.  In this approach, a cross-functional or multi-disciplinary team manages the project through a series of phases.  As the project starts, the team is considering requirements and options to decide a framework for the project result.  The team reaches a decision and they start on the next phase.  The project progresses from phase to phase with all disciplines participating in the work concurrently and then agreeing on the project decision before moving to the next phase.  The project adapts as the team is able to use the results and conclusions from one phase to influence the activities and decisions of the later phases. 

This approach relies on a highly collaborative project team.  Rather than a detailed prescriptive project plan, the team uses key milestone decisions to guide the project activities.  The work is often iterative in nature as each of the team members builds on the solution from the preceding phase.  These projects are often managed by a series of checklists for each milestone decision point.  Project management tools that help to managed complexity such as the Network Diagram, Responsibility Matrix, and Risk Register are particularly useful with this approach.

This approach is well suited for those projects where the requirements are general in nature and the details must be determined during the course of the project.  In addition, this approach works well when cross-functional decisions are required to reach an optimal project result.  However, this approach requires a high level of interactive participatory project management.  The detailed plan is continually changing which requires a high level of project integration activities.  This approach is not appropriate for organizations that do not work well in a collaborative dynamic environment.    

   

Agile/Scrum

The agile methodologies came onto the scene in 2001.  Several agile methodologies were created for software development.  The Scrum approach has become the most widely adopted and is now used in many settings beyond software development.  This approach has provided structure to an age-old practice of putting a dedicated team on an urgent business problem to resolve it – the crisis project.  In this approach a dedicated team is assigned for a short duration to work on focused and prioritized set of requirements, known as a sprint.  The team does as much as it can in the specified time and delivers whatever it completes.  Requirements not completed within the time period are either dropped or transferred to a new project.  On larger projects, a series of sprints may be used.

This approach relies on dedicated self-organizing team to work collaboratively to complete as much as they can in a short time.  The classic project management tools are not used.  Instead, the team relies on a prioritized list of requirements and two visual control charts, a Scrum Board and a Burndown Chart to track progress. 

This approach is ideal for relatively small projects where time is critical and the scope can be flexible.  The project duration can be shortened by an order of magnitude, but it is essential that the team be fully dedicated and fully empowered to do the project work. In a highly regulated environment with externally specified requirements and extensive documentation, the benefits of this approach or lost.  Also, when the project team needs to be very large, this approach is inappropriate.

So to choose the best approach, consider your situation – both the project and the organization.  You may find the need to modify one of these a little, or even use a hybrid where one approach is used for a portion of the project and another for the remainder.  

Authority and Response-ability

“Both for practical reasons and for mathematically verifiable moral reasons, authority and responsibility must be equal - else a balancing takes place as surely as current flows between points of unequal potential. To permit irresponsible authority is to sow disaster; to hold a man responsible for anything he does not control is to behave with blind idiocy.” Robert Heinlein, Starship Troopers.

So what should a project manager do when authority and responsibility are not balanced?  Are they faced with disaster or idiocy?  How can they effectively deal with this situation – which often happens?

Authority and Responsibility

Authority and responsibility are terms that are often used interchangeably.  But they shouldn’t be.  They are very different.  Wise project managers understand this and watch for a situation where authority and responsibility are divided.  When they see it, they know they have uncovered a project risk.  Let’s explore the definition of each.

Authority deals with control.  It is the other side of the accountability coin.  If you have authority over something, you control it.  If you are accountable for something you must answer for what happened to it.  Authority cannot be shared.  Oh sure, you may say that you are sharing authority with someone else, but when push comes to shove, and disaster is happening; who do people turn to for the decisions?  That is the person with authority.

So what about responsibility?  Rather than control, this deals with causation.  Is this person “able” to elicit a “response?”  Do they have “response – ability?”  Can they initiate a process; start an investigation; or cause an interaction to occur?  Then they are responsible for the chain of events that happens.

But once a chain of events is started, the responsible person may not be able to make decisions and control what is happening.  They may not have the authority needed to manage the results of the response.  And by the same token, an individual may have the authority to manage the results of the response but lack the ability to initiate the response or prevent its initiation. In that situation, authority and responsibility are divided and you are just a step away from disaster or idiocy.

A Practical Example

Let’s put this on a practical project level.  In a new product development project, one of the core team members is told that they have the authority and responsibility to test the new product to be sure it is ready to release to customers.  The company wants the test finished as soon as possible so that they can begin to sell the new product.  As this individual is about to start the testing, they realize that the product given to them to test is a preliminary prototype and does not represent the final design.  In addition, the test requirements were established by the quality department and do not reflect the input from the voice of the customer. 

We will start with the case where our core team member has both authority and responsibility.  They are responsible for initiating the test sequence and the authority to determine that the product is ready for release to the customer.  In this situation they may determine that some of the testing would not be able to demonstrate that the new product is ready for release.  They initiate the tests that they believe are appropriate and that are relevant to the configuration of the prototype.  At the same time they demand a proper configuration of the product be provided and the final test requirements revised to align with customer needs.  They don’t complete the tests until those are available. 

If this individual had responsibility but no authority, they would start the test with the prototype and current test requirements.  They are responsible for testing, so they test as soon as possible.  They initiate a chain of events (tests) that yield test results.  They are not accountable for whether the product is ready for release to the customer.  They do not have authority in that area.  Doing that type of testing is idiocy.

If this individual had authority but no responsibility, they would demand a production-configuration product and a rewrite of the test requirements.  They would continue to send things back to the other departments until it is perfect (and it never is).  Nothing would be initiated.  They have authority to declare the product acceptable, but they are not responsible for ensuring the testing is done as soon as possible.  This will lead to a project disaster.

The Project Manager and Risk

Here is the problem for project managers; when they see a mismatch between authority and responsibility they can expect confusion, delays, and rework at that point.  The disaster of irresponsible authority can occur leading to delays, overruns, and massive rework.  The idiocy of holding a man responsible for something he can’t control leads to frustration, anger, and ultimately to unacceptable  and wasted effort.

It is for this reason that I believe that the RACI methodology is a very poor approach to use with a Responsibility and Accountability Matrix (RAM).  RACI separates the responsibility and accountability (i.e. authority) and often spreads it across multiple individuals.  RACI, which stands for Responsible, Accountable, Consult, and Inform, assigns these roles to individuals for each project deliverable or activity.  While the methodology allows one individual to hold multiple roles, it often leads to a separation of responsibility and authority.  

I prefer to use the acronym CRSI, Customer, Responsible, Support, and Inform.   Every deliverable or activity must have both a Customer and a Responsible person.  With this approach the person who is responsible should also have the authority needed to complete the deliverable or activity.   The Support and Inform roles are only used as needed.  This has the added value of emphasizing customer awareness and customer-centric activity on the project.

Don’t fall into the trap of separating responsibility and authority on your projects.  Avoid both idiocy and disaster.

Ignorance Is NOT Bliss!

Back in 1742 Thomas Gray wrote a poem that included the line, “Where ignorance is bliss; tis folly to be wise.”  That may be the case in academia (he was at Eton College) or for those who spend their time reclining in idyllic pastures.  There is often a lot of ignorance in those settings.  But that is not the case with the world of project management.  The ignorant will not stay blissful for very long on a project.  Reality quickly intervenes and then wisdom is urgently needed.

Projects – A Process of Change

This is because of the inherent instability of projects.  They are a process of change.  They are creating a new product, process, facility, or system.  They are building up or tearing down.  They are modifying, improving, adapting, or upgrading.  Projects are all about changing the status quo. And when there is change afoot, there is instability and uncertainty.  Ignorance of the change does not protect someone from the impact of the change.  Ignorance is not bliss, it is project disaster.  Wisdom is not folly, it is vital for recognizing and reacting to changes.

Now you may be thinking that the instability and uncertainty could result in a better than expected condition.  Bliss may still occur by accident.  The project may go much faster than expected.  Things may work better than expected.  The cost may be lower than expected.  But the problem with those conditions is that phrase, “than expected.”  The business is expecting a certain level of project performance.  The change that the project brings about will impact the organization.  The business leaders are aligning the rest of the business processes and systems to accommodate that change.  Finishing the project with anything other than the expected level of performance will cause a misalignment and some corresponding negative business impact.

Assume Nothing Is Certain

Wisdom is needed on projects.  Socrates said, “The only true wisdom is in knowing you know nothing.”  That is accurate for most projects.  With the inherent uncertainty of project activity, the project will not go as planned.  The project leader and project core team members must be continually monitoring project activities and deciding when and how changes should be made to the project plan.  Don’t assume that everything will happen as planned: Check on it.

This may sound like micro-management.  It is.  But it is micro-management only in the sense that you are checking frequently to understand what is happening, not that you are continually over-riding the decisions of team members or directing them on how to do their job.  This type of micro-management is a frequent pulsing of project activity to uncover roadblocks, miscommunications, misunderstandings, and project problems.  The project leader will then work to correct each of these.  

  

Pulse Meetings

I recommend the use of project pulse meetings.  These are frequent regularly scheduled team meetings.  I know, you are saying to yourself, “We already have too many meetings! I can’t add one more.”  These meetings will ultimately reduce the amount of time spent in project meetings. 

I hold project pulse meetings every day.  The meeting lasts about 10 minutes.  These meetings are not long technical discussions and status reports, these are a quick check to find problems.  My agenda for these meetings is very simple:

1. Did the tasks that were supposed to finish yesterday finish?  If not, what do you need to get them done?
2. Did the tasks that were supposed to start yesterday start? If not, what do you need to get started?
3.  For the tasks that are underway, have you uncovered any roadblocks that will prevent you from fully completing the task on time?

Typically there are only about 10 active tasks on a project.  It takes less than a minute to answer these questions for most tasks, so the meeting is done in 10 minutes.  Then the project leader works offline with the appropriate task leader(s) to understand any problem that was raised and develop a solution.

This type of Pulse Meeting lets everyone on the team know if something is ahead or behind schedule.  They also will know the major issues the project faces.  This type of proactive knowledge allows the team to act wisely.  They can decide to ride a problem out, add extra resources or attention to a problem, or change the project plan to avoid or accommodate the problem. Thanks to the Pulse Meeting, the project leadership is not ignorant of problems.  They can proactively respond to them while they are small and reduce the need for crisis intervention or project failure.

I have conducted these meetings both in a face-to-face manner when the project team was essentially co-located and in a virtual manner when the project team was distributed across multiple locations.  I set the meeting to be at the same time and place each day.  And – this is vitally important – I cap the time, usually at 10 minutes. 

I have found these to be far more effective than weekly one hour team meetings.  In those meetings, we often don’t find out about a problem until it is already 4 or 5 days old.  By then, it is often impossible to recover back to the original budget or schedule.  In addition, these often turn into a forum where each person is talking about everything they are doing, but we lose sight of whether tasks are starting and finishing on time.

Pulse Meetings pull back the veil of ignorance and allow the project leader and team members to act wisely. 

Characteristics of a Value Creator

I have heard people use the phrase, “a culture of customer-centric value creation.”   When I ask what that means, the answers become fuzzy.  So in the interest of providing a starting point to the conversation, I offer this perspective.

As I work with individuals across many industries, companies, and levels, I find that their approach to business situations can often be categorized in several ways.  I believe that two important categorizations with respect to customer-centric value creation are whether they have an internal or an external focus to their work and whether they approach their job as an employee or an entrepreneur. Let me describe each of these in a little more detail.

Internal or External Focus

Most people try to do a good job with their work.  Whether it is pride or self-preservation, they want their work to be considered acceptable.  But how are the standards of acceptable performance determined? 

A person with an external focus will be looking to their customer for those standards.  If their work is supporting the activities of a customer-facing process, their customer is the business customer.  If their work is supporting the activities of an internal process, their customer is the business unit or department that receives the output of their process.  Either way, an externally focused person is looking outside their process activity to determine acceptable performance.

A person with an internal focus will be looking to the job description, the procedures, or the checklist to determine what to do.  They do what their instructions say to do, nothing more and nothing less.  They do not concern themselves with the impact of their performance on the customers of their business process.     

Employee or Entrepreneur

For this discussion, entrepreneurism is not based upon whether someone has started a company; rather it is based upon the attitude they have about their role in the organization. Do they see themselves as on owner responsible for company success or are they an actor playing a role?

An employee sees themselves as a role or a position on an organizational chart.  They have a prescribed area of responsibility.  They have specific assets or activities for which they are responsible.  Their attitude is that they have a job to do and they will do it well.  Within their area of responsibility they are willing to act – even improvise a bit, but they will not act outside their area of responsibility without specific direction.

An individual with an entrepreneurial attitude is not focused on just their position in the organizational chart.  Rather they are aware of what is happening across the company.  They strive to improve the organization’s ability to reach its goals.  They feel personal ownership for organizational success. Wherever they see opportunities they either act to take advantage of them, or they influence others to act.

So let’s take these two characteristics and place them in a simple four-block diagram.  When we do this we begin to see patterns in the behaviours of individuals.

Risk Avoider

This is the employee with an internal focus.  Their goal is to do their job correctly, as it is defined by the organizational chart and procedures.  They often take great pride in their work.  However, they do not step outside the boundaries of their work process.  They are content with the status quo and they resist change.  I believe that this is the majority of the workforce in most companies. 

Problem Solver

This is the employee with an external focus.  Their goal is to ensure that the process in which they are involved is running smoothly.  They look beyond the requirements of their own specific activities and determine if their customer is satisfied with the results.  If the customer is not satisfied, they seek to satisfy the customer through the assets and resources that they control.  These individuals often act as the voice of the customer within the organization.

Empire Builder 

This is the entrepreneur with an internal focus.  Their goal is to increase their power and influence in the organization.  They look beyond their current position for opportunities to take on additional responsibilities.  Often this is because they believe the work is not being done well by others and that they could do it better.  When these individuals have good people skills, they are viewed as leaders in the organization.  When they do not have good people skills, they are viewed as power-hungry tyrants.

Value Creators

This is the entrepreneur with an external focus.  Their goal is to create as many satisfied customers as possible.  They are seeking to understand customer needs and interests and to provide value propositions that address those needs and interests.  They can be very disruptive in an organization because they are often advocating changes.  Internally focused individuals will often see them as a threat to the existing organization and employees will often see them as undisciplined.    

A Culture of Customer-Centric Value Creation

Based upon this model, several questions immediately arise.     

• How many people in the organization must be Value Creators to establish a customer-centric value creation culture?  100%? 50%? 10%? 
• Can you have too many Value Creators? 
• Can you convert people in the other categories into Value Creators? Training? Incentives? Coaching? 
• What, if any, operational or governance controls should be imposed on Value Creators?

I don’t have the answers to these questions.  I have not seen the inner workings of enough customer-centric value-creating organizations to discern a pattern.  But I do believe a framework like this will help us understand culture change that must take place for most organizations. 

Critical Path and Chickens

I hear many project managers and stakeholders talk about the project critical path, but I seldom see anyone actually use it to help them manage the project.  Is that because they don’t know what the critical path is, or because they don’t know how to manage with it?  In my opinion, it is both.  Project managers don’t actually calculate the critical path.  But even if they did, neither project managers nor stakeholders know how to use the critical path to manage the project.  The best approach I have seen involved a rubber chicken.

What is Critical Path?

Let’s quickly review.  The critical path is the longest path through the project and therefore sets the boundary for the shortest time to complete the project.  Since it is the longest path, all other paths are shorter and should not impact the end of the project.  To accelerate the project, you must accelerate the critical path.  A delay on the critical path will automatically cause a delay on the project.

Critical path is typically calculated using project management software. In order to calculate the critical path, the project manager must first create a network diagram linking all project tasks and activities.  With the network diagram or flowchart of the project activities set, then estimate a duration for each task.  With this information the longest sequence of tasks from start to finish on the project can then be determined.  That sequence is the critical path.  It is not necessarily the most difficult path; it is the longest duration path.

Why Is Critical Path Seldom Calculated?

I frequently ask project managers if they know their critical path.  The typical answer is that they know what it is.  When I ask to see their calculations or the schedule chart that shows the critical path they start dodging.  They tell me that they haven’t actually done the calculations, but they know what the critical path is.  When I ask them to give me the sequence of events, it is often just a list of several difficult tasks that many times are not even linked together.  At that time it is obvious that they do not know their critical path.

Calculating the critical path requires that the project manager have all the project tasks for the project, or at least a phase of the project.  This can quickly expand to be what the project manager perceives to be unmanageable. 

I was working with a company recently on a development project.  We created the network diagram for just one deliverable in one phase and that network diagram had over 400 tasks in it and would take about six months.  This wasn’t because we were trying to micromanage and created miniature tasks, it was because there were several departments and several locations involved.  Each had activities to do and these were followed by a number of coordination activities between everyone.  That was just one deliverable in one phase for the project.  To do the entire phase would be about 2,000 tasks and the entire project would be over 5,000 tasks.   The project manager was overwhelmed by the thought of creating a project schedule with that much complexity – so he didn’t.     

This illustrates one of the problems.  Most project managers do not have a schedule that is detailed enough to actually determine a critical path.  And the creation of a detailed schedule could be an enormous undertaking for the project manager, even with the use of software.  So project managers don’t have a detailed schedule.  They have a very high-level schedule that is often missing key points of intersection between activities. Yet these points of intersection will drive the determination of the critical path. 

So what is the answer?  It depends upon how important schedule is on the project.  If schedule achievement is critical and there is significant business benefit for schedule acceleration, the project needs to invest in a detailed network diagram that has all the points of intersection mapped out.  Yes this is work, but without it, you cannot determine the critical path.  If schedule is not the most important aspect of project success, then I would not invest in the effort to create and maintain the schedule.

How Do You Use Critical Path Information?

I often hear senior managers ask a project manager what is their critical path.  Even if a project manager provides that to the senior managers, they do nothing with it.  The critical path determines how fast the project can finish.  If the managers want the project to finish faster, they should be asking what can be done to shorten tasks on the critical path.  They should also be working with their people to ensure they are prepared to immediately start work on critical path tasks that are in their department.  I have seen numerous delays on critical paths because the individual who was scheduled to start the “next task” on the critical path is not prepared.  This is as much a failure of senior management as the project team.

Once the critical path is identified, the project manager needs to pulse the critical path task every day – maybe twice a day.  A delay of even a day on the critical path is a delay to the end of the project.  This pulse is to find if there are any problems and if there are to immediately start to fix them.  The second thing the project manager needs to do is to warn the individuals on the next task that they are about to be the critical path.  They can get ready to start immediately.  The handoffs between tasks are where most of the time is lost on the critical path.

So where do chickens fit into this? When I was a young project manager I was leading a sub-project on a large enterprise-wide project.  The overall project had thousands of tasks and activities across many departments.  We were behind schedule and a new project leader introduced a critical path awareness technique – the rubber chicken. We had to set up our detailed schedules and a project critical path was determined.  Whoever was managing the task that was currently active on the critical path had to carry a rubber chicken around with them at the office.  If you were at your desk, the chicken was on the desk.  If you went to a meeting the chicken went with you.  The only way to get rid of the chicken was to complete the task and hand the chicken to the individual leading the next critical path task.  This was a fun visual reminder of the critical path and it helped to keep the entire organization focused on accelerating the project to reach the schedule goals.

On a large project, critical path management is not easy.  However, by doing the calculations and managing the handoffs, it will help you achieve the schedule goals.  

The Missing Customer

It is time to transform the Business Case model that is used by companies for approving projects.  I have seen hundreds of business cases. I even wrote a book on how to develop them.  But I am now convinced there is a critical weakness in them.

The customer is usually missing.

A project business case normally will evaluate a project opportunity by comparing the benefit and the cost through a Return on Investment (ROI) formula.  Most companies now incorporate the best practice of also evaluating whether the project is aligned with the business strategy.  If the project is aligned and the benefit is greater than the cost, the business case recommendation is to do the project.  

This is a company-centric approach.  The customer is missing from this evaluation.  Sure, sometimes the business strategy may be to increase customer satisfaction or grow market share and revenue, but the measures used are always internal measures.  The business case evaluates the cost to the company and the benefit to the company.  While I agree that those are important, I also believe that a better decision will be made when a company includes the consideration of the cost to the customer and the benefit to the customer.

Business Value Chain

Business transactions require a customer.  Until an individual or organization has decided that they value something more than the money in their bank account, there is no business transaction.  (I am ignoring for the time being the coercive power of government to take money through fees, fines and taxes.)  The business value chain starts with a customer decision and ends with the fulfillment of the customer order and payment for the product or service.  It is only when the chain of events that makes that happen occurs that value is created.  Creating new products that no one wants does not create value.  Offering services that no one needs does not create value.  Building facilities and systems that do not improve customer service or customer satisfaction do not create value.  These may create assets that we put on a balance sheet, but non-performing assets have no value.

To fully understand the business value chain, you must include the customer’s actions and decisions in the process.  If you expect the customer to purchase something because of this project, the value chain should start with the customer condition which results in the recognition of the need for the product or service.  The business value chain should then proceed through the steps and decisions made by both customer and your organization to get to the point of a sales transaction.  Depending upon the type of product or service, the business value chain continues through the steps of creating and delivering the product or service, including work done at your suppliers.  Of course you need to include the final invoice and payment at the appropriate step.  Even then the business value chain is not complete.  It should include the initial use of the delivered product or service and the resultant customer satisfaction or irritation as they experience the product or service.

Only when you have fully mapped and understood the business value chain will you understand where value is created or potentially where value is destroyed.  Otherwise, you may get a local optimization that improves value at one step yet decreases the value at many other steps.   A classic example of this is the phone systems where the caller has to listen to a menu of options and then select a number.  This reduces cost for the company operating the phone system, but it can be a problem for customers.  I have been on several systems where I went through multiple layers of selection, but there was no suitable option for the purpose of my call.  Eventually I get to a point where I am put on hold for many minutes waiting for a live body to pick up the phone.  This has been so annoying that there are several business that I refuse to do business with now because of this system.

Business Case Value

So let’s go back to the business case.  How does a company account for the value to the customer?  How do you calculate ROI when the “return” for the investment does not occur in your company?  I suggest that companies calculate two ROIs for each project, the internal ROI and the customer ROI.  The internal ROI would be calculated in the same way that a typical business case ROI is calculated.  Use internal costs and internal benefits to calculate whichever method your company normally uses, such as the NPV, breakeven, or payback method. 

But a second ROI should be calculated and this is the ROI for the customer.  I recommend that this be done for a single customer and that the calculation be a “static” ROI instead of the dynamic “ROI” calculations, like NPV and payback that include a time factor in the calculations.  The static ROI would be the net benefit divided by the cost to acquire, expressed as a percentage.  The most difficult portion of this ratio will be to calculate the net benefit.  Some types of customer benefits are “hard benefits,” meaning they are measurable and can be easily converted to a monetary value.  This would include productivity savings or performance improvement.  But some benefits are “soft benefits,” which are much harder to quantify and may vary significantly from customer to customer.  This would include brand affinity, peace of mind, or societal responsibility.  The only ways to place a value on these is to talk to the customer.  It is likely that there will be different customer ROIs for different customer segments.  I’ll discuss how to do this in a future blog post.

With internal ROI and customer ROI, a company can make a better decision about a project.  High customer ROI will likely lead to enhanced project impact and future benefits for all parties.  A low customer ROI will likely lead to reduced project impact and alienation from your customers.