Monday, December 21, 2015

The Problem with RACI

While the Project Management Body of Knowledge (PMBOK Guide®) may refer to it as a Responsibility Accountability Matrix, everyone I know calls it a RACI Matrix. It is supposed to clarify roles and responsibilities, yet it often creates more confusion that it clarifies.  So let’s look at this tool, the benefits and the pitfalls that create the problems.

Assigning responsibility for work is an age-old principle.  Even in early civilization, some people were designated to have certain responsibilities. The ancient kings had cupbearer, chariot drivers, shield-bearers, and ministers of all types.  These individuals had specific responsibilities and if they didn’t perform the punishment was often sharp and swift.  In more modern times, thanks to Fredrick Winslow Taylor and scientific management theory, everyone in business has a designated role or position and they are expected to become expert at the responsibilities associated with that role.

But projects are a little different.  They don’t always lend themselves to scientific management principles. Projects are temporary endeavours undertaken to create a unique result.  Individuals on the project team are temporarily assigned to work on project activities, and some of those activities may not be well defined.  Because of the unique nature of projects, a pattern may not already exist.  Roles, responsibilities, authority, and accountability need to be assigned to prevent duplication or work or missing work.  Which brings us to the RACI matrix.

RACI Matrix

The RACI matrix is the most common tool for assigning roles and responsibility to project team members.  The matrix is structured by placing the project tasks on one side of the matrix, normally the vertical axis; and the project team members on the other side of the matrix, normally the horizontal axis.  The role of each individual with respect to each task is then noted in the matrix as either R – Responsible, A – Accountable, C – Consulted, I –Informed, or left blank if the individual has no role.

The RACI matrix assigns a role to each individual, but it does not clarify what they are supposed to do.  And that is what leads to the confusion.  Who plans the task – the “Accountable” person or the “Responsible” person?  I have seen it explained both ways.  Does the “Consulted” person only participate when asked, or are they expected to engage and ensure their perspective is included?  Again I have heard it described both ways.  And then there is the question, “How can someone be accountable but not responsible, or responsible but not accountable?” 

Questions like these and others have led to a plethora of variations on the RACI matrix.  The fact that there are so many variations is an indication that there is a major flaw with the RACI approach.  If it was working well, people wouldn’t be trying so hard to improve it.   Let me list a few of the alternate approaches.

Alternate Responsibility Matrix Approaches

  • ARCI – rearranging the letters because Accountable is more important than Responsible.
  • RASI – Responsible, Accountable, Support, and Informed attempts to better define the original Consult role by now calling it Support.
  • RACIQ – Responsible, Accountable, Consulted, Informed, Quality reviewer – this adds a role for review and approval.
  • RACIO – Responsible, Accountable, Consulted, Informed, Omitted – this approach is meant to ensure that some individuals do not engage on a task and tamper with what is happening.
  • RATSI – Responsibility, Authority, Task, Support, Informed – a slightly different segmentation of roles meant to clarify the differences as compared to the original RACI.
  • RAPID – Recommend, Agree, Perform, Input, Decide – a variation that focuses on decision making authority rather than on the actual task activity.
  • PACSI – Perform, Accountable, Control, Support and Informed – a variation that identifies some activities that must be done in addition to roles.
  • DACI – Drivers, Approvers, Contributors, Informed – a variation that focuses on the type of activity that the person does rather than their role.
  • CLAM – Contributes, Leads, Approves, Monitors – another variation that focuses on the type of activity rather than roles.

There are probably more, these are just the ones that I am aware of. 

The Problem

So what is the fundamental problem with RACI?  I believe it is that while defining roles, it does not clarify actions.  But clear actions are what a project needs.  As a retrospective tool to look back on a situation, RACI is effective.  It can determine who was responsible for success or failure?  Who was accountable for ensuring the task was completed?  Who was consulted along the way and how effective was their input?  And who was or was not informed and what impact did that have on the project?  Great questions when doing a post-mortem on a project; but not very helpful for proactive project management.

 When planning and executing a project, the project team members need to know who is doing what.  A matrix focused on actions associated with each task is much more beneficial to the team.  Who is planning the work?  Who will be helping on the task?  Who are the stakeholders that have to approve or sign off on the results of the task?  With these answers, the project leader and project team can manage their resources, coordinate the schedule, and ensure that risk mitigation plans are being executed in a proactive manner.  They don’t have to wait for success or failure and they try to understand what happened.

Recommendation: DACI or CLAM

For that reason, I recommend the use of either the DACI or CLAM approach.  These are activity-based matrices.  I have found that the level of confusion concerning who is doing what is significantly reduced when these are used in project planning and execution.  

Monday, December 14, 2015

VUCA Product Development

In most companies, developing new products is a critical component of strategy.  Many companies are finding this to be more and more difficult as their environment increases in VUCA.  The acronym VUCA stands for Volatility, Uncertainty, Complexity, and Ambiguity.  This acronym was created and gained recognition in the strategic planning circles of the US military during the past 15 years.  A body of knowledge is being developed around leadership in the VUCA world, with numerous articles and books published in the past few years.

Bob Johansen has proposed a leadership response to the VUCA environment which he titles VUCA Prime.  According to Johansen, volatility is countered by vision, uncertainty is countered by understanding, complexity is countered by clarity, and ambiguity is countered by agility. Let’s take a look at each of the elements of VUCA and VUCA Prime as they apply to product development.

Volatility

Volatile is defined as changeable – and often with an explosive or fleeting connotation.  Volatile situations are full of surprises.  Vision is the recommended leadership response.  Developing and articulating a clear vision will assist an organization through the volatility be reducing the disorientation that occurs when a volatile situation unfolds.  Even though there is rapid changes happening all around, the vision and direction stay constant; providing a basis for decision-making and action.

Product development involving innovative new technology, or a marketplace that is fast developing with new customers and competitors, can often be volatile.  The vision that is needed for the product development team is a clear product line strategy.  The strategy that has identified target markets and the characteristics of new products will guide the product development team through the technology, design, and business trade-offs that must be made when volatility strikes.  Without a clear product line strategy, the product development team often stalls as they start chasing options and waiting for decisions from stakeholders.

Uncertainty

Uncertain is defined as the state of being unpredictable and indeterminate.  There are numerous significant unknowns in the business situation.  The environment is novel to the point that past experience cannot be used as the measure for what should be done now.   However, in an uncertain environment, there are facts that could be discovered.   The recommended response to uncertainty is understanding.  This requires investigation, fact-finding, and analysis.  Rather than responding in a dogmatic manner using outdated principles, the response is to slow down and learn what is actually happening. 

Within the product development environment for innovative new products; there is normally uncertainty with respect to customer needs, product performance, and market response.  There are two approaches being used to create understanding within product development methodologies.  One approach is to do extensive upfront analysis using tools such as the Quality Function Deployment.  The other approach is to create a series of rapid prototypes of a minimally viable product to get “real-world” experience and feedback.  I have used both approaches and there are pros and cons for each.  The key takeaway for this discussion is that there is work that must be done to gain understanding.  And that work needs to be built into the development project plan.

Complexity

Complex is defined as intricate, often complicated, interconnected parts, processes, or organizations.  With complexity comes options and opportunities.  Some of these options and opportunities are very favourable and some are disastrous.  Navigating through the complexity requires numerous decisions.  The recommended response to complexity is clarity.  Clarity exposes the decision points and the options.  Clarity will also often provide a framework for understanding the implications of decisions.  Clarity exposes pathways through the complexity.

Product development of new innovative products will often involve complexity on several levels.  If the product is a system, there will be multiple components, possibly hardware and software, that must all work together.  And research shows that system integration and test is one of the most likely areas of a product development project to overrun both time and money.  In addition, there is often organizational complexity.  Marketing is developing requirements, engineering is creating designs, quality is establishing test and inspection methodologies, operations is setting up manufacturing and logistics processes and facilities, IT is bringing new databases online and possibly new systems for support.  All of these functions must work together and a change in one cascades through all the rest.  Establishing a stage-gate product development methodology with defined practices and decisions points will go a long way to creating clarity in product development.

Ambiguity

Ambiguous is defined as obscure, indistinct, and with numerous possible interpretations.  Unlike our definition for uncertain where facts are available but are not yet known; in an ambiguous environment there is normally no “right” or “wrong” answer.  Instead the answer is always, “it depends.”  The recommended response to ambiguity is agility.  This means that as the fluid situation continues to change, the decisions are revised and updated frequently.   Nothing is ever final; it is just the “current state,” with the expectation that change will soon be required.

In the global marketplace, industries are separating into those that are ambiguous and those that are rigid.  The highly regulated industries have a tendency to be very rigid and those that are not regulated are often ambiguous.  But regardless of the industry, the product development environment is ambiguous.  It follows that an ambiguous end market will create an ambiguous product development process.  As the target for product definition and performance is constantly changing, whatever product is developed will immediately need an upgrade or replacement product.   But even in rigid end markets, development is ambiguous.  The regulatory environment is often different in different countries or areas, and these regulations are frequently changing.  In addition, the regulatory agencies interpretations of regulations are often inconsistent.   Regardless of the industry, a rapid pulsing process is needed to determine the current state of the market and industry environment.  This must be coupled with a robust change management process for product development.   Finally, the product development metrics must be focused on business success or failure of the product, not on time and budget targets for the project.


If you are involved in product development today, you are probably experiencing VUCA.  You may reminisce about the “good old days” when things were calm and simple.  But don’t expect those days to return.  Instead embrace an approach to have vision, understanding, clarity and agility.

Monday, December 7, 2015

Learning Lessons from Lessons Learned

They go by many names including: Lessons Learned Sessions, After Action Reviews, Post-mortems, Post Project Evaluation, Learn and Grow, and Project Retrospective.  These sessions are the time when the project leader and project team look back over the project, or at least a portion of it, and attempt to learn from their experiences.  It is a practice that is called for in many project management methodologies, yet often neglected.  

When I ask people why they haven’t done one, I get many different reasons.  “Everyone is busy on other projects now.” ‘Why bother, we won’t change anything.” “Most of the team at the end of the project is different from the beginning team.  They didn’t participate in many of the decisions.”   In fact, often these are backwards looking, blame-focused sessions.  When that occurs, it is an indicator that the organization and project teams don’t understand how to use these sessions.

I would like to discuss five elements of effective reviews.  These are the purpose, the timing, the participants, the questions asked, and the follow-up.

Purpose

The purpose of these sessions is continuous improvement.  These are not meant to be final project reports or a history of what happened.  They are intended to improve the planning and execution of the current and future projects.  One of the implications of this purpose is that anything can be discussed.  There are no “sacred cows.”  Don’t avoid subjects because it many hurt someone’s feelings or it makes them uncomfortable.  The goal is to improve performance.  If we ignore some aspect of performance, it will not improve. 

Timing

A mistake often made when doing project reviews is that the review occurs long after the project is over and the review then considers the entire project.  A much better approach is to do a quick review after each phase or milestone with the project team so that they can immediately take action to improve the remainder of the project.  This type of review doesn’t need to be an all-day offsite meeting with formal facilitators and reports.  It can be a pizza lunch with post-it notes on a white board.

Let’s consider for a moment one of the best models of how to conduct one of these sessions, and that is the US Army’s After Action Review format.  First, note that it is not an “After War Review” with Monday morning quarterbacks looking back over years of history and trying to find the big lessons of the war.  It is a review that is immediately conducted following an action or event.  Everyone from the team is still there.  The events are fresh in everyone’s mind, and because it is focused on what the team just did; many of the recommendations are immediately actionable by the team.

Participants

This gets us to the participants in the review.  I recommend that it is the team, the whole team, and nothing but the team.  Well, you may want to have someone from the PMO or another project leader to help take notes and facilitate.  This is especially true if there were some leadership problems and the team might be uncomfortable discussing this in a meeting being run by the project leader.  There is no need for senior management in this meeting.  Their presence is likely to repress the conversation.  It is appropriate for the project leader to provide a summary of the results to senior management and the PMO.  But the discussion is likely to be much more open and honest if the meeting is just the team members.

Questions

The agenda for the meeting is very simple.  What is going right and what is going wrong.  The team may want to vent a little if there are problems or celebrate if things are going well.  Let them release a little emotion, but then focus them on these questions:
  • What is going well that we want to continue?
  • What is not going well that we need to change?
  • What should we do differently as part of the change?
  • What recommendations do you want to make to the organization to pass onto other teams?

Follow-up

Well, as you can see from the questions, we anticipate that we will want to make changes.  It is possible that the team may say that everything is going great and nothing should change.  When that is the case, the team should be making a recommendation to the organization so other teams can copy their result.  However, most of the time there will be some changes.  By conducting the review with the current project team, they can also decide what they will change – starting tomorrow.  I like to get very specific when I discuss the changes.  I go around the room and ask each person what they personally will be doing differently.  Doing this in the room among the team members will improve personal accountability among the team members.


Turning these reviews into forward looking change events instead of backward looking blame events will make them productive.  They really will drive continuous improvement.  

Monday, November 30, 2015

Will the Real Customer Please Stand Up?

I can remember as a boy watching the television game show is “To Tell The Truth” when the weather was nasty and we couldn’t play outside. The show originated in 1956 and has been produced off and on ever since, including running in syndication.  The premise of the show was that three contestants all claimed to be same individual who had some unique distinctive profession, hobby or experience.  One of the contestants was the individual. A panel questions the three contestants to try to determine who is “telling the truth” and who is making it up.   The contestant won if they could fool some members of the panel.

Have you ever felt like this when you were developing a new product or service?  There are several people or organizations who you think would benefit from using your product or service.  You are trying to get a comprehensive list of user needs and you keep getting different answers.  And soon you are wondering, “Who is the real customer?”  Unlike the game show, we can’t stop after ten minutes of questions to ask, “Will the real customer please stand up?” 

This leads us to the fundamental question of how to determine the real customer.  Is it the person who purchases the product or service?  Is the person who uses the product or service?  Is it the person who is advising the purchaser?  Is it the person who provides the money that pays for the product or service?  Is it the user’s customer who receives benefit because of how the user employs the product or service?  Granted sometimes the answer to those questions may be the same individual, but many times it is not.

Unfortunately the answer is, “All of the above.”  Which means that understanding customer needs and providing customer value can become confusing and complex.   This is one of the reasons why so many companies don’t even bother.  Instead they have the marketing organization create a “value proposition,” push the product out to the market, and see what happens. 
  
In another post I will talk more about discovering and understanding your customer perception of value.  For now, let’s look at a few principles that should be followed if your company decides to use the approach of just pushing something onto the market to see what happens.  The key to success with this approach is marketplace feedback and rapid production and marketing iterations.  Let’s look at five characteristics your company needs to be successful with this approach (besides luck):

  • Quick customer feedback.  Assuming you get customers, you need a mechanism to get feedback from your initial customers.  This is usually through direct contact by your sales or marketing departments.  You need more than just a “Like” on Facebook.  You need to understand why they bought your product or service, how they used it, and the result.  Knowing this will allow you to understand whether the product or service is creating value for your customers.  This will inform both your updated marketing and your product development iterations.    

  • Investigate the “no-sales.”   To the extent possible, find out why people did not select the product.  If they viewed the website or visited the store, ask them.  If they never heard about the product, find the communication barrier.  Knowing why a customer does not buy is just as important as knowing why a customer does but a product.  Again, it will inform both you updated marketing and your product upgrade iterations. 

  • Rapid product change.  The likelihood that the product or service you offer will exactly hit the market is low.  There are just too many unknowns.  So you need to be able to quickly modify the product or service to respond to the market feedback.  This has implications for both the product design and your product development process.  Your product should be modularized to allow for rapid redesign of selected modules.  In addition, you probably need to be using one of the Agile product development methodologies.

  • Tailor the value proposition.  Once you find out what is working, you can tailor your message and your marketing to better fit a target audience.  Customer testimonies are examples of the use of the product are always great advertising.  In addition, you can select your market channels that best reach the market segment you are now going after.  A clearer message of the product or service value and a more focused marketing channel should lead to more potential customer understanding the value, which will drive sales.

  • Be prepared for success or failure.  The last point is to be prepared for both success and failure.  Success can lead to a quick spike in demand.  While that is great, it requires capacity to meet the demand.  Have a plan for how you would add capacity.  Don’t cut corners when you add capacity.  Otherwise you may create a quality problem which leads to a quick loss of customers and creates a negative impression in the market about your product or service.  Of course, if the demand doesn’t materialize, you need to repurpose your capacity.  Set some clear thresholds at the time of market introduction that will indicate the need to add capacity or cut production and sales.  Set those while everyone is still thinking looking at the situation from a logical perspective, once you are into the day-to-day management, it is hard to remain unemotional about those decisions.


Following these principles can help you find and focus on your target market.  It will probably take one or two iterations, but soon the “real customer” will become clear. 

Monday, November 23, 2015

No One Takes You Seriously When You Are Naked

Mark Twain once said, “Clothes make the man.  Naked people have little or no influence on society.”  The underlying truth to this statement is that those who are acting in a manner that is well outside the societal norms, especially if they are engaging in what is viewed as outlandish or impractical behaviors, are not taken seriously.  They are not able to influence their surroundings.

So why did I bring this up?  There is an application of this principle in business settings.  If you don’t understand your company’s business model and how your company intends to implement the business strategy, you won’t be taken seriously.  If you are viewed as irrelevant or a flake, you won't be taken seriously.  You are essentially naked in your business environment.  People may tolerate you and find you amusing, just like we used to laugh at the people who would “streak” at sporting events or concerts.  No one really took them seriously, and no one will take you seriously either.

This means that to become a person of influence in your business, you need become “clothed” in the business and industry.  For many years I worked with several Fortune 500 companies providing training to their new college hires.  While I was supposed to be teaching them project management (which I did), I found that in many cases what was more important was that I taught them how to think in business terms.  In other words, I had to teach them how to get “dressed” for business.  Here are the five suggestions I provided:
  • Become familiar with what is happening in the company.  Read the company newsletter.  Follow the company on social media.  Keep track of the company press releases and shareholder reports.  It is not enough to just know your department or your division of your company, you should be aware of the major issues and initiatives in your company.  A great way to do this is to join one of the corporate communities of interest.  Sometimes these are formal and sometimes they are informal.  Regardless, make friends and get involved with others in the company so that you will be aware of what is currently important and why.

  • Become familiar with what is happening in your industry.  You were hired for your technical expertise that was learned in college.  But now you must apply that expertise in the business setting to be successful.  You need to know what is happening in your industry so that you are prepared to do that.  You may be an IT person, or an HR person, or an engineer.  If you are in IT, what are the trends in the use of information technology in your industry?  If you are in HR, what are the hiring, staffing, and retention issues that your industry faces?  If you are an engineer, how is product or process technology changing the nature of competition in your industry?  To be relevant and influential, you need to know what is happening.

  • Become known for an aspect of professional competence related to your work.  You don’t have to be an expert in everything, but to be taken seriously you need to be viewed as an expert in something.  You want to become a “go to” person on a topic that is important to the business.  This means that you will be specifically sought out and included in key discussions and decisions.  Once you have a seat at the table, your voice will begin to count on more and more topics.  Developing this expertise will take some time.  You may need to read books or attend conferences.  Look around your business for an area of business concern where the organization is currently weak.  Focus on that area and become the expert.  Your work to become familiar with your company and the industry should help you pick an appropriate area of focus.

  • Developing financial acumen was another aspect of business preparation that I recommended.  Finance is the language of business.  Companies typically measure success or failure in financial terms.  Personal or organizational goals and measurements often include financial goals such productivity, savings, growth in key ratios, or return on investment.  Many of the new college hires had no background in these topics.  They could balance their check book, but they didn’t know how to read a balance sheet.  This is an area where there are books and classes that can help someone get up to speed.  In fact, one option is the online course offered through GoSkills that I teach. (www.goskills.com/Course/FinanceProfessionals)

  • The final point was to demonstrate a mature and caring personality for their co-workers.  Work isn’t a beauty pageant, but if it were, their goal should be to win the award for “Miss Congeniality.”  You want to develop a reputation as someone who is encouraging and supportive of others.  Not a reputation of being “snarky,” rude, and off-color.  I don’t mean that you pretend everything is always wonderful when it isn’t.  But when things are difficult and people are discouraged, you keep a positive attitude and work to make things better.  The rest of the organization will see you in the role of a problem-solver, not a problem-maker.  This is the hardest attribute to teach.  That is because it is less about knowledge and more about attitude and habits.  However, habits can be changed through practice.  That is why athletes spend so much time in practice, so that their body will respond to the challenges of the game or meet out of habit.  Use whatever reminder system works for you to think about your attitude and practice developing a positive and encouraging way of interacting with others at work.

So if you want to be taken seriously, you need to put on the clothes of business.  These five suggestions are a great way for you to “dress for success.”   

Monday, November 16, 2015

Trust - The Value Accelerator

I was reviewing the successful and unsuccessful business ventures I have been involved with over the last few years. One of the things that struck me was the element of trust that was a necessary ingredient for successful business.  Where trust was present up and down the value chain, the business was successful for all parties.  Whenever trust was missing or broke down, at any point, the business dropped off or never materialized.

Let me give you a few examples.   One of my newer clients came about because a friend from many years, who is in a C-level position at a large organization, recognized a need in his organization and called me.  Within a few weeks I was onsite providing assistance with a pressing problem and the solution has had an immediate positive impact in their operation.  In another case, a long standing client had an immediate need due to personnel changes.  A few phone calls and my work with that client increased significantly.  The good news for the customer was that there was no interruption in their ability to offer their products and services. Trust created successful business relations in both cases.

By the same token, I recently lost an account when a new person came on board at the client.  I did not have a relationship with the new individual.  After several misunderstood emails and a bad teleconference, I lost the client.  (The fault was primarily on my part – I assumed a relationship existed because of my previous work when it didn’t.)  Another example was a start-up client that I have worked with for years.  The company is still trying to land their first big account.  One of the difficulties is that the product/service they have developed integrates aspects of sales, operations, marketing, and finance into a single system.  Although they are often able to find an advocate in one of those departments within a possible customer, they haven’t been able to find an advocate in all the departments.  The typical organizational silos create a barrier between departments.  The result is they have not been able to gain the trust from all departments and one of the departments will veto the project.  (Interestingly, it has been different departments in different companies.) Lack of trust destroyed business opportunities.


The point to be noted is that where trust exists, business transactions were accelerated and value was created for both the customer and seller.  Where there is lack of trust, transactions are stalled.

Trust Enablers

So how do we build trust in our business relationships?  How do we especially build trust in relationships with customers?  There are three trust enablers.  When these three are strong, trust will grow.  When one is missing, there will be an element of mistrust on the part of the customer that often slows the transactions.  When two are missing, you can forget about doing business with that customer.

  • The first enabler is the efficacy of the product or service.  Does it work?  Does it work consistently? Does it work in the manner that the customer expected it to work?  This is often referred to as the product value.  Customers seek out products or services because of this value.  However, this type of value is seldom a competitive advantage.  There are other potential sellers who can offer a similar product or service.  The absence of efficacy will destroy trust.  If the product does not work the way the customer thinks it should work, the customer will likely feel cheated.  So to enable trust and create value, the product/service must work.

  • The second enabler is the reputation of the company, often referred to as brand value.  In the mind of the customer, some brands are desirable, others are to be avoided.  And in many cases, they have no opinion about the brand, until they check references.  A company’s reputation can open customer’s doors or close customer’s doors.  This is so serious that there are entities like Better Business Bureaus who exist to report on the reputation of companies.  My most recent two clients found me, rather than me finding them.  They contacted me because of my products/services and reputation.  Those two items were trust enablers.  They demonstrated value to the customer.  But to actually close the deal, we needed the third enabler.

  • The third enabler is relationship.  As much as we might wish that businesses make decisions strictly upon the cost versus benefit of a product/service or the historical experience with a supplier, the reality is that relationships matter.  It is still people who are making the decisions.  That is why you do business with your brother-in-law or college roommate; even though they might not have the best product on the market.  Most customers want to look a potential seller in the eye or speak with them over the phone.  People like to feel special.  They appreciate it when a supplier greets them by name or shares a common interest.  It creates a special bond that builds trust.  Relationships are often initially based upon first impressions.  Everyone carries around in their head stereotypes or caricatures of people.  These could be based upon age, gender, race, religion, origin or any of a hundred other factors.  These will immediately create bonds of trust or barriers of mistrust with individual they just met.  If an individual fits a positive stereotype, a relationship bond can often be quickly established.  Negative stereotypes can be overcome, but that will take time to develop a personal relationship.

The Trust Chain


So let’s recap.  We create value for our customers and companies when a transaction occurs.  A transaction is much more likely to occur if the customer trusts the seller.  In order to establish trust, a seller needs a product/service that works, a positive business reputation, and a relationship bond with individuals within the customer’s organization.  If you are a seller wanting to accelerate your business and create value for customers and your company, you must focus on the three trust enablers.         

Monday, November 9, 2015

Project Kanban – Integrating Scope, Schedule, and Resources

One of the latest techniques in project management is to use a Kanban approach to project scheduling.  Those advocating for this scheduling tool highlight the characteristics of blending resource allocation with schedule and scope management.  Some even go so far as to say that it is more than a tool; it is a brand new methodology.  Let’s look at it in more detail.

This approach is often tied to Agile methodologies, but it has actually been around far longer.  I was using a modified Kanban project scheduling tool in the 1980’s.   The tool shows the relationship between scope schedule and resources.  Like the Gantt chart, it is very effective for managing the day-to-day status and tracking.  And also, like the Gantt chart, it is a tool that can be used with many different project management methodologies. 

This tool works best for those projects where many different deliverables go through similar steps or activities.  The Kanban schedule is set up as a matrix.  The vertical side of the matrix is the list of project deliverables.  The horizontal side is the steps or activities in the project.  Normally, at the top of the matrix, the level of resources available for each step is listed either in terms of the number of individuals or the number of deliverables that can be actively worked at one time.  See the diagram below.


Kanban Principles

Kanban scheduling relies on two important principles.  The first is that it is “pull” scheduling, not “push” scheduling.  This means that a deliverable does not move to the next step until there is a resource available to work on it.  As soon as the resource completes a deliverable, it pulls the next deliverable from the preceding step.  That way a step does not become glutted with many deliverables all hung up at a bottleneck.  

The second principle is that it is a “visual” scheduling tool.  The “pull” indicator is visual and the status of how many items being worked on at one time is also visual on the matrix.  In addition, I normally will change the cell color of the deliverable and the step to show what is being worked on and what is completed.   Visual control normally leads to improved project team communication because it is simple to understand.

Kanban Weaknesses

There are two weaknesses with using Kanban scheduling.  The first is that it is difficult to translate the schedule to a calendar.  The Kanban schedule is a matrix.  Often the matrix will have dates for each step of each deliverable, but it is difficult to take a table of dates and picture what is happening on a calendar.  That is why I normally will also use a calendar-based Milestone chart when using a Kanban schedule. 

The second weakness is that it is very difficult to track inter-relationships between deliverables.   If the deliverables are separable that is not a problem.  If there are numerous points of interaction between deliverables, the ability to pull can be confused.  In that case, the network diagram is a better scheduling tool because it shows those relationships and allows the project team to calculate a critical path.

Planning with Kanban

So let’s talk through how a project plan would be represented using a Kanban schedule.  First create the list of deliverables – this is usually derived from the scope statement or project contract.  Then determine the categories of activities that must be accomplished on each of the deliverables.  This is the same type of activity you would do when developing a work breakdown structure.  With these two pieces you can build the matrix.  Next, determine the resources capacity you have for each activity type.  Finally, estimate the amount of time required for each deliverable and estimate the dates when each activity will end for each deliverable.  Place that date in the appropriate cell of the matrix.  See the diagram below.


Managing Project Progress with Kanban

The Kanban tool is an excellent tool for managing day-to-day project activities.  Thanks to the visual control aspect, it is easy to see what is underway, what is complete, and what is coming up next.  Because I use cell colors to indicate activity status, the current project status is easy to see.  Also, problem deliverables or problem steps will quickly “jump out” from a review of the matrix. 

In the diagram below it, the present date is July 25.  It is easy to see that Deliverable #7 is behind schedule.  This is a major issue on the project and should be receiving the project manager’s focused attention.  In addition, the “Update/Debug” step is becoming a bottleneck.  There are five deliverables that could in process at that step, #3, #4, #6, #10, and #11.  However, the capacity is only to work on three, so deliverables #4 and #11 are not being worked on by anyone at this time.  So far it is not a major bottleneck, but deliverables #2, #8, #12, and #13 are in work in the previous activity and could be turned over to the update/debug queue soon.   




The Kanban schedule tool can be very useful for some types of projects.  It combines scope, schedule and resources into one easy to read visual display.  If this tool is not currently in your project management toolbox, you should consider adding it.

Monday, November 2, 2015

Channels, Navigational Beacons, and Project Management

When bringing a large ship up a river into a harbor, the captain and pilot must be careful that they don’t run aground.  There is a channel of deep water that they must follow.  By staying in the channel they avoid hazards such as rocks, reefs and sand bars.  There are often navigational beacons and buoys marking the channel to assist the captain and pilot.  If there are no navigational beacons, the captain must find a local experienced pilot, or proceed very slowly, taking soundings all along the way.  The local experienced pilot can still bring the ship safely into harbor because he or she knows the path of the channel and can tell where the safe path is by other landmarks.  The slow approach and soundings will tell the captain of dangers and allow the ship to maneuver to avoid them.

You are probably thinking, “What does this have to do with project management?”  Well, channels and navigational beacons are great metaphors for some important project management principles.

Every project is different, yet every project has some similarities.  Each project has a start and an end point.  There is an optimal path the project should follow for achieving the lowest cost or fastest time.  Depending upon the company and the project type, that path is unique.  Often when starting off on the project “voyage,” the water looks calm and smooth, but there are reefs, shoals, and shallow water that can cause the project to run aground.  The project manager, just like a captain or ship’s pilot, must navigate through the hazards and bring the project safely to its end point. 

To assist the project manager, many times an organization will create a project management methodology with templates, checklists, and reviews that are used to “chart” the path the project should follow.  The methodology defines a channel that has been determined to be the best path to navigate the risks and dangers of the project.  The reviews, checklists and templates are the navigational beacons and buoys that are used by the project managers to guide them through the channel.  The channel is still likely to have some sharp turns and dangerous eddies, but the templates, checklists, and reviews are there to guide the project manager through these dangers.

Without pushing the metaphor too far, we can see some of the problems and challenges that project managers and organizations face by considering some of the challenges associated with channels and navigational aids. 
  • One problem is that the channel will often change over time.  Storms can shift sand bars and a channel can quickly be blocked.  In fact there may not be a navigable channel following a storm.  Within companies, re-organizations or new initiatives and systems can change how work is done. The original channel may no longer exist and a new channel must be found or dredged.

  • Another problem is that the channel fills up with mud and sand over time so that it is no longer deep enough for the ships to come in.  When that occurs, the channel must be dredged to clean it out.  Within a company, a project management methodology often becomes cluttered over time.  A Lesson Learned on one project adds a new checklist or template.  The new checklist is added, but the old ineffective checklist is not removed.  A new management team wants to do project reviews in a different manner than before.  The new reviews are added, but the old reviews are not removed.  The organization needs to periodically review the “channel” in the project management methodology to ensure that it does not get cluttered up with unneeded or ineffective templates, checklists and reviews.

  • A third problem is the use of the beacons.  Small boats can often scoot around the beacons and maneuver outside the channel because they have a very shallow draft.  As the captains of those boats are promoted to larger ships with deeper drafts, they can no longer safely navigate outside the channel.  Within companies, small projects can often be successful even though they did not use some of the templates, checklists and reviews because their scope or team is so small.  However, when these project managers are promoted to the large projects, that same behavior can lead to disaster.  The larger the project the more important it is to use the full project management methodology.  

  • A fourth problem is that the captain and pilot must be able to see the navigational aids and understand what they mean.  This requires training.  In a river or harbor, the color, shape, and number of the navigational aid has a distinct meaning.  Within project management, checklists, templates and reviews also serve a distinct purpose.  Using the wrong checklist at the wrong time in a project can lead to bad decisions that create project disasters.  Project managers, project sponsors and key project team members need to learn the methodology.   Project management methodology training, tools and technique training, and periodic performance reviews are needed to ensure that project managers are effectively working with the project management methodology.


Whether your project is best represented by a super tanker, a catamaran yacht, or a two-person dingy, it is still important to know the channel and to understand the navigational beacons.  Using them appropriately will enable you to bring your project safely into the harbor.

Monday, October 26, 2015

Kaizen, Lean, Six Sigma - What's the Difference?

Kaizen, Lean, and Six Sigma are all business improvement approaches.  They can be thought of as three different tools in the business leader’s toolbox.  It is important to understand the focus and purpose of each.  Using the wrong tool will not fix the problem, and it may make things worse.  As an illustration, if I have three tools: a hammer, a screwdriver, and a wrench; I must use the correct tool to accomplish my goal.  I must use a hammer to drive a nail; a screwdriver will not do the job.  However, if I need to remove the cover of a light fixture from the ceiling, I will want to use a screwdriver.

Kazien

Kaizen can be summarized as, “Fix the next problem.”  Kaizen is a team-based problem solving technique.  Kaizen puts focus on a problem to understand it and solve it – then on to the next for continuous improvement.  A Kaizen project is normally requires only a few days to complete.  The Kaizen team is usually dedicated to fixing the problem during those few days. 

The Kaizen team employs data collection techniques and uses basic problem solving tools to understand the root cause(s).  They then create a solution (within the boundaries and constraints given them by management – such as budget or time) and an implementation plan for the solution.  Often the Kaizen team is empowered by management to immediately implement their solution. 

Kaizen works very well with problems that have a singular root cause, or to improve new and emerging business processes that have “low hanging fruit.”  Kaizen is not as effective at solving complex system problems or transforming an entire business operation. 

Lean

Lean can be summarized as, “Eliminate waste from the flow.” Lean is a process analysis problem solving technique.  Lean focuses on mapping a business process flow and identifying all areas of waste – time waste, cost waste, and wasted activity. 

A Lean analysis for a process normally takes one week to one month, (depending upon the nature of the process).  Once the analysis is completed and solution options identified, the implementation of change can take several days to several months, depending upon whether facility or system changes are needed.  Lean will consider all aspects of how a process is performed, from the process controls, operator training, facilities and systems used, and the process measurements.  Often the team conducting the Lean project is the same individuals with day-to-day management responsibility for the process.  They will lead the change implementation. 

Lean works very well for improving business processes that have a continuous or regular flow.  Lean is not as effective for processes that are only occasionally performed or for problems that have suddenly emerged.

Six Sigma

Six Sigma can be summarized as, “Remove variation.”  Six Sigma is a process control problem solving technique.  Six Sigma focuses on measuring the outputs from a process, aligning those outputs with customer expectations, and then controlling the process so that the outputs stay aligned.  Six Sigma uses a structured five phase project management approach: Define, Measure, Analyze, Improve, and Control.  Six Sigma establishes a permanent management control system to ensure the process maintains a minimal amount of variation in process output. 

A six sigma analysis will normally start with several weeks of data collection, once the real-time data collection system is established.  The data will undergo statistical analysis to understand all sources of variation so that they can be either eliminated or controlled.  This often takes weeks or months to complete the analysis and testing of hypotheses.  The new control system is then implemented and used for day-to-day management of the process by process operators and managers.  Because of the extensive use of statistical analysis, often a Six Sigma team will include several people with process knowledge and several people who are Six Sigma Black Belts or Green Belts.  The solution will often require a change in management control processes and procedures and usually requires changes or upgrades to various business systems. 

Six Sigma works very well with complex business systems that have known performance goals.  Six Sigma is not as effective with processes that have changing requirements.  Also, Six Sigma is a cultural change for management and employees since all process control decisions are data-driven rather than using intuition.  Management no longer is providing direct process supervision, but is acting more as a coach, facilitator, and strategic decision maker.   Operators are now responsible for making the day-to-day decisions required to achieve desired process performance.  This culture change can take a long time.

Comparison

Kaizen
Lean
Six Sigma
Cross functional team
Process management team
Team with process knowledge and statistical expertise
2 -5 days
2 weeks to 2 months
3 – 6 months
Find and fix a problem with clear root cause(s)
Improve process flow – time, cost, and quality
Control process output to consistently meet customer expectation
Typical Tools: data collection, brainstorming, root cause analysis, basic quality tools
Typical tools: value stream mapping, data collection, process analysis tools, Kanban, value-added time
Typical tools: data collection, process capability analysis, statistical hypotheses testing, Gage R&R, DOE, control charts
Limitation: Has difficulty addressing complex problem
Limitation: Requires a consistently used stable process
Limitation: requires expert knowledge and culture change

Synergy

These approaches can be used simultaneously and in concert with each other.  A few example scenarios are described below.  These are for illustration only; your business conditions may not precisely fit these:
  • A new operation is having many problems at startup.  I would start with Kaizen projects to solve any “Crisis” problems and begin to establish some predictable performance.  Once the big problems are resolved, I would follow with implementing Lean to remove waste and inefficiency from the process.  This will improve cycle time, cost and quality.  I would then implement Six Sigma to establish a control system to manage the process.
  • An existing operation is undergoing a major upgrade for new products or systems.  I would start with Lean.  Map the old and new processes to understand and communicate the changes.  As the new process is introduced, I would assign Kaizen teams to resolve unexpected problems that arise.  Once the new process is stable, I would implement Six Sigma to establish a control system to manage the process.
  • An existing stable process does not meet industry benchmarks for cost or quality.  I would start with Six Sigma to ensure the process is aligned on customer value and then determine the issues within the process.  If issues are due to singular root causes, I would use Kaizen teams to solve those problems.  If the issues are due to systemic problems with organizational processes, I would use Lean to understand and improve the process.  (If issues are due to complex business and system interactions that are inherently unstable, I would not use either of these techniques but would rely on a Design of Experiments analysis.)


Business conditions should be used to determine an approach that is best suited for achieving your goals and objectives.