It’s a well-accepted practice that an intranet redesign project should begin with consultation of stakeholders across the business. Get it right and you pave the way to adoption and organizational efficiencies. Get it wrong and you join the ranks of intranet managers struggling to demonstrate value.
Before getting started, spend some time defining "aboutness"
An intranet can be many things to many people. Before embarking on a company-wide consultation process it’s worthwhile to work with a smaller intranet steering committee and, ideally, the project sponsor to define what the intranet means to you. Consider the areas where the greatest measurable impact can be made towards organizational goals. Are you trying to:
- Drive sales?
- Foster a positive work culture?
- Make a societal impact?
- Reduce time spent on projects?
- Reduce duplication of effort across geographies?
- Usher in a major change?
- Weather a competitive threat?
- Spark product innovation?
- Retain organizational knowledge?
- Increase the speed of new employee onboarding?
At this very early stage in the project, it’s easy get a little bit giddy. We want all of the things! It’s exciting to look at examples of what other companies have built to these ends and imagine how these solutions can be applied to all of the company’s dreams and shortcomings. But generally, we have found success likelier with a tighter focus.
This focus, once achieved, will help guide the selection of stakeholders. Having an approximate sense of where you are headed – even if it changes or evolves as you proceed with your consultations – can lead to clearer, more measurable outcomes upon conclusion of the project.
Selecting who to consult
Begin by assessing which groups will be most significantly affected by the introduction of the new tools and content. A recent org chart is helpful in ensuring no major groups are left out. Be sure to include anyone with enough interest and clout to derail the project as it unrolls. Consider:
- Executive stakeholders
- Managerial and non-managerial representatives from business units
- Additional segments worthy of special consideration:
- New employees
- Geographically dispersed employees
- Office workers
- Field workers
Most of the above groups would be considered users or consumers of the intranet. It is also worth understanding the needs and views of heavy publishers of intranet content such as Communications, the Help Desk or Human Resources.
For an intranet, we try to define groups that have a shared sense of purpose and context. Ideally, each group contains approximately 6-8 participants. Include too many people and the conversation becomes difficult to facilitate; include too few and you run the risk of overemphasizing the needs of particular individuals. The number of stakeholder groups we choose to consult depends somewhat on the definition of the project. For approximation-sake: a complete intranet redesign intended for a company of 1000 employees might encompass 15-20 group sessions with upwards of 100 stakeholders across the company.
Executive consultations are best undertaken one-on-one. The focus of these discussions is generally more strategic.
Setting the length of the consultation
We’ve found the ideal length of a session ranges from 45 minutes to an hour. This provides enough time to spend:
- 5 minutes introducing the project, discussing associated goals and getting comfortable with the facilitator and the environment
- 5 minutes outlining the brainstorming or interview approach
- 20-30 minutes brainstorming
- 10-15 minutes prioritizing
- 5 minutes wrapping up, communicating next steps in the intranet design proces
Deciding on format: Interviews versus other requirements solicitation techniques
As part of the stakeholder consultation process, you’ll want to emerge with answers to key questions. Questions will obviously vary based on the nature of the group you are engaging; but at a high-level, some sample intranet stakeholder interview questions might include:
What is the nature of the group being interviewed?
- How large is the group they represent?
- What job (or jobs) do they perform on a day-to-day basis?
- Where do they perform these jobs?
- How do they perform these jobs? Are the activities that encompass the job largely made up of individual processes? Team processes?
- How do you communicate and collaborate with your peers?
- What proportion of day-to-day activities are routine vs. custom, high-touch or experimental?
- What tools are instrumental in helping to perform these jobs?
- What is the comfort-level or access-level of the group being interviewed with web-based or social technologies?
- When support for day-to-day work is needed, how is help sought?
What are the objectives driving this group?
- How are objectives currently communicated?
- How are they currently accomplishing these objectives?
- Is there a timeframe identified for fulfilling objectives?
- Is there compensation tied to fulfilling objectives?
- What barriers exist to fulfilling objectives?
- How do the group’s objectives figure in to the broader organizational context?
- What tools are available for gauging progress towards stated goals?
How does the group use the intranet today and intend to use it in the future?
- How does the current intranet support their needs?
- How should it support their needs in the future?
- Are there processes that could or should be facilitated by the intranet?
- How urgently is intranet support needed for day-to-day work?
Who is the audience the group serves? (This could be an internal audience or an external customer)
- Are there ways that the intranet can facilitate better service to this audience?
What are the types of content most-often used by this group?
- What type of information is referenced when completing a job?
- Are there rules around how content should be managed?
- Where is this content stored?
- How is information catalogued and retrieved?
- How often is it retrieved and used after it has been stored?
- What is the typical shelf-life of information produced by this group?
- Is there a process for retiring outdated information?
Speaking from experience, attempting to ask these questions directly of large group can result in unbalanced conversation. Some participants may be uncomfortable, shy, busy or disinterested and spend the whole time fiddling with their cell phone; while others might monopolize the conversation. An interview also runs the risk of conversation dwelling too long on one particular requirement.
We have found better success with activities designed to engage the whole group. Depending on the goals of the interview and the stage of the project, I might use a variety of techniques to tease out or directly observe answers (and reveal questions that we may not have even considered). At this stage, I might consider:
- User story writing – requirements written in everyday language are rapidly jotted down on index cards then sorted and prioritized.
- Participatory design – participants co-create solutions on paper (a combination of collage and drawing.) As participant groups explain their designs, the facilitator listens carefully and probes for emergent requirements.
- Contextual inquiry – work activities are observed in-context, providing the researcher/facilitator with a real-world sense of day-to-day life and how software might fit into it.
We won’t get into the details of how to run a session using these techniques. However, with the first two techniques, the idea is to keep the session energetic and enjoyable. For all three, it’s important that the facilitator be well prepared. Ideally the facilitator should have a very firm grasp of the questions above – even if the answers are not necessarily derived through direct lines of questioning.
Invitations and preparations
When inviting people to participate in an intranet stakeholder interview it’s important to provide a light overview of the project, its goals and why it’s important that their voice is heard. Plan to book the interviews several weeks in advance since finding time in busy managerial and executive schedules can prove challenging.
To prepare for upcoming sessions you should consider assembling the following materials:
User story writing
- Several packs of index cards – a single user story writing session can easily use up hundreds of cards
- Lots of rubber bands – I carry a big ball of rubber bands to sessions with me. This way, I can easily keep track of grouped and sorted requirements
- Post-it notes – not only are these helpful for idea generation and prioritization sessions, they also make great labels for grouped sets of index cards
- Lots of pens and sharpies
- Recording device – a Livescribe pen is a fantastic investment if you plan on running a lot of sessions. It creates a digital audio recording that is synchronized with hand-written notes. Once the session is complete, the notes themselves and accompanying audio can be transferred to your desktop. Through OCR-technologies, the hand-written notes become searchable. The nice thing with this is that you can revisit not just your notes, but the actual conversations that accompanied them throughout the course of the project
- Snacks – candies or other snacks help put the group at ease and create an almost festive, relaxing environment for talk
- Premade printed artifacts – to assist the design process, we tend to prepare a set of elements that can be cut and pasted onto a piece of paper to mock up a potential solution. When planning an intranet for one client on a tight budget, we showed up equipped with several printed SharePoint web part stencils. The team discussing the intranet was not terribly familiar with the tools available at their disposal, so making use of these printed assets allowed them to assemble a solution that both suited their needs and required minimal customization
- Large sheets of paper – we tend to use 11 x 17 sheets
- Pens and sharpies – these can be used to draw elements on the page (when the premade printed artifacts just don’t do the job)
- Glue sticks or mounting putty – mounting putty is nice because people can reposition elements on the page
- Post-it notes – these can be used to illustrate or describe individual features. Post-its can be moved around the page
- Recording device – in this case, we tend to prefer using a video camera hooked up to a laptop running usability software, Morae. The video can then be bookmarked at key junctures for use throughout the project. Video excerpts can also be easily created; helping to educate project stakeholders and justify design decisions down the road. If desired, the full intranet team can observe and discuss the sessions in real-time using Morae’s networking capabilities
- Recording device – not much is needed for contextual inquiry, as the researcher is more of an observer as opposed to an active facilitator. Again, the Livescribe pen is somewhat useful in this situation
Deciding who should lead and who should be a fly-on-the-wall
It pays to have an unbiased, experienced facilitator conduct the interviews. A good facilitator is adept at ensuring that everyone feels comfortable voicing their opinions and keeping the conversation moving. An “outsider” can be valuable in this role in that they will not run the risk of taking offense if criticisms arise around how things are currently done. The facilitator should be an expert at translating the discussion into requirements for review of the intranet steering committee. For activities like participatory design, a second facilitator may be useful to capture insights from group work.
It is also useful for members of the internal project team to sit in on the sessions – ideally as a silent observers. Anyone who plans to have a key decision-making role throughout the project should be present as they will ultimately be representing the needs of users across the company.
Closing the loop and validating assumptions
So many of the first and second generation intranets that we are called in to replace were never designed with the input of end users. And while it’s a major step forward to use the input gathered through these early stakeholder interviews to shape design efforts, it’s risky to treat them entirely as gospel. Reviewing and revisiting assumptions through usability testing at various stages in the project as well as closely monitoring surveys and analytics post-launch can help iron out areas where requirements may have been misunderstood, missed or wrongly prioritized.