Monday, March 27, 2017

Stakeholder Personas Part 4 - Data Oriented

Stakeholder management is a major aspect of project management.  The Project Management Institute identifies it as one of the ten major knowledge areas of project management and has numerous tools and best practices for managing stakeholders.  But let’s face it.  You don’t manage the stakeholders.  In fact, it is much more likely that they are managing you.  So what you manage are your interactions with the stakeholders.   Now “interactions” implies that there are at least two individuals involved, you and the stakeholder.  In this series, I want to address the best practices for interacting with stakeholders based upon how they normally interact.  This is based upon what they consider to be compelling issues and their primary area of concern.  I have identified five personas that represent the types of stakeholders I have encountered over the years.  These are the action-oriented stakeholder, the expert-oriented stakeholder, the process-oriented stakeholder, the data-oriented stakeholder and finally the uninterested stakeholder.  In this post I will talk about interacting with the data-oriented stakeholder.

The Stakeholder

The data-oriented stakeholder trusts the data.  They don’t care who collected it or what procedure they used, provided the approach was valid.  They just want to know the facts.  Give them test results, survey results, or the output from your model, and they are ready to make a decision.  Give them your opinion, or even the opinion of several subject matter experts, and they will still want to go run a test or do a study to confirm it with facts.  They believe that mistakes are made when we make decisions based upon assumptions and opinions - facts are needed to reduce the risk.  They may ask where or how you got the facts, but that is just to be certain that you are not making them up or using inappropriate data.  And you can count on them to check the math on your presentation slides to be sure everything is adding up.  If there is a mistake, they will catch it, and at that point you will have lost credibility. 

Interaction Style

The key to interaction with this stakeholder will be to communicate through data.  You can summarize the data, but always be ready to provide the details behind your summary and conclusions.  These individuals will often appreciate a statistical analysis of the data – and they will understand the statistics so be sure you do your calculations correctly.  If there are holes in the data, know why you do not have that data and be ready to explain either why it does not matter or what you are doing to collect that data.  The types of questions they will be asking are:
“What tests or analysis did you do and what was the result?”
“How many tests have you run?  How big was your sample in the study?”
“Is this consistent with other data we have seen? If not, why not?”
They would appreciate getting the full data set from your test or study.  You don’t need to provide that in a presentation, but you should have a handout ready to give to them that includes that data.
If the data is clear, they will make a quick decision.  If the data is inconclusive or incomplete, they will ask for more studies, tests, and analysis until the data gives a clear picture.  They do not want to be rushed or pressured into making a decision. 

Key Messages

When discussing your project, have the actual data – cost, schedule, or performance data – associated with the issue being discussed.  Be ready to explain the thresholds for what is considered to be good or acceptable levels and what is a problem.  You can then defend your position or ask for your change based upon what the data says.  The discussions should focus on the validity and completeness of the data followed by the implication for your project or organization.  If you don’t have data, don’t ask for a decision. Instead discuss the approach you will be using to collect data.

Good News and Bad News

For these individuals, bad news is missing, suspect or incomplete data and good news is clear valid data that tells an unequivocal story.  Even if something catastrophic happened on the project, if the data clearly indicates the cause and you are able to correct or avoid that cause in the future, this will be considered good news.  However, if something either good or bad happens and you don’t know why, that is bad news to this stakeholder.  It is an indication of an out of control situation.  If you find yourself in that position, be ready with a plan for investigation that will lead to facts and data to explain what happened.

Final Thoughts

If you come to these individuals armed with facts, data, and analysis, these individuals will be supportive. If you don’t have data or you can’t explain it, they will tear you apart.   I have had the privilege to work with several stakeholders who operated in this fashion.  In one case, I was able to quickly make a major scope change in a large project because I had the data to back up my recommendation.  I must admit that early in my career I have been caught a few times in meetings with this type of stakeholder where I did not have my facts straight.  Those quickly became very uncomfortable meetings.

Tuesday, March 14, 2017

Stakeholder Personas Part 3 - Process Oriented

Stakeholder management is a major aspect of project management.  The Project Management Institute identifies it as one of the ten major knowledge areas of project management and has numerous tools and best practices for managing stakeholders.  But let’s face it.  You don’t manage the stakeholders.  In fact, it is much more likely that they are managing you.  So what you manage are your interactions with the stakeholders.   Now “interactions” implies that there are at least two individuals involved, you and the stakeholder.  In this series, I want to address the best practices for interacting with stakeholders based upon how they normally interact.  This is based upon what they consider to be compelling issues and their primary area of concern.  I have identified five personas that represent the types of stakeholders I have encountered over the years.  These are the action-oriented stakeholder, the expert-oriented stakeholder, the process-oriented stakeholder, the data-orientedstakeholder and finally the uninterested stakeholder.  In this post I will talk about interacting with the process-oriented stakeholder.

The Stakeholder

The process-oriented stakeholder trusts the business processes and procedures.  These stakeholders want to make sure everything is being done the right way.  They believe that the business processes, procedures, and checklists are established for a reason and that reason is to reduce risk and help the business make wise decisions.  In fact, they believe that most mistakes and problems in the organization are because people did not follow the processes, procedures, and checklists.  And they have they have the examples to prove their point.  They want to know that the correct procedures are being followed.  And if the circumstances are outside of an existing procedure, they want a structured problem solving process to be used to deal with the situation and the documentation of the result to be used in the creation of a new procedure to address that issue if it ever comes up again.  They may come across as bureaucratic.     

Interaction Style

The key to interaction with this stakeholder will be to communicate through the correct channels for the type of information being presented.  If it is a budget report, stick to financial topics.  If it is a schedule status meeting, don’t get sidetracked into dealing with a personnel issue.  Use the correct forum, use the correct format, and address the correct topics.  The types of questions they will be asking are:
  • “What did you do first and why?  Then what? Then what?”
  • “Have you followed the correct process?  What was the result?”
  • “Have all the appropriate individuals/organizations been contact? What was their response?”
They would prefer to see the completed checklist or a step by step walk-through of the process and what happened at each step. 
They do not want to be rushed or pressured into making a decision.  They want to go through all the steps and they believe that by the end of the process the correct decision will be obvious to everyone and easy to make.  Generally speaking, they do not like argument, debate and controversy.

Key Messages

When discussing your project always explain what procedures and checklists have been completed or are in-process.  Be prepared to discuss the results or conclusions of the those procedures.  If a procedure is in-process, explain how much progress has been made and how long it will take to finish the procedure.  Then if the interaction is a decision point, be prepared to explain the options that are available and the criteria that should be used when selecting an option.  Be ready with the documentation of the results of every procedure, process or checklist that has been completed.

Good News and Bad News

For these individuals, bad news is an individual or team not following the standard procedures and good news is that, even though something catastrophic has happened, there was a procedure for that and it is being followed.  They will be very supportive if you have “played by the rules” and totally unsupportive if they believe the individual or team is “just winging it.”  If the situation is one for which there is no procedure, process, or checklist, pick one that is close and use it as a guiding framework.  Always have a plan.  Even if it is a plan to create a plan – have a plan.

Final Thoughts

If you are following the business processes and procedures, these individuals will be supportive, if you aren’t they will not trust any information or recommendations you provide.   I have had the privilege to work with several stakeholders who operated in this fashion.  By following the procedures; I found that I was quickly able to gain their trust and confidence and I could accurately predict how they would react to almost any situation.  By the same token, I have seen project managers fired during a meeting when they admitted that they had ignored a procedure.