A typical intranet starts with a problem. Maybe a staff survey that highlights inadequate staff engagement, maybe someone frustrated by not having a central place to share company documentation. When that problem becomes big enough or annoys the right person, a project is launched.
If the existing intranet is not up to scratch, they may turn to the market to see what’s available. As the project lead you begin to invite intranet software suppliers to come and present how they would solve your problem. They demo their technology and highlight areas that they could help, more requirements spring up that can be solved by the capabilities that they can offer.
The danger I often find is that people begin to get seduced by the features available and really lose sight of the original problem. It’s great to understand what is available but this should support your original objectives, not the other way around.
In my experience, getting requirements right involves speaking to people. Representatives from within the business that actually face the problem you are trying to solve. Interviewing stakeholders to understand the method that they go through and the information they seek.
Through this knowledge you can get intranet software that actually helps the process that you are trying to fix, instead of throwing more capabilities at your intranet audience. It removes the risk of thinking of ourselves as the intranet audience. It will enable you to judge the success or failure of your project by the processes that are improved instead of the features that are implemented.
If you are looking to understand your intranet requirements I have recorded a set of videos that take you through the process of interviewing your stakeholders and conducting a requirements gathering workshop. You can access these videos for free on our uncovering intranet opportunities page.
