The Personalities of Project Stakeholder Interactions

Project managers often must interact with many different stakeholders on a project.  Not only do the stakeholders have different interests and objectives with respect to the project, they often have very different interaction personalities.  When developing a stakeholder communication plan, a project manager should take these interaction personalities into consideration.  Depending upon the personality type, the method of communication, timing of communication, and the emphasis in the communication should be different.

Let me be clear about one thing, always communicate truth.  With all personalities you must provide a true picture of what is happening on the project and the type of interactions or decisions you need from the stakeholder.  However, in some cases the emphasis will be the facts, in some cases the emphasis will be the team members involved and some cases the emphasis will be the impact and next steps.  Let’s look at the five stakeholder interaction personalities.

Fire-fighter

This individual is focused on action.  They want to know what has happened, what is happening, and what you will do next.  When reporting on project status they want to hear about problems immediately and what you are doing about them.  To them a project communication failure has occurred if they find out about a problem on your project before you tell them.  If there is a major problem on a project, contact them immediately.  You don’t need all the facts or all the answers, but you need to let them know you are aware of the problem and doing something about it.  They will want to be involved in problem solving.  As a fire-fighter, they want to “smell the smoke.”  

Super-hero

This individual is focused on the people on the project team and those assigned to project problems.  They don’t want to know all the details about the problem; they want to know who is working it.  They put a high value on relationship and trust with individuals throughout the organization.  To them a communication failure is when an unknown person (or worse yet someone they don’t trust) is responsible for communicating with them about the project or problem.  You need to build a relationship with this person so that they will trust you.  When working on a project problem, start the communication with a list of who is working on the problem.  They will help you get the right people if you need them.

Data Demon

This individual is focused on facts.  They want facts about the project. They want facts about project problems.  They expect detailed plans, status reports, and analysis.  They would rather that you wait until you have the facts to talk with them than to have you interact quickly with vague or incomplete facts.  To them a communication failure is a project status or conclusion that is not supported by data.  When communicating with these individuals about project status, always have a detailed plan, status, and analysis.  If there is a problem, let them know that a variance has occurred and that you will provide the data about the issue as soon as you are able to collect it and analyse it.  They are not as interested in what you are doing as they are in what you know.

Process Policeman

This individual is focused on processes.  They have faith that if the process is followed, good results will happen and that the biggest business problem is undisciplined people doing unfocused work.  They want to know what process is being followed and on which step the project or project team is working.  When it comes to project status, they want to know that you are following the approved methodology and they expect the project report to be following the approved template.  They consider unapproved deviations from the process to be a major project failure.  If a problem arises on the project, they expect you to follow the problem resolution process.  When meeting with them, ensure that you let them know the process you are using and progress through that process.  If there is no process explain how you will develop one and then follow that.

Brick Wall

This person is not focused on your project, despite your efforts to get their attention.  They don’t come to meetings or conference calls.  They don’t respond to emails and status reports. Communicating with them is like communicating with a brick wall.  You and your project are either an irritant or irrelevant as far as they are concerned.  The key to working with these people will follow one of two paths.  One path is to structure your project so that you minimize the amount of interaction required with these stakeholders.  The second path is to identify something that they are very concerned about and that your project could impact.  Then lead every project communication with a reference to that item. 

Recognizing the interaction personality of your stakeholders and responding accordingly may take a little more effort, but will improve the communication and interaction with stakeholders.  When in the middle of a project issue, this can minimize miscommunication and help to quickly align support for resolution. 

Is It Time To Dump The Gantt Chart?

The most common project scheduling format is the Gantt Chart format.  It is easy to understand.  It is great for visualizing a project plan.  It clearly communicates what activities the project team should be working on each day of the project.  So what is the problem?  There are several.  The Gantt Chart relies on two demonstrably false assumptions with respect to development projects.  Added to that, once a Gantt Chart is in place, it often creates an environment of frustration, obfuscation, and team dysfunction.

Actually the correct title is the Bar Chart.  This chart is in the form of a calendar across the horizontal axis.  The project tasks are placed on the calendar with each task represented by a bar that begins on the task start date and ends on the task completion date.  The length of the bar then represents the length of the task.

Henry Gantt’s Chart

The chart became popular following the publication of a book, “Organizing for Work,” by Henry Gantt in 1919.  Gantt had worked for Fredrick Taylor before becoming an independent consultant and was an advocate of Taylor’s scientific management principles.  The Gantt Chart was developed for use in a manufacturing setting as a means to communicate to the factory supervisor what they should have the men working on next.

This leads to the inappropriate assumptions for a typical project application of the Gantt Chart.  The first assumption is that every activity that is in the project is identified and included on the chart.  This is a valid assumption for a manufacturing environment with defined process steps, well-defined tools and equipment, and the experience of having already done the activity numerous times.  The second assumption in the Gantt Chart is that the estimate for each activity is precisely accurate with little or no uncertainty.  Again, this was a valid assumption for a manufacturing operation that had embraced Taylor’s scientific management philosophy.  An operations manager would be measuring everything, collecting data, and monitoring performance.

Assumption #1: Every Task Is On The Gantt Chart

The assumption that every project task is on the Gantt Chart is invalid for most development projects.  Whether it is product development, system development, software development, or process development, the development environment is a discovery environment.  While experienced stakeholders and team members can forecast the likely chain of events there will inevitably be some activities that are discovered along the way.  These will not be in the Gantt Chart.

Further, a best practice touted by Cooperand Edgett is to use spiral development.  I have used the approach and I love it.  But it cannot be accurately represented on a Gantt Chart.  First, we don’t know how many spirals it will take to get the desired performance.  Even if we do guess right on the number of spirals, the activities in each spiral will change based upon the results of the test and analysis done on the previous spiral.  So the project management has two options.  He or she can guess what activities might be required in each spiral and probably guess some right and some wrong.  Or they just show the spiral with high level summary tasks that provide no useful information on what the team should actually be doing.

Assumption #2: Every Estimate Is Precisely Accurate

The second demonstrably false assumption is that every task duration estimate is precisely accurate.  The task will start precisely on the designated day and end precisely on the designated day.  This assumption is probably valid for some project tasks, but it is definitely not valid for many of the development tasks which have uncertainty embedded in them.  There is uncertainty with respect to the performance of the new technology.  Often there is uncertainty in the duration of the task because of the experience of new team members.  They must learn while doing, which depending upon their learning capacity and the level of instruction available to them, create more uncertainty in task duration. 

Add to this that many of the tasks are linked together either through task completion artifacts or project personnel availability.  As one task is delayed, it creates delays in other tasks and the impact can snowball through the project resulting in a Gantt Chart that is totally inaccurate.

Environment of Frustration, Denial, and Team Dysfunction

The impact of the two invalid assumptions is that a development project  Gantt Chart quickly becomes wrong.   The project manager may try to correct the chart but before he or she is able to incorporate the revisions and update the rest of the project management information, the Gantt Chart has changed again.  Eventually the project manager becomes so frustrated trying to keep it current that they just stop processing the day –to-day changes and wait to do a massive update at a major milestone or gate review.

But this now leads to a problem for team communication and progress reporting.  The team is tracking progress on a Gantt Chart that everyone knows is wrong.  Some of the team members will use the erroneous Gantt Chart as an excuse to ignore or avoid all project management activities and reports.  Others will try to twist what they are actually doing into the context of the erroneous Gantt Chart.  This leads to confusion and obfuscation of what is actually happening.

Finally the team ends up in a situation where the project manager is asking for status against a plan that the whole team knows is wrong.  This undermines the project manager’s credibility with the team.  Some team members refuse to even participate in a schedule status meeting.  They are now viewed as not being team players.  Others are twisting what they are doing into something to fit the erroneous Gantt Chart, but everyone knows that what they are reporting is not what they are doing.  Soon the other team members begin to suspect they may be lying about other aspects of the project.  By this time the team is totally dysfunctional.

The Alternative

So what should we do?  I recommend either switching to Milestone Charts and Network Diagrams or PERT Charts for large system development projects or using a Kanban chart with Milestone Reliease planning for smaller projects.   Milestone Charts can be used for tracking against calendar dates.  The Network Diagram or PERT Chart can be used for tracking activity sequence and monitoring  progress.  Kanban simplifies the project planning and tracking tasks for projects with low project management complexity. 

Constraining Innovation: The Six Sides of the “Box”

A well-accepted principle in innovation is that the innovation team must approach the innovation need with creativity.  The phrase often used is “thinking outside the box.”  But what does that really mean.  What is the “box?”

Well a box has six sides if you include the top and bottom.  And there are six types of constraints that can limit the path of innovation.  Each of these constraints can be broken.  The fewer the constraints on your team, the more likely you are to get meaningful innovation.  Let’s look at each of these six sides of the innovation box.

Technology Constraint. This constraint is the physics (or chemistry or biology) of the product or service. The laws of nature have limits.  Our periodic table has only 118 elements.  Water freezes and ice melts at specific temperatures. Copper conduct electricity and glass does not.

The only way to break this constraint is to change the physics by changing the technology you are using. For instance contractors and plumbers looking for an approach to installing plumbing in a structure that was easy, low cost, and resistant to breaks and cracks in freezing temperatures had to change from copper to PEX (cross-linked polyethylene) pipes.

Application Constraint.  This constraint is the task or use to which the product or service is applied.  Many products and services are designed to work well for a particular application.  Other applications were never considered when the original innovation took place.  Using the product or service in a new application can create new paths for innovation. 

To break this constraint you must consider the conditions and context of a new application.  Examine the assumptions inherent in the original application and those in the new application.  The different assumptions will point to new paths for innovation.  For instance, the original application of a telephone was to communicate between two individuals who were not co-located.  An assumption was that an individual was present at each telephone.  By changing the application to a messaging system, the assumption of the physical presence of an individual on each phone could be removed.  This led to the innovation of voice mail.   

Industry Constraint.  This constraint is the industry regulatory requirements and standards.  Often the standards and regulations are based upon particular technology and product or service embodiment.  These standards constrain the potential innovation paths. An innovative approach using a different technology may not be compatible with the current regulations or standards.

To break this constraint you must convince the regulatory bodies and standards agencies that they are being too restrictive.  This effort is often more about politics and vested interests than it is about technology or product performance.  For instance, for years AT&T and its Bell phone company subsidiaries controlled telephone service.  They had regulations concerning what was allowed and was not allowed on the telephone system.  Once deregulation occurred, the telecommunication industry and cellular communication has exploded with innovation.  

Organization Constraint.  This constraint is the organization systems, procedures and culture in which the potential innovators operate.  This includes the work space, the work authorization process, the risk sensitivity of the organization, and the rewards and recognition system.   Management systems like Lean and Six Sigma which strive to eliminate waste and variation often become innovation suppressors.

To break this constraint you must create a culture that encourages risk taking and creativity.  This is more than just a slogan about being innovative, it includes the business processes that review and approve new ideas.  The organization needs to reward risk taking and creativity which means deviating from tradition and the existing product or process baselines.  Slow bureaucratic processes with numerous reviews and delays waiting for the next budget cycle will kill innovative ideas.  A great example of this is the Department of Defense and the Defense Acquisition Cycle.  By the time many new systems get to the field they are already out of date.

Team Constraint. This constraint is the skills, background, and personalities of those working on the innovation team.  The broader the experiences and more diversity on the team, the more likely the team will have creative ideas.  However, the broader the experiences and more diversity on the team, the harder it is to get the team working together on a common goal.   The team also needs to have someone with the personality to challenge and push the team to make trade-offs and turn the ideas into actual products or services.

This is often the easiest constraint to break but the hardest to sustain.  Through hiring – either full-time or temporary – and training you can quickly break this constraint.  However, a change in team members can result in the resurfacing of this constraint.  Sometimes even the current team can switch from creative and innovative work practices to a sterile and hostile environment due to poor interpersonal skills among team members.  An excellent example is the experience at Apple.  Steve Jobs created a very innovative culture and teams, but at times the atmosphere was harsh and demanding.  Jobs left the company and the innovation pipeline started to dry up.  Jobs came back and there was another explosion of innovation. 

   

Resource Constraint. The sixth constraint is resources – time and money.  This is possibly the easiest constraint to understand.  Innovation often requires multiple iterations of the new product or service as unexpected or unforeseen challenges arise and must be resolved.  The innovation often leads to additional business challenges. Does the innovation now use software? There may be compatibility issues with other systems.  Does the innovation open up new markets?  There are now logistics, tax, and translation problems that we never had before.

To break this constraint the innovator requires time and money.  Large corporations will often have the resources to sustain an innovation effort.  They just need the vision and confidence to see it through.  Small start-up companies must seek angel investors or venture capital to overcome this constraint.  A classic example of this constraint was Thomas Edison’s work to create a commercially viable incandescent light bulb.  It took over 1,000 experiments and two years of testing to find a design that was commercially viable. 

As you plan your innovation efforts, consider breaking the constraints on all sides of the innovation box.  Don’t limit yourself to just one or two sides.  The fewer the constraints on your innovation team, the more likely you are to get a steady stream of high value innovations.