# Presentation: YB5XBOGNR7BS63S233MDJCJNNR6ZIVJ5

## 
July 7, 2005

Presented by: Ella Page
Software Process Improvement (SPI) Project

**July 7, 2005**
**Presented by: Ella Page**
***Software Process Improvement (SPI) Project***

**Hints for Stakeholder Coordination**

##   Purpose and Objectives

**Purpose: Review the overall approach to planning, monitoring and controlling stakeholder coordination throughout your project**
**Objective -  After this session you should know:**
**Who your stakeholders may be**
**How to plan for stakeholder coordination**
**Approaches to monitoring and controlling stakeholder coordination**
**The kind of records to keep for stakeholder coordination**
**Some pitfalls associated with stakeholder coordination**

***For CMMI Maturity Level 2 stakeholder involvement in key activities must be planned, monitored, and controlled.***

##       What Is A Stakeholder?

**Dictionary definition**
**One who has an interest or share in a commercial undertaking **
**CMMI definition**
**Stakeholder: Those affected by or accountable for the outcome of your project.**
**Relevant stakeholder: a stakeholder that is identified for involvement in specified activities and is included in an appropriate plan **
**. **

***View your relevant stakeholders as those who influence, or are influenced by, some aspect of the project.***

## How Do You Keep Stakeholders Involved? 

**Notes:**

Managing expectations is something we all do every day. 
Sometimes we do it well, and if we don’t, the consequences are not usually pleasant. 
The stakeholder is surprised, unhappy, and can’t be convinced that it’s not ALL your fault. 
Besides, you were the one who set their expectations in the first place. One way to do it is through coordination with the stakeholders.
Four of the tasks are done during the planning. The other three are done during project execution.

## Identify the Stakeholders 

**Look for relevant stakeholders who are**
**Users of outputs from the project**
**Suppliers of inputs to the project**
**Performers of activities within the project processes**
**Relevant external stakeholders may include**
**Suppliers (contractors, vendors)**
**Mission Project and interfacing subsystems**
**End Users and Operations Staff**
**Relevant internal stakeholders may include **
**Software project members (testers, developers, etc.)**
**Your management**

**Notes:**
Suppliers – of data, of SW, of HW, and of course, of MONEY
Users are stakeholders – they certainly have a stake in how the project comes ends up.
But stakeholders come in all flavors. NOT just the customer, end users, or people with the money.
You need to look internally for your relevant stakeholders as well. The people on your project are stakeholders. The important job for you is to identify the relevant stakeholders.
	Development Manager
	Test Manager
	Key Engineer
Think about how your project is organized and focus on the key project positions to get to the RELEVANT stakeholders.
Examples might include the following:
	Go over slide
So once you know who the relevant stakeholders are, you can move on to the next task ... 

##   Talk to the Stakeholders 

**Talk with stakeholders early in planning**
**Find out what the stakeholder needs from you**
**Discuss what you need from the stakeholder **
**Find out ...**
**How much time they can provide **
**What areas they need to be involved in**
**What their priorities are **
**What their preferred coordination approach is**
**If the approach and time available will be adequate for your needs**
**Negotiate for what you need **

**Notes:**
When you involve the stakeholders in the communication planning process, it ensures 
that you deliver the information in the right format 
that you deliver the information at the right time 
and that they have committed to pay attention to what they are given
Project managers may deliver too much, or too little for a particular stakeholder and the stakeholder delays looking at it until they can secure what they need.
You need to come to agreement on the ground rules of how the communication will work up front so everybody gets what they need and expect.
Ask project stakeholders the key questions about when, how, why and what they want to know about the project progress. 
This can be done in a phone call or in a meeting; one-on-one, or with a group of related stakeholders.
Listen to their answers and look for ways to get what you need while giving them what they need.
Document what you hear.
Negotiate for what you need. 

##  Define the Coordination Approach 

**Identify ways to keep each stakeholder involved, such as**
**Meetings and telecons, with minutes (*****yours or theirs*****)**
**Internal project process meetings, including a Project Orientation Meeting to review project processes**
**Formal or informal reviews**
**Documentation review**
**Status Reports and Action Item lists**
**Email messages, Briefing Messages, letters, or memos**
**Map stakeholders to the defined approaches and identify artifacts to be collected**
**May need different artifacts for different stakeholders**
**Use existing artifacts (e.g., meeting attendance by “expected attendees” or roles)**
**Assess any risks associated with insufficient or excessive stakeholder involvement**
**Document the coordination approach in SMP/PP for Class B/C, Section 3.3.4**

**Notes:**
You can think of the coordination approach as a communication plan. There are many ways of coordinating or communicating with stakeholders. 
Here are a few in this list.
You need to think about the answers you got from each stakeholder as you put this plan together.
Maybe a stakeholder providing you with a piece of software doesn’t want to come to your weekly status meeting. Then perhaps you can send someone to his status meetings, or maybe you can ask to have status reports delivered to you.
Include the stakeholder only when one or the other of you really needs to exchange information ... like if you’re discussing software requirements, schedule constraints, etc.
Try to avoid the “Too much information” syndrome.
If you go through the list of relevant stakeholders and identify all the ways you’d like to communicate, you can then begin to map stakeholders to those you think will be effective. 
Tweak the list to get to a minimized list that still meets everyone’s needs. 
Try to have at least 2 ways of communicating with each stakeholder
Ask you go through this process, think about anyplace you have a real risk to the project if the coordination doesn’t work.
Emphasize coordination in these cases. Consider adding these cases to your list of project risks.
Document your proposed approach in the SMP/PP
Section 3.12 for the Class B/C template 

## Stakeholder Coordination – 	SMP/PP Documentation

**Purpose and rationale for stakeholder’s involvement**
**Importance to the project**
**Authority and responsibility of the external stakeholder **
**Responsibility on both sides of an interface, such as**
**Flight software to the flight hardware for working compatibility issues**
**Ground Data System to the Flight Operations Team for acceptance of the system**
**PDL to line management**
**PDT to Safety and Mission Assurance, IV&V, and ITA**
**How stakeholder involvement will be monitored and documented (e.g., by publishing expected attendees at reviews/walkthroughs and recording attendance)**
**Other project effort or materials needed to ensure the stakeholder involvement (e.g. briefings to stakeholders, walkthroughs, hardcopies of review materials) **

**Notes:**
Use a matrix to document stakeholders , when you coordinate with them, and how. Check the matrix to remind you about stakeholders that are really important for any given activity.
It’s also important to start out recognizing when you need to get stakeholders involved and what kind of information or records should be kept. 
While it might take some time to create the very first time you use it, a matrix that identifies all of the life cycle or process events that need stakeholder involvement will be very useful to you.
This matrix can be used from project to project with minor tailoring to add, delete, or modify events, artifacts, and stakeholders.
There is a sample matrix in the SMP/PP template.
Another help might be to look at the FSW matrix, which shows which stakeholders are involved in each process area and what their involvement is. 

## Stakeholder Coordination – 	SMP/PP Template Example

## Stakeholder Coordination – 	FSW Template Example

**Stakeholder Coordination ****–**** ****	****FSW Template Example**

## Get Stakeholder Agreement

**Get appropriate stakeholders to review documented plans**
**Get stakeholder agreement on coordination plan**
**Address stakeholder comments and record approvals**
**Negotiate and iterate until stakeholders have approved and committed to the required coordination**

**Notes:**
Once you have the plan documented, you still need to get agreement from the stakeholders that what you’ve planned is acceptable to them.
You can send selected pieces of the documented plan to each stakeholder and record their response using email.
For selected or key stakeholders, you can have them actually review the coordination plan. 
Get their comments in written form if possible. If they only give you a verbal response over the phone or in meeting, send them an email that notes each comment and your response.
You need to address any stakeholder comments on the coordination plan, because if they aren’t happy with it, it probably won’t work.
Getting agreement won’t always happen easily. Stakeholders won’t always agree with what you’d like to do or have, so you have to be prepared to negotiate with them.
As you try to finalize the approach try less to sell them on your ideas and more to hear what they’re looking for.
Then try to find a solution that satisfies both sides.
Update the documentation as you reach final agreements.
Once you’ve gotten agreement from each stakeholder, get something in writing ... a form, an email, a memo, a document sign-off sheet, etc. 

## Monitor Stakeholder Coordination

**Identify records for stakeholder coordination, such as**
**Meeting attendance and minutes**
**Review attendance and minutes**
**Documented review comments or signed review sheet**
**Status report distribution lists**
**Action item status**
**Emails and Briefing Messages cataloged by stakeholder group**
**Collect and store stakeholder coordination artifacts**
**Use artifacts to assess coordination relative to your plan and to evaluate risk**

**Notes:**
If you’ve completed the coordination matrices, this part should be easy.
You’ve documented what the coordination should be and what artifacts you need to keep.
Just follow your plan and collect the good stuff according to the plan.
I’ve already talked about the artifacts associated with stakeholder coordination. Some are in this list.
It’s important to remember that the reason for the artifacts is to provide current information and historical data on how the project is doing. 
Without that data it’ll be hard for you to monitor what’s really happening. 

## Control Stakeholder Coordination

**Assess effectiveness of coordination**
**Verify that information sharing is happening**
**Verify that agreements are being reached**
**Verify that commitments are being honored**
**Take corrective action where coordination is not adequate**
**Talk to stakeholders to determine the problem cause**
**Modify approaches to improve coordination**
**Take stakeholder coordination into your hands with regular communication**
**Escalate real problem areas to management**
**Report coordination status to management with other status**

**Notes:**
And as you monitor, you sometimes find that you need to use the “control” function of management to adjust some deviation from the planned performance.
If the coordination is working, you might find out that a stakeholder will be late with information or a delivery, or that the process of coming to agreement on an interface is not going well. Those problems you work elsewhere.
But if the coordination isn’t working, you need to find out quickly and fix the problem ...
Because coordination is critical to getting everything else working.
For example, the coordination data may tell you that information sharing isn’t happening as planned.
You may find that agreements about things like requirements or interfaces aren’t clear and that two sides are working toward different solutions.
You might find that coordination commitments aren’t being kept ... people aren’t attending the meetings, or they aren’t reviewing documents, or they aren’t doing whatever they agreed to do with respect to coordination.
These are signs that the stakeholder coordination – the crucial communication with stakeholders – isn’t working properly. This you need to fix.
You can take corrective actions like these listed ... discuss the slide
But is all else fails, you need to escalate the unsolvable problems to management.
And don’t forget to report on the coordination effort status to management as well. 

## Keep Stakeholder Records

**Products of stakeholder coordination that should be kept in the project data stores:**
**Stakeholder plan in SMP/PP**
**List of stakeholders**
**Stakeholder matrix with coordination approaches**
**List of planned stakeholder coordination artifacts**
**Key commitments (emails, sign-offs)**
**Stakeholder monitoring artifacts collected, such as**
**Minutes from stakeholder agreement meetings**
**Review comments and approvals**
**Formal/informal review presentations/minutes/attendees**
**Training presentations/attendees**
**Stakeholder coordination analyses**
**Stakeholder coordination status reports**

**Notes:**
And the final task is to make sure that you keep all of those records artifacts and any metric data stored away in an organized fashion.
So what kind of stuff do you need to keep?
Here’s a list of the kinds of things that might be important. 
Remember, what you need to keep will be defined in you coordination plan.
I know that we frequently have to best of intentions about keeping all this stuff, but when things get really busy, we wind up losing the email, or the attendance sheet, or the minutes.
One thing that’s always helped me is to define up front where each kind of “thing” is supposed to be kept. 
An easy way to do this is to create a list of the things you’re going to collect and put the storage location next to it. Then post the list and make sure everybody on the project has a copy. 
Emails can be placed into “email folders” by stakeholder or by meeting, or however you decide to organize them. 
Maybe minutes are kept by the CM officer stapled to the original attendance lists. Think about what you need to keep and where you’re going to keep it at the start of the project and you’ll have an easier time of staying organized as the project progresses.
And another advantage ... when they decide to do a CMMI appraisal on you project you can impress them with how organized your project is and how easy it is to find those assets.

## Watch Out for the Pitfalls

**Not including important stakeholders**
**Having too many different meetings or reviews to cover the stakeholders**
**Not using existing artifacts to track coordination**
**Not following up on commitments to or from stakeholders**
**Stakeholders who are focused on other things and too busy for your project**
**The fine line between pushing coordination and becoming a pest**

## How Do You Work With Stakeholders?

**Assume you’re involved in a software development project for a specific Mission. **
**Who are your stakeholders likely to be?**
**What are some of the ways you would coordinate with these stakeholders?**
**How would you track the coordination?**

## Summary

**Know who all of your stakeholders are**
**Get their support and participation early**
**Define and document your coordination process**
**Plan for stakeholder coordination artifact collection and analysis **
**Get stakeholder approval of the coordination plan and commitments for participation**
**Track the stakeholder coordination**
**Make sure the stakeholder coordination is effective**

***And remember ... you, too, are somebody’s stakeholder, so be responsive***

## Questions?

## July 7, 2005 – Using the website http://software.gsfc.nasa.gov/

***July 7, 2005 – Using the website ******http://software.gsfc.nasa.gov/***

**Click asset name to get asset PDF**

**Click “?” to get feedback form**

**Click icons for desired files**

**Use search function to find assets**

**Use approved process assets**

**Find tools**

**Get measurement info**

**See lessons learned**

**Locate training and experts**

**See Engineering process group (EPG) Contacts**

## Accessing Presentation Slides From the Website

**Access SW Engineering Discussion schedule:**
***(http://software.gsfc.nasa.gov/swengdisc.cfm)***

**Access slides from past SW Engineering Discussions:**
***(http://software.gsfc.nasa.gov/swengdisc.cfm)***

**For SW Engineering Discussions ...**
**   ****Click “Training” and highlight **
**   “*****S/W Eng. Discussions*****”**

**Access slides from multiple NASA centers**

**For Other On-Line Slides...**
**   ****Click “Training” and highlight **
**   “*****Training Program*****”**