Honestly, I hope this post is way out of date, in the sense that everyone knows how to start and manage a Discussion Board or Forum. But just in case, let me share my experiences as a warning!
Several years ago we implemented Blog/Forum functionality on the intranet. This was the first set of “democratic tools” available, long even before the terms “user-generated content” and “social media” were glitters in a marketeer’s or communicator’s eye. From the start we had a few successful examples: there was a place where sales people could discuss competitor’s activities at their customers, we had one for questions and suggestions about the intranet, and we successfully ”crowdsourced” our Mission Statement and Company Values.
You can imagine we were very thrilled to receive another request from the CEO’s desk, this time to help with collecting tips for cost reductions (and revenue increases) throughout the company. A global topic, of high relevance, and endorsed by the CEO; of course this was a wonderful opportunity to promote our functionality again. We worked with Communications to set it up in the desired form, trained them in managing and moderating, and created a nice place on the homepage to feature it.
The first few weeks saw lots of activities. People liked the topic and had many interesting ways to save money or to increase sales, whether it was by selecting cheaper flight routes when travelling, installing motion-activated office lighting to reduce energy costs, or preferring our customers’ restaurants for business and private dinners. There were also good discussions about other topics, like pros and cons of open source software. All in all, this forum was a great success!
Until two things happened.
First of all, there was no reaction from the CEO or anyone from Communications to the suggestions. Nobody was expecting exorbitant praise or prizes, but we had expected that some suggestions would be featured in news stories, promoted to the entire company as a good practice, or even made into new internal procedures. When we asked Communications if they needed a PMO Team Site for follow-up of the most promising suggestions, it turned out that any evaluation or follow-up of the suggestions was not part of the plan. When, after a few weeks, people started realizing nobody did anything with their suggestions, the enthusiasm appeared to decrease.
But the real Forum Killer was a remark from an employee in Europe who was losing his job as part of an outsourcing project. He questioned the motivation and cost effectiveness of outsourcing his role, and made a few vicious, but funny, remarks about the CEO. What no policy or corporate news item has ever achieved, happened now: the remark spread like wildfire and by the time our American colleagues came into the office, everyone in Europe had read it.
You would think this would be a good opportunity for the CEO to show compassion with the employee, and to explain the company strategy once more.
Even no reaction would have been understandable, since everyone understood that this employee wanted to vent his frustration at being made redundant, and that he overstepped the boundaries of responsible behaviour.
But nobody understood why the vicious remarks were removed from the comment (leaving some asterisks instead) without any further comments.
From that day, the Forum fell silent. Even a new discussion started by the CEO generated no more comments.
Are you in charge of, or advising someone with a Forum? Then these may be some suggestions:
- Communicate a clear and transparent process about the Forum. What is the purpose of the Forum? What are you going to do with the generated content? How is the content being moderated? How fast can people expect a reaction (if relevant)?
If you are not going to take action, or want to leave any actions to individuals, make it clear as well! - If you want to use the discussion as input for a programme, make sure you publish about it regularly. Keep the ideas coming by showing that they can make a difference.
- See all remarks as opportunities for dialogue. I have seen Forums at other companies where people expressed their concerns for their jobs, and where management reacted promptly with a compassionate message showing they fully understood the problems of job insecurity.
- Inform people about any appropriate behavioural guidelines, e.g. your Employee Guidelines, Business Practices or Internal Social Media Policy. Also, make it known how you will treat inappropriate comments. (Please note that most in-company Forums, which are generally not anonymous, rarely have inappropriate remarks)
- Read more about moderating forums and other online media by Alex Manchester of StepTwoDesigns.
Recreation of the Forum, with the censored remarks.
Today is going to be an exciting day! With my new iPad fashionably dressed for the occasion, I head into the office. Today we start Bring-Your-Own-Device to work! Although this saves my boss a lot of money, and sets me a back a large chunk of my paycheck, I can finally choose what I am going to work with. And my netbook and my desktop at home are both not suitable for work.
How wonderful it will be to work with one computer! No more struggling with Dropbox or USB sticks to transfer files from one place to the other; finally I can update software when it suits me. Never again will I be interrupted by a mandatory immediate reboot while in the middle of a Live Meeting training to 20 people across the world. (Yes, this has really happened).
My new colleague had already told me that she would not have accepted this job if she could not use her MacBook. I think that is rather a “spoiled brat” attitude. Work has different rules than play, however much the times and locations for work and play are being intermingled these days.
My other colleague has been grumbling for days because he is no longer entitled to a business laptop and is too stingy to buy something from his own money. So he has brought an old laptop that has been collecting dust in his attic for some time. Even the local charity does not want it anymore.
I have already checked my email on the train, so once settled, I decide to go to the intranet first. Now, what was that URL again? I have never had to remember that! After some typo’s I manage to log on smoothly. Hold on, what am I saying: LOG ON? What has happened to Single-Sign-On? Do I need to log on every time from now on? That is not exactly progress!
The Homepage looks a little strange. Some headers display differently than I am used to, and some texts that should be clickable, are not. But the document I am looking for in my department’s Team Site is still there, and I need to update it with the latest insights. Hey, why can’t I edit it? Oh wait, that can only be done if you have IE and Office. Or the SharePlus app, but does anyone know if that works with our on-premise SharePoint? I decide to download the document, then edit and upload it again. Too bad it loses its version history, but I can’t be bothered really; it has to be updated. This all takes more time than with my office laptop though.
Phew, typing texts with just a touchscreen is not that easy! Perhaps I should buy an extra keyboard if I have to write these large chunks of text.
When my document has been saved again, I check the status of my order in SAP. But why can I not log on to SAP? Let me call the Helpdesk.
“Which system and browser are you using? IOS? Safari? O, I am sorry, we are still learning about that. We are accustomed to Office and IE. Can you please call back in a week, we expect to have figured out all those new systems by then.”
The order is not that urgent, so I decide to update my performance and development plan on the Employee Portal. I can’t seem to find the brand new instruction videos that should be on the instructions page since last week. ”Those are in Flash”, the HR employee sobs when I call for enquiries.
At the coffee machine (iPad under my arm, because I am afraid to leave it on my desk unattended), I run into our Project Manager Green IT. He looks unhappy. “All my project goals are messed up”, he says, “we used to have a nicely uniform low energy consumption and now we have a zillion of different systems with different power usage…and everyone seems to be charging their devices continuously at the office.”
The Security Officer joins us with a tired face. “You do not want to know what I have seen in our systems”, he sighs. “People are using the strangest software at home. It is a matter of hours before there will be a major issue. And think about all those unsecured Wifi connections that people will be using on trains and in restaurants, and all our business data being passed through unprotected systems. How can I still do my job?”
“You are not alone” I tell him. “Many people are thinking about the implications of BYOD“.
“But do you know what happens if my iPad crashes, or is completely broken?” I ask them. “Will the Helpdesk fix it? And do I get a temporary replacement?” They shake their heads, much to my annoyance. Their remark that, in case of loss or theft, they can remotely wipe my device and all its content, including my personal stuff, does not really make me any happier. “And”, the Security Officer adds, “if your phone or iPad or laptop contains potential evidence in a lawsuit or investigation, you will have to hand it over for investigation. That may take some time, and they will have access to your personal content too”.
Hmmm, I do not know if the price for “Bring Your Own Device” is not a little too high…
Of course the above story is entirely fictional. And while I am convinced that we can start today with Bring-Your-Own-Telephone to work, I am also quite certain that at a lot of Silicon will have to run through the Valley before 100% Bring-Your-Own-Computer will be a realistic option in every organization.
As you will know, I have helped many colleagues with setting up SharePoint Team Sites. These could be simple project sites, mainly used for sharing documents, but also sites where important processes were facilitated. (See tag DMWS-Examples)
My clients were very diverse. Each initial interview was therefore exciting. What kind of person would be in front of me?
- The Hesitator, who is actually quite satisfied with sending large documents by email, who does not mind to send around an Excel form every month to collect data from his colleagues, and to cut and paste the results manually into a report, and who can not imagine that a meeting’s agenda and meeting minutes can be done online and not in a document. Yet there is the realization that things could be done more effectively, but how?
Taking them by the hand, staying close to the existing process, and creating a comprehensive manual and training is the motto here. - The System-Lover, who knows a lot of different IT systems, has attended SharePoint Connections meetings, and who now suddenly needs everything he or she has seen there. The moment you ask for a description of the current process and the issues to be resolved, things go wrong because this person thinks in technical solutions rather than in business processes. Instead of thinking “how could we make this process simpler and better and reduce the issues”, they say “this step needs Nintex workflow”.
When working with the System-Lover, you need to stay focused on the process, and avoid the automatic deployment of new shiny functionality. Focus on using your existing toolset. You have to have that “business sense” I wrote about earlier. - The Ideal Partner who is able to discuss her / his problem process clearly and with openness, who is not afraid to commit to a business case (“this task requires 2 hours work per person per week”) and who knows things can be done more effectively, and leaves me to come up with the best solution. Who learns quickly, tests immediately and is a good sparring partner. This is a wonderful person to work with, because they always come back whenever they embark upon a new project or encounter a new inefficient process.
But there is also a client that is not so pleasant to work with, and that is the Resister. They have often been asked by their manager to improve a process, but they are not interested in or even afraid of technology, say that “SharePoint is not intuitive,” or do not believe that anything that you have done for 25 years, should be changed. Once you have finally defined the process, and have configured the site, suddenly new requirements appear, causing extensive rework. They never have time to test, and each time there is another reason that the new process can not yet be implemented.
In short, these projects take a long time and are rarely finished or implemented.
By asking some flexibility from the client, some clever thinking and being creative with the available functionality of SharePoint we have always been able to approach the ideal situation pretty well. We therefore felt confident to promise at least 80% of the desired functionality, and generally to the full satisfaction of the client. But that does not apply when you are dealing with the Resister.
And that finally brings me to my 80-120 rule:
For someone who really wants something, or who really has a problem, 80% of the desired functionality will be sufficient. But for someone who does not want to change, 120% is not enough.
Do you know better words for the different clients? Please let me know…I am not a native English speaker/writer.
When do you use this configuration?
We have used this for every large program with many individual projects. It can be a global (such as actions from the yearly Employee Satisfaction survey), business-wide (e.g. increase the profitability of a business unit), or local ( like improving efficiency of a production location) project, with the following characteristics:
- a set of projects (generally > 10)
- where all results and revenues are reported together
- there is a Program Manager for the complete set of projects
- each individual project is managed by a different project manager
- to be finished in roughly the same timeframe
What were the issues?
The risk of a set of projects, managed in different ways, is that the Program Manager has to chase everyone for updates, will receive these updates in various formats, and needs to spend much time to turn these diverse bits of information into one proper report. While the official reporting is done once a month, management is always asking the Program Manager “how things are going”, which means the Program Manager has to know the status on a daily basis. And this may cause some stress…
What are the benefits of this setup?
Every project manager updates his or her projects in the Team Site in one list. This enables uniform reporting and automated aggregations.
There is no document editing involved, so no issues with check-in/check-out or overwriting changes.
The Program Manager can spend time on analysis, progress and solving issues, rather than on collecting and aggregating data.
The online reporting also allows for many different permanent slices-and-dices (views) and real-time graphs of progress, making the need for official progress reports even less.
The priority of these configuration projects is generally very high:
- Many people save lots of time by having one place to go for the project’s progress
- These projects are generally very much aligned with business priorities
- External partners can have access to the Team Site and online meetings, so they spend less time and money on travel
How is the TS set up?
- The backbone of the site is an issue list or custom list, with “versioning” on. Versions are useful to store monthly updates, but also to see the progress of the project over time.
- Every project is one line item.
- The “Assigned To” is the project manager. She or he edits their own item(s) on a regular basis.
- We use many different metadata columns depending on the project, e.g. country, department, business unit, workstream, project type, etc.
- The fields that are updated most often are on top, allowing the project managers to edit with as little scrolling as possible.
Frequently edited items (highlighted) are on top of the edit form
- We prefer choice fields over lookup fields. The project’s metadata are known and do not change during the project, so we do not need to make it easy to add options; and choice fields in the list reduce the risk of someone accidentally adding, deleting or editing an option.
- Project managers have no ”delete” permissions to avoid accidents.
- “Traffic lights” give a quick overview of progress and pain points.
- We create many views to slice and dice the information.
- In most cases, making all projects visible to all project managers is beneficial and stimulates discussion and a healthy sense of competition. In some cases we filter all views on “Assigned To”= [Me]. This is the case when layoffs, reorganizations, acquisitions, divestitures or other major business critical outcomes are expected. In those cases, the Program Manager will set personal views. (Most people do not know how to create personal views or do not want to take the time, so this is quite safe)
Overview of all projects, sorted by Due Date.
Using traffic lights
Everybody always loves traffic lights as status indicators, which makes it easy to see “the good and the bad” at a glance. We have used 3 ways to create them:
- Texts (Green, Yellow, Orange, Red), with a description of what these terms mean. This is very basic, but often works well. It is also the most simple and stable solution.
- Uploading coloured icons and asking people to add the appropriate link.
- Using a calculated fields to color code. This is a more sophisticated way, but not always necessary. I do not have much experience with it.
2 ways to work with Stoplights, 1. Text, or 2. Picture
Some interesting views and graphs
- Projects not modified in 30 days or more. This view is helpful for the Program Manager to chase the project manager for updates
- Red and Orange projects. This view shows the projects that need management attention.
- Projects grouped by Phase, by Workstream, by Country etc. These views all help the Program Manager decide where to take action and where to find success stories and good practices.
- Views with sums on the realized savings or revenues.
- Gantt Chart
- My Projects
- Graph of projects by Phase. This shows progress of the complete PMO and is very useful for Management. (See also my Telesales example)
From left to right: Start of Program, During Program, and End of Program.
Are you also managing programs and individual projects in Team Sites? Please let me know!
Over the years, we have used Team Sites extensively for managing and working in projects. Depending on the type of project, we have used them in different ways:
Simple Projects: stand-alone Team Sites
The majority of projects were simple, short-term projects where a Team Site was used mostly for sharing documents, and perhaps a calendar for meetings and deadlines. Everyone with a good business reason could request a Team Site. We left it to the project manager to configure, which he or she seldom did, but as long as they let us know when the project was finished and the Team Site could be removed, we did not mind. The basic setup was generally sufficient and the target audience small.
We only actively tried to discourage the use of Team Sites with Tabs; they were very popular but also took a lot of work to set up properly. For a short-term project we thought this was not efficient.
Recurring projects: Team Site with templated subsites
There were also teams who had one project after another, such as product development and IT. Some of the project managers wanted to have a standard setup for their Team Site for each project. For instance a standard lookup field in every Document Library with the project phases, a custom list to manage time spend, or a world clock because they were working with people from all over the world. Since we did not like to configure stand-alone sites every time, we usually created a subsite template, which we or they could activate whenever necessary. For the project managers it had the additional benefits that all project sites were under one Team Site “umbrella”.
My earlier Crisis Management in a Team Site is another example.
Multiple projects: 1. PMO Team Site.
As every large company, we often had global projects with local or functional sub-projects. You may think of a Sustainability project, the follow-up of the yearly Employee Satisfaction Survey, or a company-wide Cost-Reduction program. It was essential that the progress of these projects could be monitored in an easy way.
Many of those projects were therefore facilitated by a simple Team Site with an Issue Tracking list as the main component. Every project was a line item, that the respective project manager had to update on a regular basis. By cleverly configuring the list and the views we could give a great overview of project progress to the Program Manager.
The individual projects could be managed in a subsite, a stand-alone site, or in a different way.
The first few times we really had to push this functionality to the various Program Managers, but after a few succesful implementations, people came to us immediately when a new global project was planned.
Multiple projects: 2. Program Site Collection.
For other major global projects we created a dedicated site collection. We only did this when it was absolutely necessary, for instance when many people had to contribute (increasing the risk of accidental overwriting), lots of documentation had to be shared, and/or it was important that one country or function did not have access to another’s information.
In those cases we used a templated subsite per country and/or per function. We generally made use of (Corasworks) rollups and rolldowns. For instance, announcements and manuals were posted in one site, and rolled down to all subsites, while the results of the project were rolled up from all subsites into another site for reporting.
All these rollups influenced the performance of the site. Next to that, it was essential to think about security because there were many people who needed access to one subsite or another, and if you wanted to be able to see the rollup of results, you had to have access to all subsites. And then we are not even talking about any changes in template – if the program manager wanted a change to the template after it had been implemented, it meant that you had to make changes to many individual subsites and to the rollups.
But in the few occasions when we have used this setup, it has worked well.
I will describe and show an example of the PMO Team Site setup in my next post.
I may be irritating KPI-addicts, mathematicians, or other people who like counting, measuring and comparing, but what gets measured does not always get done!
Of course that requires some explanation.
When we moved from a custom-built intranet to SharePoint, we had to think about usage statistics. We were accustomed to measuring usage by company unit, which allowed us to see which countries or functions used the intranet the most, and where we had to spend more time to increase adoption. It turned out that a link with our Yellow Pages was impossible in our SharePoint implementation, so we commissioned another party to develop this for us.
When our implementation partner returned with their proposal, their eyes sparkled with dollar signs. They proudly proclaimed that this would be their largest Business Intelligence deployment in Europe!
At that moment, all kinds of alarm bells should have started ringing.
Unfortunately, we thought that this was actually a cool idea.
We spent a lot of time specifying our requirements. As an intranet team we needed information about usage of portal, sites, pages, and documents, about referrers and referrals, by location, country, continent, company unit and discipline, and everything had to be exported into html, xml, csv, excel, pdf and a handful of other formats.
Our content owners would also have nice statistics such as distribution of visits by country and discipline (very useful to see if you were reaching the intended audience), the most popular documents and “just” the number of unique visitors and clicks on their content during various time periods.
When it was finally working (many months later than the launch of the new intranet), we got lost in a slow loading slurry of numbers. With every report we wanted to make, we had to spend an hour calculating, and/or had to read the manual to see how these numbers had been defined. As the company changed, and businesses were divested or merged, the mess kept growing because all the old data was still in the system and contaminated the results.
Because we stored a large amount of data, the system became slower and more sensitive to disturbances. We had to remove data on a regular basis because the server was full. Our service providers were not familiar with these custom statistics so they could not solve the problem. At one point the daily update took about 20 hours. Try explaining that to your users, especially if the 4 hours uptime occur in their night!
So, what have we learned?
1. If you suddenly are someone’s largest project, in not exactly the right discipline (Business Intelligence? For intranet statistics?) please think again. Is this the right partner for you, or are your goals too ambitious for your purpose?
2. Focus on what you REALLY need. We also specified lots of “nice to have, just in case” functionality.
3. Make some scenarios for the future: can this be maintained and supported over time, what happens when major changes occur in your organization, or if you are storing many years of data stored.
And now, out-of-the-box functionality suddenly sounds very desirable 
.
When I was developing snack products, I was never allowed to talk about my work with people outside my company. Others might copy our ideas! I always felt this was a real pity, because I was convinced that other product developers would have exactly the same problems that I had and we may have shared solutions. Of course I am not talking about sharing secret recipes, but about topics like: how do you do consumer tests, how do you set priorities, how do you work with marketeers who want new products NOW while you, as a developer, want GOOD QUALITY products?
Now we all had to re-invent the wheel ourselves. (Which I hate with a vengeance!)
But now that I find myself in the wonderful world of intranets, life is suddenly very different! Intranet managers continually share knowledge and experiences with acquaintances and strangers, at home and abroad, online and offline, because we share a profession.
Is that because many intranet managers have a background in Knowledge Management? Because we have learned how inspiring, comforting, or just easy it is to listen to the experiences of someone else? Do we all have the same “evangelist gene” that causes us all to passionately change our organizations for the better? Or are we all just lazy, er…I mean efficient, and do we all hate to re-invent wheels ?
Or is it perhaps because we realize that this profession does not have many secrets? Our secrets are in the content. Our secrets are NOT in our design, our platform, our governance or information architecture. What an organization does with its intranet is always based on the strategy and culture of that organization. (Well, at least I hope it is!) So copying another’s design, navigation or position of the web parts on the page is useless, because it will never fit with your organization.
But you can always learn from other intranets of course – if only that you have made the right choice for yours!
Of course I have also had my doubts about the amount of information I could share in my presentations. I have given lectures and removed the screenshots from my presentation for the handout. But later I have just hidden any sensitive information from my screenshots and just left them in. (Screen capture tools like Snagit allow you to “erase” confidential information easily)
A picture really says more than 1000 words! And whether your company news is in the center or left, with a summary or not, is interesting, but it is certainly not mission-critical information.
What then is your confidential content? In general: sales and customer data, financial data, employee personal data, and information about projects in such areas as innovation, lawsuits, contracts and acquisitions. This is generally information that an intranet manager will not have access to, anyway. We may facilitate the collaboration, but we do not own the content.
So…let screenshots do the talking and let’s share more screenshots of our intranets!
Have you ever been involved in a product recall or another crisis? If yes, you will know that this is a stressful time! A recall is very important, it has to be dealt with NOW, and it has to be dealt with correctly to avoid risk, and all on top of your normal work. Everything that can relieve the stress is more than welcome.
What was the problem?
One of our larger countries had occasional recalls. It did not happen too frequently, fortunately, but it was a real hassle when it occurred. There was an official procedure, and many people from different departments and external partners were involved, lots of documents were being sent in various formats and versions. Since people were in a stressful mood, they did not want to spend time on thinking.
The briefing was:
- make all essential information as easy to find, read and edit as possible (not everyone was Team Site savvy, especially the external partners, and everyone was hurried)
- avoid sending documents and emails back and forth – but notification emails are welcome
- have the option to archive the generated information for legal reasons and for learning
- make it re-usable
What is the solution?
We have set up a Team Site collection, with a templated subsite for every recall. The subsite can be created from the top site by the process owner without any help from the intranet team – he has Site Collection admin rights, a rare gift 
The site is set up to deliver maximum info with minimal effort. The process owner only has to check and update the Team Members list which is in the template. The email addresses are displayed in the list so process owner can copy these and give access to all in one step.
Next to that, there is an ongoing Live Meeting to be used exclusively for emergencies. The access information is incorporated in the template.
The Homepage displays the essentials:
- Announcements
- Picture of the product and the problem, if it can be visualized
- Last 5 documents
- Actions assigned to me
- Decisions taken
- Links to set Alerts (all changes, immediately) to Announcements, Documents and Actions/Decisions
- Content editor web part with information for the Live Meeting
- Content editor web parts to inform people how to work in the site
First I created a sort of wireframe, to test if we could display all the most important information on one page.
Wireframe. The items in red contain the most important information.
We decided not to display two lists: the Evaluation (survey), which was only used at the end of a recall, and the Expense Declaration form, which was only used by a few individuals. The process owner will announce the path or link to those lists when necessary.
When a recall is finished, the process owner removes all users except himself and the designated legal person, and stores the site for the legally required period.
Recall Subsite Homepage
What are the benefits?
After the first recall that was managed in this new setup, all team members were very positive:
- The Alerts mean that people receive many emails, but smaller in size and they do not need to be stored, since the actual information is in the site.
- The Alerts ensure that everyone receives the same information – nobody is accidentally left out of an email.
- Sharing everything in one Team Site creates one official version-controlled dossier instead of various personal ones. This saves everyone time and stress and creates confidence.
- The Live Meeting allows people to discuss anytime from anywhere, saving time and travel. (especially since you need to meet at least once a day)
- The evaluation survey and the expense declaration are now online, and no longer in individual documents. This saves time in aggregating the results, and creates instant transparency.
This is in fact a very simple setup, without any complicated lists or workflows. The most time-consuming part was making sure that a new subsite copied everything correctly, so it was ready to use instantly. I had to make some sacrifices, e.g. display the lists and libraries and train people to set an Alert, rather than displaying the direct links to the alert pages. But because it is tailor-made for the situation and can be used almost instantly, it is a real time- and stress-saver!
Further improvements are possible, like using an Issue List for the required log, but at the time it was too complicated for the users.
Have you used Team Sites in a similar way? Please share your examples!
“What’s in a name? That which we call a rose, by any other name would smell as sweet.”
Well, if William Shakespeare has said this, who am I to disagree? But I think that the name DOES make a difference when it comes to content!
Take a look at this screenshot.
Local news functionality in two countries
Both countries use exactly the same functionality for the same purpose. But the language of country 2 is both more informative and more inviting: You know you have a new colleague called Annette. If you are curious about where she works, you can click on the article to find out more. But if you have limited time, you know at least the essentials. This title has a good “information scent”: it immediately gives you an idea what the information is about.
This seems very logical. Yet sometimes we forget to think carefully about names and titles. My communications colleagues have been known to send a weekly newsletter from “”ic@company.com” (and not “Internal Communications” or other descriptive name) with the subject line “Newsletter week 43, 2010″. That just does not smell nice!
Another example: in the Netherlands the first truly relevant documents on our intranet were about employee benefits. All Dutch employees had the link on their homepage for easy access. Yet we received complaints:
The content owner complained that people kept calling and emailing for information, even though “it was all on the intranet”.
Employees grumbled that they expected to find employee benefits information on the intranet, but they did not know where to look.
What was the case? The link was the same as the acronym of the originating department, and that was, very intuitively, “CSPO”.
Fortunately the solution was exactly as simple as you think!
Tips:
- Always spend time thinking of titles of documents, emails, navigation elements, links, “from” and “subject” lines in your e-mail, etc.
- Look for alternatives and test them with a few colleagues, especially if this is information which is important, has a large and diverse audience, and/or will remain on your intranet (or website) for a long time.
- Keep in mind that what is obvious to you is not always as clear for your audience. Your content may be a rose, but if you call it ” manure” you will definitely have fewer visitors!
Further reading:
Helping people find the content they want, from Step Two Designs, with explanation and examples
Boosting Information Scent, from WebSiteOptimization.com, with useful tips
Keep People on your site …. of VanSeoDesign with the theory
And your own examples are welcome, too!
“And, did our French colleagues decide to use the Local News functionality?” my manager asked me one morning, when I had just returned from a visit to our Paris office.
I looked up from my desk in surprise. “How do you know we discussed that?” I asked him.
“Well”, he smiled, “I saw a news item on the intranet”.
Oops! I felt my face flush and did that office floor just sink a few centimeters? It turned out that I had created a news item, just for demo purposes, and forgot to target it to France, and forgot to delete it. Since I was a global administrator, I automatically published to all countries. So “A new intranet for France’ was visible to all employees, with a “blah blah” as the text. Luckily it was programmed to show at 8 am, and it was only 8.15 am when it was discovered, so the damage was small, but I felt so stupid!
Of course this did not happen again. But others did; and because I always like to see the bloopers on my sitcom dvd’s, I thought you might want to learn about my mistakes too; after all, it makes us human!
Another great blooper was the deletion of a complete Team Site while I was configuring it. Or rather, after I had configured it. I thought I was deleting a subsite, but I was on the top site! Three days of configuration down the drain, and on top of that, I was working in Spain, because that way I could work more closely with the business owner. I had promised him that he would have a working prototype by the time I left, which was a few hours later.
Luckily I had a very able colleague who restored my site in 5 minutes, but it were 5 very long minutes! Since then I have always looked at the URL at least twice before deleting a subsite, so I have never made this mistake again.
But my biggest mistake must have been my failed efforts to streamline our Investment Request process. The Investment Request is a complicated form to ask approval for a large investment such as new machinery, a commercial, or software licenses. Depending on the purpose, the business and the amount it had to be approved by different people, and that meant that the process took a long time and was completely opaque. It happened freqently that nobody knew where the form was or that it was lost completely. Everyone agreed that this needed a better process. And since we agreed that it would be wise to try and use our existing SharePoint platform before blindly buying a dedicated tool, we decided to try and describe the current and ideal processes.
The idea was that the forms would be in a Document Library in a secured Team Site, with a Nintex workflow enabled. We would add the approval procedure to the Team Site, with an agenda of the next decision meetings and the deadlines for submission, to give all people submitting a good idea of what they could expect.
There was general agreement about the process, but it turned out that the exact routing was decided afresh every time. Even while we had only about 8 people involved in the approval, the sequence varied and I could not find the deciding factor. Did one amount needed a different routing than another amount? Did availability of the participants play a role? Was it the part of the business the request originated from? I needed this information because the Nintex 2003 workflow was not very flexible and we needed some structure. But I was convinced that with 3 or 4 different workflows we would be able to capture 80% of the requests easily.
I was rather shocked that nobody could provide information on the sequence. Just for a joke, and to make people aware of the strangeness of this situation, I asked if it might be the moon or the pollen count?
As it turned out, this was not appreciated. I have made a Proof of Concept and tried to interest the business owner to test it, but to no avail. Lack of time, too difficult for his assistant to understand, not flexible enough, all excuses were made.
Still, this is a mistake I will happily make again and again! I firmly believe that, with a bit of flexibility and structure it would have worked and would have saved the company a lot of time and hassle.
Do you have any bloopers that you would like to share? Please add them to the comments!
