In my last article, I extolled the virtues of using a team website to keep everyone on your team in the loop. But exactly what information should be kept on a team website? What’s critical and what’s just “nice to have”? These are the topics of today’s post.
What’s It All About? There are dozens of useful things to consider putting on a team website. No two sites will end up sharing exactly the same information, but there are a few elements that should be on any site that’s meant to communicate with stakeholders about a big change.
Must Haves: Here are a few essential categories of team info that I typically include when building a website for a team:
1. Latest News: Use the home page to keep your stakeholders informed of breaking news from the project. It’s especially important to make it very easy for them to find information that impacts their expectations – like announcement of training date or changes to scope or features. Update the home page with fresh news at least every few weeks so stakeholders get into the habit of returning.
2. Project Foundations: Include information about why the change is being undertaken. I usually list out the goals and objectives that were agreed to during the alignment phase of planning for the change. In some cases we update the team’s progress toward realizing these goals by posting metrics. It can be very useful to have a brief, focused description of the rationale for your change handy when you introduce thousands of new stakeholders to your change in a short time. Having a page dedicated to the foundations usually addresses that need for instant immersion quite well.
3. Schedule: This one is fairly self-explanatory. Keep everyone aware of the expected dates for events – especially those events that require stakeholder action; such as training, opportunities for stakeholders to offer feedback and dates when the old way of doing things will no longer be available.
4. Training: Speaking of training, I found that no topic gets stakeholders more interested in your change and the time-line for that impact than making specific training available. On this page, make sure to be as specific as you can be as early as you can. If you have a detailed curriculum planned – share it. If the training varies by the different roles that people play in your company’s business processes, be clear about that. Most of all, it is critical to let them know of learning opportunities far enough in advance that stakeholders can plan to attend.
5. Communications Archive: Most people will not visit your team web page daily and some will not visit until late in the project (around the time that they need to get ready for the change to become permanent). I usually encourage the project sponsors to send an occasional email to stakeholders reminding them to visit the site to keep up to date, but invariably people get busy and the communication isn’t received. So I usually build a single archive page where I store all of the official communications that have gone out in reverse chronological order, so stakeholders can easily catch up on what they missed.
6. FAQ’s: I wrote a series of posts a few weeks ago about this topic, so I won’t get into the details here, but ALL projects should anticipate the most common questions that their stakeholders would have and draft brief answers to them ahead of time. This can save a lot of last-minute calls and emails from panicked stakeholders who just want to know the basics…
7. Feedback / Contact Points: Finally, it is essential that people know where to go for help with your change. This page can have email links to the project team, to key individuals or to your help desk/support function. It can also include phone numbers to call if someone just wants to learn more about the project or the change. In each case make sure to anticipate the way your team will want the flow of resolutions to operate as you build this page. (for example: all security/log-in questions should be directed to the help desk, all training questions to Barb or Betty, all functional questions to someone else, etc.)
Not Required – But Useful: Here are a few more elements to consider including on your team’s website. These items are probably not as critical as those listed above, but each one can help to improve your communication with stakeholders and reduce the amount of resistance you’ll experience when you pull the trigger on your big change:
– Terminology/Buzzwords: list all those acronyms and new terms with brief definitions. I have found this very helpful for changes that involve new technology or significant changes to people’s work processes.
– Benefits of the Change: Describe the up-side in terms that make sense to stakeholders (Hint: don’t just cut and paste in the buzzword-laden gibberish from your business case!)
– Meet the Team: In the past I have built sites that show pictures and brief biographical sketches of the key people on the project. This can be a great way to introduce folks – especially if you plan to do web-based seminars or site visits.
– Team Events: I often help teams do small milestone celebrations or recognition events as a part of team-building. (Sadly there is a false impression out there that team recognition is not needed or is too expensive these days with budget crunches, but that’s another post for another day…) In any case, it can be fun to post pictures for other record of these positive events on the team site.
An Effective and Efficient Communication Tool: A team website can be a great tool to share information within your team – and more importantly with your stakeholders. It can give the company a clear focal point for communications that is available whenever someone has a question. I highly recommend it as a way to save you and your people countless hours of questions and avoid stakeholder confusion.
Questions for Chatter:
- What else have you seen as useful to share on a team website?
- How can you limit the amount of effort it takes to keep the site up-to-date without losing its effectiveness?