The global landscape is littered with failed Intranet projects. But why? There are many reasons why Intranet projects don't go to plan. We've listed 5 key reasons below.
Most vendors will propose to implement their software in a certain way unless you define upfront what your specific requirements are. Just because you’ve selected an Intranet supplier doesn't mean you’ll end up with the Intranet you want. The customer is expected to determine what are the requirements. This does not require the customer to be an Intranet expert, rather the list of requirements should cover the business problem you want to solve, what you want to deliver to staff via the Intranet, functions you expect to be able to perform using the Intranet, and finally your budget and a timeframe in which you want to complete the project. This pedigree information will greatly assist Intranet providers you invite to tender for your project to determine how to propose their solution. Intranet projects fail when the customer makes no effort to document any of the pedigree information, and is likely to end up choosing a solution that isn’t the right fit.
Rome wasn't built in a day, and neither was the common Intranet. Expectations vary, and as the customer it’s important to remain conservative about what’s possible given your budget and timeframe. Most vendors will offer an out-of-the-box Intranet solution that is designed with speed to market in mind. This means they can deploy their basic offering quickly, but its likely not to meet all of your expectations. On the flip side the team you’ve put together internally to ensure the project succeeds are likely to be managing this new Intranet project in addition to their regular day jobs. Intranet projects fail when there is a misalignment between what the customer communicates are their expectations, and if the vendor responds accordingly with a solution that delivers on these expectations. Be specific with your Intranet requirements.
Intranet projects fail when the customer makes no effort to document any of the requirements, and is likely to end up choosing a solution that isn’t the right fit.
Most organizations will procure Intranet software through a third party; an IT service provider or consultancy firm. This will be the most common situation for most organizations, but it is possible to work with the developer of the Intranet software direct if you take the time to do your research. Typically IT service providers and consultancy firms don't just sell Intranet solutions. It’s one of many things they do to generate revenue for their businesses. As such, they are rarely Intranet domain experts and can only deliver a solution that is closer to an out-of-the-box offering and not a custom tailored Intranet that actually delivers on business requirements. It might be obvious, but reviewing previous Intranet projects delivered by the vendor and checking referees will ensure you are confident that they know how to successfully complete your Intranet project.
Timeframe and budget
This is perhaps the most important question. First and foremost, timeframe will be directly related to budget. If you don't know what to spend on an Intranet (and don't panic, why should you be expected to know what it costs), documenting your requirements upfront will allow you to engage initially with vendors to learn what type of ballpark investment is going to be required to meet your expectations. Budget will be relative to the size of your organization. If you’re fifty people then your budget is going to be smaller than if you have five thousand people. As most Intranet software is licensed on a ‘per user’ basis, the software licensing cost alone will determine decent portion of the required budget. The other price dimensions include services and support. How much customization do you want to explore? How much support do you expect? Working within conservative deliverables and timeframes will provide you with a budget that you are comfortable with.
Ultimately Intranet projects fail because both parties stop communicating. In some cases, the customer makes the mistake of handing over responsibility to the vendor once the successful vendor has been engaged. This ‘autopilot’ approach to the project by the customer can be disastrous. Firstly, the project is only just commencing, so as the customer you need to monitor that the vendor is executing on the deliverables in the way they proposed they would. Secondly, you need to ensure the vendor confirms they understand the deliverables as they were documented. Time and time again customers will interpret differently to what the vendor has proposed. Lastly, both parties need to clearly understand what each of their responsibilities are for the project. Intranet projects are like any other marriage. Effort is required from both parties, and each party is responsible for their part of the relationship. When Intranet projects fail, the question is who failed with their responsibility? The customer or the Intranet vendor? Ensuring there is open and transparent communication from beginning to the end is fundamental in making sure the new Intranet project is a success.