Onboard the Stakeholder

Being on couple of projects of different complexities in last one year or so, and going through various tricky situations, it stuck me  that how less emphasis we give on a fact when a new stakeholder joins the project. Not to get into the definition of what a stakeholder is, reference here is towards a stakeholder who is also a customer.

Projects, which are small in nature, generally have a happy go lucky feeling much on the lines of having a small circle of friends or a tiny community of like minded people. Communication is easier in this small group as no. of stakeholders are less and so the chances of having varied expectations from a project or the people.

Life on a large project is quite different though. By the way, the problem in question here is not a problem of scale. But, it is something to do with complexity of client organization and various stakeholders in there at different levels. Various projects have seen pain, mainly for the reason that some new influential stakeholder has joined the project in some capacity and have a different idea about running the project for what so ever the reason may be. 

Various project management books and experts talks about doing stakeholder identification, need analysis and then continuous management. What doesn't come out very well is the fact that these stakeholders need proper attention in first bringing them on board with state of affairs on variety of things. There are bunch of things, which needs to be established from the outset. 

List of things to-do includes:

• Alignment on philosophy of two organizations i.e. customer and vendor
• Delivery Models
• Who is who
• Communication model in place
• Expectation Setting
• Setting up the path to fluid communication

Method of doing this on-boarding could differ but goal should be same i.e. to bring the stakeholder on the same page about state of affairs on the project. On the other hand, it could be a great opportunity for a project team to know of some concerns in advance and proactively manage them. My preference is to do one or multiple face-to-face discussion with the stakeholder in an appropriate setting. My preferred environment is to invite the person to the place where the project team works from. It simply builds perspective to the entire discussion.

There could be more to this list above but it may play a vital role in not only managing the stakeholder but also can define success or failure of a project.

Retrospectives

Go back to basics, look into dictionary, search and understand the definition first.

Wikipedia says Retrospective (from Latin retrospectare, “look back”), generally means to take a look back at events that already have taken place.

Software Project retrospective took the definition one level up and used it as a tool to look back, learn and move forward in the quest of improvement.

Well, hardly anyone can argue with the definition and the value this exercise brings but certainly not a bad idea to re-visit the fundamentals and may be, add up based on the experience gained over few years.

Doing retrospective on a usual retrospective -

A. Look Back – why it doesn’t work normally

1. Retros are most commonly an unplanned activity in a project cycle
2. It doesn’t happen on a regular basis
3. Planned for 1 hour went on for 2.30 hours
4. Couldn’t find a facilitator so the Project Manager became one
5. Some super hero hi-jacked the session and made sure that his opinions, problems and solutions are heard first
6. In the end, concluded that action items are for the management and the client and that’s the reason for all the problem in this world
7. Next retrospective – hardly anyone turned up

Most likely, above mentioned points are forming a pessimistic view but I have seen it happening quite frequently.

B. Learn – don’t do any of it mentioned above

C. Action Items

i) Discipline
a. Fix a day in the calendar, possibly every iteration on which retrospective sessions would be done
b. Ensure, session is happening. It’s as important as an IPM or showcase.
c. Don’t postpone the exercise unless life-critical situation unearths.

ii) Facilitation
a. Decide on a facilitator in advance, who is not part of your team and knows a way about facilitation. It’s not OK to have a facilitator from within the team whatever one argues for it. Reasons are plain and simple –

b. It’s just about the fact that you tend to ‘behave’ well when you have a third-party presence.

c. It’s also about the fact that you don’t want facilitator to let his own opinion overshadow others’.

d. Plus, you want your team members to participate in the exercise as s/he has also experienced pain and pleasure in the journey of the project and should express all of it in this session

e. Meet your facilitator in advance and explain the project, structure, and current status in brief in order for him to understand the discussions and proceedings well during the session.

iii) Express more, talk less
a. Power of 60 - Time-box activities, most importantly the talking part of it. No one speaks more than 60 seconds on a given topic. Ranting is okay but make it short.

b. Power of stickies – Use more post-its for participants to express themselves. When you write, you are most likely going to be short, concise and clear about your thoughts. No one interferes nor influences others as well.

c. Power of Parking Lot - If there is a topic, which demands more time, you need a separate meeting. Even if it is the most important item for the team, it can’t hijack the overall session.

d. Everyone speaks – Ensure that everyone gets the opportunity to express their opinion. Usually, silent ones in the team have more to offer in these sessions in terms of insight. Vocal ones most likely would have expressed themselves outside the session itself.

iv.) Action Items
a. Keep it local - Decide on action items, which are local in nature. Team members should be able to sign up on those items.

b. Around the Action in 7 days - Action items should be actionable in next 7 days. Though items actionable within iteration are a trend but it generally gets pushed into next. Shorter the better.

c. Do It Yourself (DIY) - Ideas, suggestions and action items for management and someone not present in the session should be kept aside and discussed in a different forum with all parties involved. You can’t decide on what an onsite team member would be doing even if it sounds appropriate. At most, you can talk to that person and if he agrees, it can become an action item but not in the session.

d. Actionable actions – Don’t be over-ambitious about changing the world in 7 days. Results & outcomes are motivating even if they are smaller in nature.

v) Follow-up
a. Publish – Communicate the retro notes immediately to the team and concerned parties

b. Retro cards - Create story/task cards on the story wall for the action items decided in the retro

c. Retro Cop – Let team members volunteer for the coveted position on a rotational way. This person is the iteration manager for the retro cards

d. Standup - It’s one of the topics participants have to talk much like their regular story cards.

e. 7th day – If you observe that action items are pending, it calls for a lunch-time short discussion or a huddle to understand if something can be done about it.

May be, we can derive some patterns out of it, but for some other time.
This has been my experience, what’s yours?

References-
Looking to know the basics of retrospective? : http://www.retrospectives.com