Managing Stakeholder Input

Facilitated by Arthur Coddington and Susan Nesbitt, Craigslist Foundation

How do we ensure stakeholders are heard while keeping the project focused and moving forward. What happens in small organizations when the Board of Directors takes an active role in a project? What do we do when channels of communication break down and stakeholder input bypasses established filters? What are the best approaches to managing inconsistent communications from multiple stakeholders?

Session Notes

introductions: -> good mix of big and small organizations

Open session to discuss the ins and outs of managing stakeholders.

At one org, there are small working groups made up of stakeholders (e.g. directors). In the last couple of weeks working on design directions. The prototype has been built and ideas shared but the feedback was too focused on the detail and not on the overall vision of the site. Through basecamp a lot of the reviewing was done. An image was uploaded to basecamp of the prototype but it went to basecamp and before the feedback was filtered one of the stakeholders saw it and gave very unfiltered feedback. The feedback was fine but not the right context and it derailed the process. All of the feedback was on basecamp in the open but in this situation it opened the org up for minutiae criticism - there was a lot of damage control put into gear. How do you define 'rules of engagement? How do you time the entry into the public sphere.

The new approach is to reiterate the rules of engagement.

Point :

1. how do you differentiate internal discussions and open discussion recognising there is a power imbalance. 100% communication is not perfect communication. Everyone communicating equally is not always the right way to communicate effectively.
2. what capital do people have? what is their investment? What is their stake in the communication?

Product Manager : when I speak to the board I have to think about the brand. So that grand visions are tied to practical user expectations. How can we act on things marrying the '100,000 ft' perspective with the practical perspective.

Point :

1. how to manage visionaries that also fund the project is tough. How to manage the up and down discourse? You need to let the big boss get the ideas out but filter the up currents. Most of the interaction is face to face but managed on a regular formal basis. Always have something going that the visionary boss can stay focused on while other operations go about the required operations.
2. another approach was to find someone to be the caretaker for the visionary and manage them directly. This role would rotate. 'keep them busy!'

Susan : so how would you decide on who has access to an shared knowledge base? What tools are there? How much transparency do you offer?

Points:

1. we use trac with tickets and milestones. But we also have a wiki which is used for client liaison. So the clients can see the filters trac-wiki reports on closed tickets but don't see the tickets themselves. We garden the wiki page as an access point. They can see everything but they mostly stay on the wiki. We also have a client mailing list and dev client list etc. Daily mailouts go to the client(s). The client friendly view of the project is via the wiki and the client actually mails tickets.

Susan : How about Users?

1. looking at the tracker apps (get satisfaction, lighthouse, trac, jira) for scraping user forums and linking to tickets.
2. we use 'uservoice' which is a direct mechanism for voting user functions etc. But its expensive.
3. jira considered to be the best tracker by some. Built by Confluence people. All the implementers on the ground use this. Force all feedback to go through Jira and some of this gets floated into the dev discussions.
4. Trac also has some cool plugins
5. we have a support mailing list and manage this - each week a different person is on call to manage this...one person was managing but it soon got distributed. its important to manage the communication of what is being done and someone needs to take charge of appointing the tasks and someone to take the job on. Follow up is important. if you are on call to manage this then u are the person that needs to take on the responsibility for dishing out jobs. this management role rotates weekly. internal transparency is necessary.
6. we had a double layered strategy. one strategy for developers. for staged development there was a bug tracker. giving the bug reporter a visible system is necessary so they see that the bug reports and the status. the user can then see that something is happening. putting milestones on those bugs is important.

new thread : transparency vs non-transparency....there has to be internal discussion and getting everyone on board and then transmit this to the bigger audience. Almost always there is not clearly defined decision making bodies. How is this delineated?

points :

1. it can lead to political conflict if the borders are not well defined. contracting with the stakeholders'. Use a clear document to define the roles internally. this should then be transmitted outwards.
2. transparency without structure is beautiful when it works
3. burning man : anarchy org. organised chaos. its extremely organised at its core and the roles are very well defined. 'concensus and hierarchies is the name of a doc written by the founder and it covers this ground. the board is running the company. its a company not a not for profit. operational staff make the operational decisions. project groups are well defined. chaos gets its space in specific areas. the top - down communication is alot about saying who is making the decision and defining this. then input is taken but people know when they do not have a say and when they do have a say.
4. how do you contract with your board to define their role? at a certain point the boards depth of control should finish. the board can then comment on this level but not control it and then if the board doesn't like the answers they can always fire the manager (eek!).

Susan : prep and consensus before a board meeting is important. meet internally before going to the board - build a united front. one of the board members that comes to this meeting and they get informed and fired up before the board meeting.

point :

1. it gives you the opportunity to get the board on board (harhar)
2. the critical point is that the board do have one of the board involved in the process of informing the board
3. need that united front to the board

Thread : but what if the stakeholder is ALWAYS in the office?

1. team members can get very frustrated by this, take people off-site and debrief them
2. you GOTTA draw the lines - draw this and show how it works now and how it does not work
3. talk to the stakeholder and say you need to delineate and that they should not be getting all the info out of operational necessity and efficiency
4. get the stakeholder out of the middle of things
5. if people care about the org you have to find a way for them to realise this is not the way to run - its not in the best interests of the org
6. if they don't see the process as being dysfunctional then put in place some reviews to measure the effectiveness of the process
7. can you give the stakeholder something more interesting for them to do?
8. manage their interaction time
9. consider getting out if it doesn't work

Theme : founder syndrome

points :

1. founders holding on to their baby
2. a founder should consider 'only how to win'. first priority id to the mission not planning how to exit or hold onto the foundation until the game is won.
3. must be able to direct peoples passion so that the community gets heard and ideas actioned
4. founders can potentially retire to a cushy job (evangelist)
5. building from zero and managing a successful org are different skill sets...how to manage the transition?
6. serial entrepreneurs are maybe easy to manage on this regard if they go off to another project
7. because founders had to all at the beginning they think they are good at everything which is not always the case. founders need to be open to realising that at a point their skill sets are not a match for all operations
8. founders can upgrade skills or get people on board to do the job. somewhere however there has to be honesty to realise this transition is necessary
9. open ones world to external stakeholders can keen a founder in balance between their perception of their own skills and what they are actually
10. functional reports is also necessary so founders see their successes and failures

theme : feedback from stakeholders

1. you will get more feedback on something that exists than on conjecture
2. build prototypes and ask for feedback