Intranets can take years to complete and very often never actually reach the stage of total completion; they are in a continuous state of evolution. With the advent of mobile access from an array of devices, deciding what features to deploy, and how, becomes even more challenging.
Intranet Prioritization Matrix
Feature requests come from departments, content consumers, content owners, management…the list is endless. With requirements coming from many directions, prioritization is key. All of these requests have to be considered and the benefit of them weighed and put into some kind of prioritization matrix (shown below).
The next step is usually to put together a plan and create a project very often hitting the low hanging fruit and quick wins first. This might be ‘Agile’ with lower priority items in the backlog, or may follow the ‘Waterfall’ methodology, or more often than not something in between!
Consider User Experience
Nothing new here I hear you say, well that’s not quite true. Not too long ago we would be assuming these features would only be accessed via a browser, but that’s changed now. A variety of devices may now be used to access an intranet. We are familiar with considering the different browsers users may have, but not so much thinking about the user experience on different devices. I’m not talking about making sure the pages simply display on the device, but optimizing the display and interaction for the user's device.
This is where I find identifying the “apps” in requirements helps. Most feature requests can be broken down into Apps and Services. I introduced this concept in another recent blog article -- Everything Is An App. If we can identify the Apps, then we can consider the relative investment in optimizing that App for a device and the value of that App being available on a device.
The 3D Mobile Intranet Prioritization Matrix
So, now your prioritization matrix comes into play, but how do you represent the different devices in your matrix. You could multiply up the requirements over devices but this could quickly get messy. If you had, say, 10 key requirements and were considering four devices then that would map to 40 requirements, I wouldn’t fancy representing that in a matrix. My preferred approach is to use a 3D matrix where I have the usual impact vs. cost axis, but then on the 3rd axis I have device or app type, e.g. browser, native app, web app.
Let’s take a skill search feature as an example. This is a feature that you could quite easily run through user profiles and the enterprise search engine. For a user with a standard browser this would be acceptable. You may want to build more of a feature out of this but when prioritizing you may decide for now the search engine would suffice.
However, for your mobile workforce equipped with smart phones, the experience is not so great, and you may have employees that need to carry out these searches on the move. In this instance you may decide that having a specific mobile app for this search is quite a high priority. Not only would it make them more efficient, it would also get you some buy in to the platform you are putting together. This could be represented in the 3D matrix as:
You Can’t Ignore Mobile
Users are becoming much more demanding with their User Experience expectations; they use high quality internet sites with mobile specific apps every day, and are now expecting the same from their internal systems.
In the future, the concept of intranet homepages may be a thing of the past. I can imagine users having a set of apps they use to access the services. Microsoft and Apple have invested in app technology so this stuff is here to stay and your business cannot afford to ignore it.