best practices for communicating with key project stakeholders a case study

1

BEST PRACTICES FOR COMMUNICATING WITH KEY

PROJECT STAKEHOLDERSA Case Study

ENA ARELInformation ArchitectMathWorks

2

Overview

About MathWorks culture

Our project scope

Our stakeholders

Our communication best practices

Lessons learned

3

About MathWorks

MathWorks is the leading developer of mathematical computing software.

Engineers and scientists worldwide rely on its products to accelerate the pace of discovery, innovation, and development.

4

About MathWorks Culture

We cultivate an enjoyable, vibrant, participatory, and rational work environment that

• Nurtures individual growth, empowerment, and responsibility

• Encourages initiative and creativity

• Values teamwork (consensus building)

5

About Our Documentation Group

60 Content Developers

9 Editors

3 Toolsmiths

1 Information Architect

1 Program Manager

6

This is a story about what worked for us…

7

Effective communication with stakeholders is essential to innovation…

8

The Project: Help System Redesign

Respond to customer feedback

Reduce waste

Innovate and position us for the future(mobile, tablet, better integration with software,…)

9

“Let’s make our

documentation better!”

10

Project Challenges

80+ highly technical software products for engineers and scientists

Stakeholders at various levels of the organization with different priorities

Products have complex and sometimes unique documentation requirements

Complex tools chain, delivering documentation that is both on the Web (mobile, tablet, etc.) and tightly integrated with installed products

11

What We Did

Dramatic redesign of current Help system with significant impact on user experience

For example…

12

Transitioned to Browsing by Categories

Before

After

13

We Had Book-Based Navigation

Before

14

Transitioned to Browsing by Categories (continued)

Product landing page

Category page

Reference page

After

15

Forging a Stakeholder Strategy

#1 Who are the stakeholders?

#2 Stakeholder communication strategy

16

ICN Model Used at MathWorks:

Identify which Stakeholders are in Inform vs. Consult vs. Negotiate roles

17

1. Who Are the Stakeholders? (continued)

Organization Leadership Team

Product Teams & Writers Who Will

Adopt Design

Toolsmiths Who Will

Implement the Design

Customer-Facing Teams Who Will

Show Help to Customers

Our Customers

Negotiate position

Consult position

18

1. Who Are the Stakeholders? (continued)

When identifying Negotiate Stakeholders, consider: Who can assess the project against the overall

business needs of the company? Who will stop the new design from being built if they

don’t like it? Who can provide resources for the project?

When identifying Consult Stakeholders, consider: Who can provide additional and/or unique perspective

on the project? Who will be most impacted by the project?

19

Effective communication with project stakeholders is essential for winning — and keeping — their support in managing change…

20

2. Stakeholder Communication Strategy

1. Create a formal design review body consisting of Negotiate Stakeholders

2. Get input from Consult Stakeholders early and often

3. Get Negotiate Stakeholders to agree on – Customer and internal pains to address

– Design requirements

4. Keep Negotiate Stakeholders happy by– Validating their feedback (e.g., via email)

– Communicating how you addressed each feedback point (e.g., using Before/After mock ups)

– Providing clear rationale for each design decision(requirements, user feedback, implementation feasibility)

21

Even with a good strategy, effective communication tactics are necessary to get from prototyping to shipping…

22

8 Communication Best Practices

23

1. Recast design suggestions into requirements

Can you remove that Functions link from the product pages?

It sounds like you want to de-emphasize access to Functions…

Is it still a requirement for users to access Functions easily?

Let’s explore ways we can de-emphasize the link without completely removing it…

”“

24

2. Reconcile conflicting requirements

25

2. Reconcile conflicting requirements (continued)

Remove all navigation aids from left gutter! Keep it clean! ”“

We’d like the ToC for navigation!”“VERSUS

26

2. Reconcile conflicting requirements (continued)

27

2. Reconcile conflicting requirements (continued)

28

3. Carry design alternative up your sleeve

29

3. Carry design alternative up your sleeve (continued)

Bug Reports

30

3. Carry design alternative up your sleeve (continued)

Provide multiple designs for elements that are likely to be controversial

Design alternatives should meet the same requirements

Present each alternative as a user scenario

31

4. Build consensus offline, as much as possible

32

Ne-ma-wa’-shi (Japanese)

Technique for building consensus in the organization

From “The Toyota Way”

33

4. Build consensus offline, as much as possible (continued)

Nemawashi is an alternative to standard Western style meetings with debate and clashing positions

Goal: Airing points of potential conflict “pre-meeting”

Technique:– Present proposal one-on-one or to small groups

– Methodically cover all likely key influencers

– Iteratively hash out controversial points

– Present proposal to all Stakeholder after offline consensus has been reached

34

4. Build consensus offline, as much as possible (continued)

Questions to ask during Nemawashi encounters:

Do you completely hate the idea?

Do you like some parts and not others?

Do you have specific suggestions for improving it?

What do you think is needed to improve the chances that the idea will be accepted?

35

5. If someone else speaks up for the design, let them

36

6. If you can’t do it now, explore ways to do it later

Phase 1

Phase 2 Future…

37

7. There is a Truth in every piece of feedback

38

8. Take Stakeholder pulse regularly, and respond

39

8. Take Stakeholder pulse regularly, and respond (continued)

40

Summary of Our Best Practices

41

1. Recast design suggestions into requirements

2. Reconcile conflicting requirements

3. Carry design alternatives up your sleeve

4. Build consensus offline, as much as possible(Nemawashi)

5. If someone else speaks up for your design,let them

6. If you can’t do it now, explore ways to do it later

7. There is Truth in every piece of feedback

8. Take Stakeholder pulse regularly, and respondMat

hWor

ks B

est

Pra

ctic

es

42

You have succeeded when your Stakeholders and you feel like there are no surprises…

43

Main Lesson Learned

Stakeholders in “Consult” role need to feel like they are more involved in the design – especially the Content Developers!

We gathered input from Content Developers through Managers, which was not the best way to do it. Although we incorporated much of their feedback, the writers didn’t feel their contribution.

We should have gathered it directly from the Content Developer so that they felt how we were directly responding to their input.

44

Thank You!

Ena.Arel@mathworks.com