March 8, 2011 Leave a comment
Perhaps I should do myself a big favour and keep a set of generic documents to stuff into proposals – but I don’t! However much I try to copy and paste what has gone before, I still end up refreshing my thoughts for each new proposal. The following are some thoughts I put together for a recent intranet proposal – top level project issues that I think merit attention at the beginning of each new intranet I get involved in.
Informing and engaging users
There are key elements of an intranet that must be realised in order to achieve core business objectives, such as document repositories, content searching, user permissions management, news and so on. At the same time, the users should want to come back, the intranet should become the “go-to” application of choice for many of their key daily tasks. In other words, there must be a balance between informing users and engaging users.
Intranet is a process, not a system
Clearly an intranet is a system, but it is also more than that – a vehicle for changing the way that people work, for making their lives easier and the company more effective and efficient. As users start to engage with the intranet, they will find new ways of engaging with the knowledge provided by the organization. The ultimate goal of a good intranet is to become an effective knowledge sharing platform – not just between the company and the users, but also between users.
You can’t know what will work in advance
Some ideas that seem excellent on the face of it don’t work in practice due to unforeseen or unforeseeable circumstances. Often ideas that we seek to translate from other settings – such as social media – fail in a corporate environment. For instance, my agency have implemented highly engaging attractive features such as noticeboards for car sharing, which have failed to take off. On the other hand, small elements of functionality such as ‘Who’s locking up’ and ‘Who’s out of the office’ add an unexpected value, and are picked up with enthusiasm by users.
Early involvement = happy users
Because an intranet is a system that impacts upon users’ everyday lives, they need to have confidence that it will work for them. If the system feels imposed from above, it is likely to meet resistance in rollout. If, on the other hand, users are involved early and often, it is easier to identify what works and what doesn’t work.
Ideally the development process should include a product owner from the client, as well as representatives from key user groups. By so doing, it becomes possible to identify what works and what doesn’t work early on, as well as creating a group of enthusiastic advocates who will help smooth the way for eventual buy in by the user base as a whole.
80% of value from 20% of functionality
With intranets, as with many any other kind of technology, 80% of the value is realised using 20% of the functionality. By releasing key functionality early in the development cycle, it becomes possible to:
- achieve early wins
- demonstrate successful progress
- build user confidence in the solution
- ensure the most critical functionality is the best tested
If pushed, I will always prefer a methodology that involves frequent releases and lots of user input. For reasons of internal politics, as well as the paperwork required for formal budget applications, it is often not possible to wholeheartedly adopt an agile approach in full. However, I think it is a matter of focus here – are you more bothered about ticking boxes, or about maximizing the amount the business objectives achieved with your budget? An agile mindset is all about getting useful work done as soon as possible, about satisfying pressing business needs, building confidence, and flushing out issues so they don’t stack up at the end of the project. Agile does not mean chaos – despite prejudices to the contrary. Agile to me means acting in light of the facts, and illuminating the facts through action – once the research has been done and the groundwork has been laid.