Monday, April 27, 2015

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.

Monday, April 20, 2015

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. 

Monday, April 13, 2015

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. 

Tuesday, April 7, 2015

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.