Putting intranet applications at the centre of your intranet strategy

Everything’s ticking over nicely over in Social-town, CMS-ville and in Collaboration City but you really want to take on the world. It’s time for you to follow the money and go head-to-head with those ruffians in the application estate.

Direction summary:

  1. Create a scalable system of governance and standards for all intranet applications to ensure that they are implemented in appropriate ways.

  2. Manage the application owner community, and act as a gatekeeper to ensure that applications you link to from the intranet are good enough.

  3. Build an application directory to support your governance model and to show the right applications to the right users

  4. Look at ways to fix small problems, and propose ways that applications could be streamlined and processes re-engineered to be user-centered.


For organisations, the hard, provable value in most intranets is not in communications, collaboration or social. The massive day-to-day value is in the huge variety of transactional business applications that are accessed via the intranet using a web browser. Everyone knows them inside out. Intranet stakeholders would break a limb to avoid admitting that they belong to the intranet. No, no. They belong to someone else. We only link to them, and here our involvement ends. The users however don’t think like that— as far as they are concerned they are part of the intranet and it is a mystery why they all look like a dog’s dinner.

Everyone got very enthusiastic about intranet applications, err… about a decade ago, and some of them haven’t changed since. Lots of the others have come online mostly using software as a service, with business owners going out onto the open market with a credit card with no one except the procurement department for company. Then they have landed as a link on the intranet. If you are lucky you’ve maybe got a rational way to connect the right people with the right applications in a structured way.

But the brutal truth is that this fractured, tortuous, bric-a-brac-knick-knackery of assembled antiques is how your multi-billion dollar organisation works on a daily basis.

Let that sink in for a moment.

Every conceivable business process from administration, through hiring, firing, managing and paying for people and things, accounting, dealing with customers and suppliers. All of it. All of it ticking on well enough, but with little attention to user experience or to how the next process along works.

This movie needs a director, and that director is you.


Under what circumstances would this intranet direction be a feasible choice?

Most processes are online processes

You will be beyond the first blush of digital enablement of processes. It would be rare if you would come up against a paper process.

If you switched off the intranet, the place would stop working

Ask people the question: “What would happen if the web browsers accidentally disappeared off all the computers one morning?” If business managers go pale with concern, your organisation has a high-dependency on online processes. The good news is that the intranet is highly adopted, recognised and used as a business tool. The bad news is that you could be in trouble if anything goes wrong.

There is widespread dissatisfaction with the intranet application estate

There will be grumbles. People will grouse in the lifts about it come performance management time. People will put off doing their expenses because of the horrors within. IT managers will use phrases like “prehistoric” and “antediluvian” when prompted, or possibly something more authentically and robustly Anglo-Saxon. If you have not got everything under single sign on, the back of people’s notebooks will be a tangle of usernames and passwords, dripping with risk.

Digital paper processes

The old hands will know about how horrific it was to digitally enable of of those essential business processes in the first place. You may find that you have remained stationary in the post-office queue of technological progress. What you have today are your paper processes from a decade ago frozen in time, like a siberian mammoth. The processes themselves have not been refined, streamlined or interconnected.

People find it hard to find the right application

“We have something that does that? I didn’t know.” “I have all of my intranet applications as bookmarks.” Nothing hits adoption rates more than hiding stuff.

The intranet team is not involved in application strategy, choice or delivery

Intranet applications land on you, like a cow in Monty Python and the Holy Grail [Fetchez la vache!]. Thump. The first you heard of it, someone asked for a link. “Hey why are you so angry, it’s like, only a link. Ow, please stop hitting me.”

Guiding policy

Your aim with this intranet direction is provide appropriate structure, guidance and control to intranet applications to benefit users, application owners and bolster the reputation of the intranet as the place to deliver process. You will begin to position the application estate to re-engineer processes to become user-centered.

Come on tail, go wag the dog.

The policy is straightforward — you will control intranet applications. You, as the intranet manager, control the means of connecting the user with the application:

   •    You represent the user to the application owner and application provider.

   •    You will categorise applications and collect data about them and make sure they have owners.

   •    You will be involved in making sure applications are good enough.

   •    You will create standards and a system of control based around a rigorous system of governance

An intranet strategy requires you to focus on its delivery as a priority. This is a big one, and you will need to devote resources for analysis, development and (in particular) stakeholder management. You won’t be able to do other big projects at the same time unless you can get in extra resources for this or to backfill existing tasks.

Application centric as a strategy

You must concentrate on four key tenets:

1. Let governance scale depending on circumstance

This is the big one. As soon so you mention intranet application governance some IT dude with high blood pressure will combust with rage that it just won’t be possible to make his application look like the intranet.

Aaaaand relax. Absolutism is the enemy of useful.

Let governance scale. Create a system of governance that will allow appropriate decisions to be made depending on different criteria. If an application is used by everyone everyday, you are going to want the user experience to be consistent, to wish it to be branded as much as is reasonable, and to make sure it is under single sign on for authentication. If an application is used by a team of twelve in the Doncaster office, you are not going to be fussed about it, but you would like to know about it and to have some metadata that allows to provide a link from the application directory.

2. Manage the application owner community; be a gatekeeper

You are used to dealing with, and controlling, publishers. This is no different, this is the old content management game, but you will need play hardball. The first step is getting comprehensive data on all the systems that are out there, and and getting names for each of them. The second step is providing some standards for application owners within the context of the scalable governance model. The third step is to enforce the controls. This is a long game and will take some politicking and organisational fancy footwork but you have means as you are the gatekeeper.

3. Add value through structure and coherence

As far as the author is concerned the primary purpose of intranets is to provide structure. Providing structure to optimise the employees’ access to complete tasks through processes is then one of your key responsibilities. Tasks have in general been lumped together in massive blobs of similar functionality called an “Application” and applications have their own internal order (or lack thereof).

So your task is pretty easy, categorise all of the applications and show the right ones to the right people. There are a couple of approaches (see tactics below).

Adding metadata for each of these application will again add massive value, both for your administration of the governance model, as well as surfacing ways of finding the right tool for the job to the employee.

4. Fix problems, streamline processes

Once you have whipped the application estate into some form of order, you can start stirring.

Through user testing begin to document and explore where there are significant and provable problems with applications. As you already know the extent to which each application is used (by numbers of employees, frequency and duration) it will be trivial to build business cases to fix them. Make a stink. As an experienced intranet professional you should have the usability and user experience chops to evangelise to development teams and to propose solutions. Help them.

Fixing small problems is however small beer. Once you start looking you will start to see the preposterous lit up with spotlights. The processes that are redundant. The two requests for the same thing that goes to two different teams. There will be pride to bruise, but both you and the intranet could come out shining.


The strategy is the battle and the tactics are your troops.

Scalable applications governance model

Get the governance model written and out there. Not all applications are born equal. Some are exceedingly important to large numbers of people. Some are only used intensively once a year.  Some may be crucial to the operation of the organisation.

Your governance criteria may include:

   •    The number of people who use the application and their geographical distribution

   •    The frequency and duration of use of the application per user

   •    The business criticality of the system (administration through to revenue generating)

   •    Whether the application is internally or externally hosted

   •    Whether the application is available on a mobile platform

Your choices within this model may include:

   •    Providing sufficient operational checks to be entered into the application directory (Mandatory)

   •    Single sign on (Scalable but virtually mandatory)

   •    Branding (Scalable)

   •    User experience (Scalable)

   •    Accessibility (Scalable-ish)

Application metadata directory

The application directory is the hook that the entire of the strategy hangs upon. You need to build (or adapt) a little system. It will be a database of all the applications for the entire company.

It will have all of the metadata you will require to understand:

   •    Who owns the application

   •    The link you need to get there

   •    All of the operational support data you might need. For example has the application passed some some of operational readiness and usability check?

   •    Who the application is for so you can target it to the right profiles

It will also be the switch that will turn an application on, or off. Grey out this switch unless all the other data has been populated. This is a heist.

New applications don’t go live until they have met your criteria.

“Sorry Mr Project Manager, Sir, I understand you are keen to launch, but we just need you to fill in a few bits and bobs. As you were told. Six months’ ago.”

Sane labelling

People within organisations as you know are rather frustrated and bored and they tend to spend a lot of time making up silly names to make themselves feel better. Many of the applications will be called something ridiculous that will make any user’s head bleed if they try and think too hard about what it does. Things like “Discover”, “Laura” “RADAR”, “Pulse” or “IcARuS”. Demented. You might have a fun time pointing this out to application owners. “But everyone knows what IcARuS does!” they will shout, as you uncap your red pen of righteousness.

Rename and be damned, new joiners won’t have a clue. Some of the finest approaches I have seen totally separate what the application is called, and replace it with a task on the home page that links directly to the task within a system. IcARuS might be a room booking system or a mortgage payment calculator. As far as the homepage is concerned call it “Book a room” or “Calculate mortgage payments.” Proper job.


Only show people the applications that are useful to them. Don’t let them wade through a link farm, show them the stuff they have access to, or is most likely to be most important.  For example a common group who have very specific needs are managers.

Many larger organisations will have different intranet applications for different regions, so chop things up based on region or country.

Applications standards

If you don’t have some standards, people won’t follow them.

Standards for intranet applications should be in line with, and reference, the Governance model. Clearly don’t get too hung up on the direct design of the user interface. Buttons is buttons, as long and people can use it successfully and you can judge that with user testing. Lay out expectations about the desired capabilities in an easy to follow format. Remember you are not the IT Strategy team. Remain strictly neutral on technologies used to implement projects, but be firm about usability, accessibility and single sign on.

Single sign on and external single sign on

I remember the days before widespread single sign on. It was horrific. Thanks to the widespread adoption of the the Windows stack (There! I said something nice about Microsoft!) single sign on via Active Directory is encountered in most organisations that I see. Single sign on is in my opinion the single most important aspect of user experience. If you need to remember another password – or even need to reenter the same password adoption rates drop off.

Lack of single sign on causes massive problems for the user and for the organisation. Projects that don’t implement under single sign on should be considered sociopathic pariahs who are shifting work from their project onto the business as usual.

One area we are seeing a threat to this is the burgeoning number of externally hosted cloud based applications. Again project managers appear to think it is OK to for external solutions to have entirely separate authentication mechanisms. Push back and insist that they use an external single sign on solution, which is surprisingly easy to do (I am told) and has massive ROI. If their pet solution does not allow single sign on, and your governance model requires it, suggest politely that they consider alternatives.

Reverse proxy code injection

I would be first to admit that I don’t truly understand this technology, and I am unaware if it is being used in this context, but if you are going to follow this strategy, I would want something like this in my quiver.

Modern reverse proxy servers (for example Nginx – pronounced engine-x) can route traffic from web service and then squirt HTML into the pages that arrive at the browser. This gives an option to transform a service without actually touching the servers or the functionality. Doing this you could insert a banner navigation to all intranet applications so that users could have a more consistent experience. You could also insert tags from your metrics platform, such as Google Analytics, to get an overview of usage. Content delivery systems such as Cloudflare use Nginx to achieve these sorts of things.

Again, my childlike mind doesn’t entire grasp the complexities of the subject, but it could be a useful tactic if you had these capabilities.

Measure and increase task effectiveness

Get a usability analyst with a stopwatch. Do all of those tests and get a time against it. Look at the problems that the test-subjects comes across. Write down their comments, reactions and stories of workarounds. It’s so simple and yet it is never done.

Use insight from that analysis to incrementally design it better, either on your side of the intranet homepage and application directory or working with the application owners to improve their application.

Reengineering existing processes

Not so much a tactic, more of a quest to crush organisational mediocrity.

When you become familiar with the intranet application estate, some of the processes will very clearly be ineffective. They will have been centred around the process and the originating teams that have created them, and will not have the user and their experience at their heart.

You don’t own these processes, but you can become the facilitator, the matchmaker, the opener of doors. Make some proposals to application owners about how their processes could be optimised. They will probably agree, but say they haven’t got budget. But you’ve planted the seed and it will however be on their mind the next time there is an upgrade. Or go for it, build the business case and take it to the big boss and see what he says.

Chris Tubb November 2013

Steve says:

“Going application-centric is the way to go if you want to make your intranet into, dare I say it, something approaching an integrated and advanced digital workplace… In terms of prioritising which applications to integrate I still think HR should be an important component of whatever you’re doing.  In fact HR sections of the intranet, particularly in global conglomerates, are usually mini- application centric microsites  in their own right.

If there are three things to remember in this Direction I’d say a) Single Sign-On is sacrosanct b) Having scalable governance, perhaps with a sense of which elements to prioritise,, brings a sense of realism of what can or cannot be done, and stops an all-or-nothing view which can sometimes stymie action  c) Remember as more applications are routed through the intranet it adds more value. If an application owner doesn’t want to play ball, then that’s their problem, not yours. They are the ones who are losing out.”