Ensure intranet project failure: A guide for project sponsors

So you’re sponsoring the intranet project? Good work – you have an opportunity to really make a difference to an under-utilised and potentially hugely valuable tool that is already used by most of the company on a daily basis.

But what’s that? You have heard about an unwritten code for intranet project sponsors? That being obstructive, dis-engaged and difficult is ‘bang on trend’? You want to join the fast growing club of sponsors of failed projects?

You are in luck. Here are our top tips.

1. Forget setting objectives

Thinking about ‘why’ you might want to change something is for losers. Why should you have to justify yourself? Skip objectives and jump straight into the solution.

2. Set a clear expectation of exactly what the end product will look like

Draw a picture and insist “I want one of these!” After all, you know better than some designer or user experience ‘expert’, and requirements are for people with too much time. You’re a visionary!

3. Don’t listen to end users

If everyone thought and acted like you, the company would be a huge success. So if you design the intranet for you, everyone will start to think and behave the way you do, right? Besides, what do these so called ‘end users’ know? How many of them have run an intranet project before? You’ve been using the internet for, ooh, at least a decade, so you know all there is to know, right?

4. Set arbitrary goals and measures for the project

When are you next meeting the CEO? Wouldn’t it be impressive to have some cool project delivery to show off when you see them? Course it would. Set the project deadline for a week before your next CEO meeting. All about managing upwards, eh?

5. Make changes big and make them a fun surprise!

Redesign – everyone loves a good redesign! It’s a great way of saying “yeah, we screwed up, everything about this page is wrong,” while at the same time not really making any improvements. Plus, half the fun is watching everyone’s smiling face when they get in one day to find that everything has been changed.

Smaller, incremental changes made over time would go unnoticed and involving people would just mean they’d steal all the credit. Where’s the kudos in that?

6. Ensure that your budget is slightly smaller than your ambition and employee expectations

… because hearing employees say “is that it?” is the finest measure of success there is.

7. Create a committee to manage the project for you

Once you have said what you want, you don’t want to be burdened with ongoing meetings and being asked to make decisions on things.

Set up a committee of people, ideally all with very different views and objectives, give each of them an equal vote and insist every decision is ‘signed off’ by the whole committee. For near-guaranteed failure, ensure this committee is made up of people who would like to own this project themselves, and think the intranet belongs to their department.

8. Tell everyone how brilliant it is before it launches

Making changes based on feedback will only slow you down. Instead, keep it under wraps but whip up excitement before launch by publicing how great it is. In this way, you can maximise user disappointment when they get to see the thing.

9. Ban the project wash-up

You knew it all before the project, you knew exactly how it would look, feel and work, so there’s absolutely no point in closing out the project with another dull meeting. Project wash-ups are for time wasting idiots. Nope. There were no lessons learnt, because it all went to plan.

10. Never, ever, ever, compromise – on anything

Changing your launch date, upping your budget, accepting some features or requirements won’t be met are all failures and accepting you got something wrong is a sign of weakness. Never compromise, plow on regardless.

Why should you come out of this project with a damaged reputation when there’s IT, the steering group and the project manager to blame? If you keep saying the same thing – uncompromising and consistent – you can’t go wrong.

Epilogue: A short note for people void of a sense of irony

While all of the above will undoubtedly increase the chancing of failing, we really advise that if you are sponsoring an intranet project, you try not to do any of the above. But doing the opposite isn’t a sure path to success either. The intranet is used by so many parts of the organisation, for so many differing purposes, so it’s nearly impossible to please everyone. It’s very likely that no matter what you do, your project will be seen as a failure by some part of the organisation.

If you’re working on the project, all of this makes the intranet project sponsor someone very deserving of our respect – they have taken on a job with very high visibility and a disproportionally small perceived value. Signing up to the role either took lots of persuasion, a real passion or unfortunate naivety.

Try to be understanding of a sponsor who appears to want to join the ‘failed projects’ club and help them be better. They mean well.

There are 5 comments

Add yours
  1. David Whelan

    Perfect timing, as we’re about to head down this path at my organization. Although I found myself having to reread a couple to make sure the “My way or the Information Highway” spin was right! Thanks.

  2. Malcolm Scovil

    Fantastic guys, a very fun and thorough “Don’t Do” list. My favs are 1, 3, 4 and 9.

    I see those 4 a lot coming in to situations where large employers have been trying to to engage employees in corporate responsibility and build a culture of “giving back”.

    On 4, that’s always a tricky one in results-focussed sales organizations…what’s your guys take on a short set of non-arbitray intranet metrics that make sense?

  3. Simon Hudson

    Very droll and really rather complementary to one we did focused more on the technical side of screwing up SharePoint:

    Perhaps we should do a double act…

    Your No 3 resonates with me – I have the following Dilbert cartoon on my office wall to remind me much the same:

    My favourites from ours are the percentage spend on design, infrastructure and application.

Comments are closed.