Embed Size (px)
DESCRIPTION
Convincing the organization to embrace a new IA is no small task. Effective communication with key project stakeholders is essential for winning—and keeping—their support in managing change. Cross-functional stakeholders typically present diverse and, sometimes, conflicting requirements that must be successfully reconciled. This presentation describes how the Mathworks Documentation Group engaged with various stakeholders across the organization to redesign and implement a new Help system over the past three years. Learn how our communication strategies and tactics helped us to build organizational consensus around requirements and structure design reviews to inspire support for the new IA across the organization.
Citation preview
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.
