I’ve been developing small-scale information worker solutions for the same company for a few years now. Different departments and teams needed different solutions to solve their problems in the domain of communication, collaboration and the optimization of business processes. And because I am still here, some time after we’ve launched the solution, I can see where it all led.
Well…
On the one hand, some solutions are still a great success, helping the teams to increase productivity and quality, and reduce cost and frustration.
On the other hand, other solutions completely fell flat. They have never been used for real, and got swept out ignominiously as a dead site by the house-keeping team.
What went wrong with those duds? It’s not always clear, but these seem to be important negative factors.
Solving no problem.
We create a solution – in my case usually specific functionality in a teamsite – to solve a problem. We identify that problem in the beginning, with a rough business case. However, sometimes an expected problem does not actually arise. So the solution is sitting there in a vacuum, solving nothing of substance.
An example that I encountered recently, was a solution for issue tracking in a high profile project. When I asked after a few weeks why I did not see any issues in the tool, the answer was that there were no issues so far…
Maybe I should see that solution as an insurance policy: you hope you don’t need it, but you make sure it’s there just in case your house burns down or – in this case – the project gets swamped with issues. Unfortunately, I fear they did find issues later on. By then, original project leader had left, probably nobody remembered that they had this tracking tool and they solved the problem some other way.
So: If you create a solution for a problem that hasn’t arisen yet:
- Double-check that they need the insurance.
- Keep it as simple as possible, to avoid wasting too much time.
- Make sure the team know about the solution, so that they can start using it as soon as the problem does arise.
Functionality insufficient
We do our best to create a solution that meets the users’ needs. But sometimes the result just isn’t good enough. In my case, the available platform and toolkit definitely limit what I can create. In other cases, the technology may be up to it, but the budget it too restricted to get the job done.
An example that I won’t forget in a hurry is a sales tool for a Russian team. We knew from the beginning that we were pushing the envelope. But as the project progressed, it became clear that it just wouldn’t work. The American third party tool didn’t understand the Russian date format. The client became more emphatic that his huge amounts of data needed to be connected in multiple ways. And there just was no way that we could solve the problems in a reliable way. In the end, even the parts of the tool that did work, were never used and the entire solution was deleted in our last spring cleaning campaign.
So:
- Identify the full extent of the client’s needs at the beginning of the project, especially complex showstoppers.
- Double-check that you have grasped the essence and that you have a solution, especially if there are further complications, like a language barrier (I don’t speak Russian any better than that third party tool that got stuck on the date format…).
- If there is no good solution, cut your losses and stop the project. Launching an inadequate, unstable solution will only make your life harder, when they call you to save them when it collapses.
Usability insufficient
Our solutions are created to help employees be more productive, or more generally: help the users reach their goals. That will only work, if the solution is user-friendly: if the users can do their job quickly, easily and pleasantly.
With on a fixed, old platform, usability of any of its solution is sub-optimal, to say the least. For instance, readers see an Edit button and only discover they do not have the required permission when they try to save the item and all their content is gone. And when contributors enter metadata, there is no connection between the data they enter. So if they first select a country and then a city, the selection list of cities is not pe-filtered. Stupid system…
However, sometimes a solution is not user friendly just because it is an IT system, regardless of its “objective” usability. I’ve sat next to users who told me “No no no, this is just too difficult for me“, until I pointed out that – basically – they just had to click the prominent button ‘Upload document’ to upload a document. “Hm, that’s actually quite easy”. Such users don’t feel friendly towards any new system, because it always takes some energy to check out something new, and they don’t see it as their core business. But that has more to do with user adoption driven by management commitment.
So: optimize usability as far as possible
- Determine who the user groups are and what they need, and cater for their needs specifically. For example, remove the Edit buttons from pages that are mostly visited by readers who cannot use them anyway.
- Test this with real users, even if it is very informally: just drop by and see what they do. I see a lot of interesting things when visit my less intranet-savvy contacts. They sometimes click in very unexpected places…
- If you can’t use technology to make things clear and the fixed styles don’t give you any help, be as clear as you can in text and sorting:
Include the right words in title bars, link texts, explanatory texts, document titles.
Order the content in such a way that the information that is most important to most users is at the top of the page, at the very least above the fold: most recent documents, my tasks, key links, etc
User adoption insufficient
A solution can be set up brilliantly, if the users don’t use it, it is still a dud. Of course none of the solutions I created were absolutely flawless. But I have seen good solutions ignored for other reasons.
One of the solutions where we really made a huge effort to make it as functionally useful and user-friendly as possible, is a program management tool. The project teams of the individual projects should update the project status and other key indicators in the tool, so that all participants can monitor the program’s progress and the program managers can intervene where needed. But most project leads just don’t do it. The tool is not that difficult to use. But determining the status and key indicators of the project is difficult. So they are very reluctant to adopt the process itself, let alone the tool they can use to facilitate that process.
Another example I’ve just encountered, concerns a very savvy project lead, who is definitely able to handle both the process and the solution he could use to make that process more efficient. But he insists on using some “old fashioned” solution that he has always used and that he is completely fluent with. Except that it is rather unpractical for collaboration with the other stakeholders. In this case, the main obstacle for adoption is probably the ‘Not Invented Here’ syndrome.
So:
- First of all, the users need to understand how it all works. Ensure that the users know what the business process is and how to handle that. And then how the solution can help them with it and how to use it exactly. So provide training and help material, both concise (FAQ, quick reference) and more detailed (user manual, help pages). Even if they don’t consult the material, many users feel more secure in the knowledge that it is available if they need it.
- Communicate not only theoretical knowledge to the users, but also a clear sense of what’s in it for them: how will this make their life easier (saving them time and effort) or richer (informing them better than before).
- Is this an important business process? Then using the tool to make that process flow more efficiently is a core task for the participants, and not just something they can ignore. This implies that management commitment is needed and the managers need to act upon their commitment.
Management commitment insufficient
In the context of intranets, the goals that the employees are trying to achieve – with or without using one of our solutions – fall under the responsibility of a manager. If the manager feels that the goals will be achieved more effectively and efficiently using a tool, they can ask us to develop such a solution. But then the managers are also responsible for the adoption, usage and maintenance of that solution, even if they delegate the actual work to another employee. However, I’ve seen quite a few solutions fail because of a lack of management commitment.
For several solutions, including what was supposed to be an important tool to aid marketing strategies, my contact for the entire project was an intern or another temporary employee. I knew the names of the responsible managers, but I never got any input or feedback or questions from them. So when the temporary employee left, the entire project just stopped.
That marketing tool was almost finished two months ago, and it still is almost finished. An HR site was almost finished two years ago, and it is still gathering dust without any further progress. The positive only example was the HR site for another country, where the intern managed to launch the site before he left. That is a rather static information site, so it does not matter as much that it has not changed since then, because at least the information is available for the readers.
In some other projects, the managers were personally involved, but the solutions still failed, because the managers did not see them through. In one case, the most eager sponsor left the company. The other one had very little time, as complications within the organisation distracted her. I noticed that she lost her enthusiasm for the project, but I was unable to re-energize her. The fact that she was in Australia and I was in The Netherlands played a role: we could only have a real time conversation in the hour after my midnight and at the start of her work day. That solution had cost us a lot of effort and was ready for launch, But it was never used and flushed out in our last spring cleaning.
So:
- Don’t do a project with an intern without on-going involvement from the responsible manager. If they won’t do more than just give the order to develop a solution, then it apparently is not important enough.
- Get more explicit and well-founded Go/No Go decisions: Is the problem that we are trying to solve still serious? Do you still think you can achieve the benefits? Can we take a sprint to finish the solution with a burst of energy? Or should we just stop wasting time on something that is just bleeding to death?.
- Make it clear that they need to invest some time now, in order to save a lot of time later, when the solution allows them and their team to work more efficiently.
Most of these reasons for duds to fall flat don’t have anything to do with technology, but with people. So getting a cool new toolkit is not going to help me get more solutions up in the air and soaring to great heights. It’s
getting a cool new toolkit
AND
determining exactly what solutions I should create with it to allow users to reach their goals
AND
making those solutions so user-friendly that they will get their quickly, easily and without frustration
AND
getting the users up-to-speed with its workings and eager to use the solutions
AND
Ensuring management commitment so that the tool that facilitates key processes is considered key as well.
