Building Site House Building Under Construction

Should you buy or build your intranet?

In 1993 I had a custom-built computer. And it was great. I could choose the 386 processor and 16MB RAM to meet my expectations and budget. And it suited me perfectly. As I watched photos load a line of pixels at a time and it blew my tiny little mind.

But would I do it now? Hell no. I go to the Mac store and choose between the space grey and the rose gold because it does everything I need it to and more.

The same is true of your intranet. You could build it, and in doing so you could make it perfectly meet your needs. But, really, can you be arsed?

In this post I’d like to explain why it’s almost certainly a waste of time and money.

People used to custom build intranets because the options to buy them were all rubbish. My very first blog post for Intranetizen was about how custom development is easier than ever, so why not build something perfectly customised.  What the internet theorist Clay Shirky called Situated Software (yeah, I was in my frustrated pseudo-academic phase).

But that was then. The market has moved on, providing a wealth of flexible options that you can buy, configure and have running pronto, meeting almost every possible user need. So why bother?

Fans of spending hours logging Jira tickets might say “but this way we own our own code!”

Sure, but you also own your own problems; buy it and it’s someone else’s problem.

You might also say “but by developing our own we can find solutions that precisely met our user needs”

Are your user needs really that special? Really?

Let me give you an example. I was asked to spec some development for a customer service team. The department head realised they had some engagement issues so wanted a feature where people could click a smiley face or sad face to express their mood, and it would provide less-than-helpful advice like “why not listen to your favourite song?”.

Sure, we could build this but really… should we? It’s a fundamentally terrible idea that uses intranet development to address an issue that’s better handled in a thousand other ways.

For development work to be worth doing it needs to deliver a return of at least what you spend on it. Very little bespoke intranet development really does this.

If you’re asked to build something custom, focus on the user need, the outcome. What are they trying to do? Then ask yourself – what are the ways I could do this? The easiest answer is almost never to Build A Thing.

Take Grand Designs. People want the perfect house, so they set about building it. They bring in an architect, find a builder and an organic polished concrete worktop supplier from Abergavenny.

And sweet Jesus that 3D rendering is bloody gorgeous.

Two years on – or after the ad break – they’re still living in a caravan looking over their custom-built foundations. The project manager’s left. They’ve identified human remains as they’ve excavated. But now they have a screaming baby, they’ve run out of money and have asked their dad if he’ll remortgage his house. And it’s raining.

When Kevin McCloud goes back to see the finished article five years later, I’m sure we’d agree it’s a beautiful house. But my god have they aged. And when he asks if they’d do it again they always say no. At the end of the day it really wasn’t worth it.

They could have bought themselves a nice Victorian mid-terrace Sharepoint, whacked on a Beezy extension and garden office and done something more worthwhile with their lives.

The same goes with intranets. At the end of it all that palaver you could have the perfect intranet. But in the meantime you have two years of arsing about without the intranet your organisation actually needs. And in that time your frustrated users have – I guarantee – adopted all manner of shadow IT solutions, because if your question for perfection you’re not helping them to do their jobs.

Finally, can you really resource it? You might have that in-house development team now. But will you in a year? Two years? How can you be sure they’re not going to have their focus moved to the website or whatever shiny system has the COO’s eye? And if they do, how will get your user stories prioritised to keep this bastard up to date?

And then you face seeing your precious site atrophy. And you’re divorced and living in a caravan. Is that what you want? Is it?

Unless you work for Facebook, in-house teams are by definition smaller and less experienced than that you’ll get from a vendor. You’re not going to get the depth or breadth of expertise to deliver truly top-notch functionality with a small in-house team.

You only have to look at Etsy to see that ‘artisanal’ doesn’t really mean better. I mean, in theory I could log and pulp my own trees but I’m not too proud to buy toilet roll.

And after 15 years in the intranet space I’m not too proud to buy a great product and save myself a lot of arse-ache.

This post is adapted from Sharon’s debate-opening talk at IntranetNow, the UK’s leading intranet conference. All four Intranetizens attended the summer conference last week and wholeheartedly recommend. The next conference is in October and we hope to see you there.




There are 2 comments

Add yours
  1. James Dellow

    Pick the right intranet solution and you can still configure/extend without building from scratch, but with less risk/effort (although always some element of trade off I’d admit). The other thing with buy these days is that’s mostly cloud with “evergreen” functionality. Anyway, when people say “build” they are really saying, we spent a truck load of money on the front-end and some functionality on top of a bare bones CMS. Few people actually really build – i.e. like the Grand Design episodes when they build a house out of mud, straw, and old car tyres

  2. Simon Thompson

    If you’ve ever become caught up in an intranet project deadlock between HR, IT, Comms or some other part of a business, you’ll know that organisations have a tendency of slowing things down, and making (and compounding) mistakes.

    For me, the great benefit of an intranet-in-a-box solution is that it removes multiple layers for making those mistakes. There is less scope for arguing over high-concept designs, there are tools that will meet many user needs, and there is a tried-and-tested natural shape to the tool and its sections.

    What’s important, to me at least, is to maximise learning at speed, and learning from mistakes is part of that process. If you can build a decent first-attempt without exhausting energy, budget or good will, then you’re on your way to an improved next version.


Comments are closed.