Don’t let your project plan and governance, become your intranet strategy and governance (or why Intranet stakeholders are your BFFs)

A quick one, but worth repeating.

Your intranet is a complex array of browser based systems and services. They are tangled together like spaghetti alla crazy glue. Your users don’t really get the idea that one bit is owned by one team, and another bit is owned by a different team; nor should they care.

If it has been a bit of a mess the reason is usually that collectively the idea of the intranet has not been a strong one. One day there is enough embarrassment-in-common amongst the great-and-the-good that something-must-be-done. “We need a project to build a new intranet,” they say. A project manager is found. Requirements are gathered. The PM rounds up a strange breed of people called “Stakeholders”, who presumably know what they want. The project starts to fly and some structure is thrown over the rhubarb-muttering crowd like a hopeful fishing net. That net is called “Project Governance” and it attempts to bring some structure to the panicky madness that is a large scale IT development project.

After a bit of monkeying around with Gantt charts, test scripts and usability testing the intranet is handed over to the people that will put content in it and content is poured into it like beer into a tankard. Champagne corks are popped that everyone has a little party, and the PM rides off into the sunset. His work is done here. The development team go and work on something else.

The governance, of course, falls apart because the project is over. The stakeholders drift away. The intranet degrades, until the next time. Then people like Steve and me shuffle onto the scene. We ask if there is an intranet strategy. Small voice: “Not really. Just ideas you know…” Mumbling. Staring at shoes. Is there a steering group. “Used to have one…” Governance model? “Pfffft…. Wild-west, innit.”

There is a better way, people…

Of course what you really need to do is to sort out the strategy and governance to scope, define and set a roadmap for the future. The projects can then fall within this framework.  So…

1. Get a group of people together who are accountable and engaged about the intranet. They will want to use it to drive business outcomes with things like “efficiency”, “engagement” and “knowledge”.

2. Get them to figure out a vision and a plan for the whole intranet – from tip to tail, from the top of the tallest shiniest news story to the dark and dingy team sites. No site left behind.

3. Get them to assemble a way of everyone working together: a governance model that encompasses anything that people might conceive of as the intranet. Let it scale.

Then start creating projects to deliver a bit of the intranet vision. Any project you create should be part of an overarching plan to deliver your intranet strategy. Your intranet “project”, even if it is huge and transformational should be initiated and accountable to your intranet steering group.

There is a better way: PEOPLE

Your intranet isn’t SharePoint. It is a idea that brings unity and structure to people, places and things. Your vision, strategy and governance aren’t just documents. They are held in place by the people who are involved and invested in it. No people, no belief, no mandate, no strategy.

Il faut cultiver son jardin, dagnammit.

If you are in this horrific groundhog day of big-bang project, followed by cold-tea ambivalent mediocrity and eventual and inevitable failure, you can break the pattern.

Save and close that Word document, get up from your desk and go speak with your stakeholders. Bond with them. Give them a reason to believe in a cheery future and your intranet’s place in it. The belief starts with you, and when someone asks what platform your intranet runs on, point at your intranet steerco and say: “Those guys.”

Steve says:

Far too often intranet  strategy comes grinding to a halt for various reasons and then gets revisited when its big project time. The danger then is intranet governance and project governance overlap and become indistinguishable. Sure there are similarities – some of the same stakeholders  are almost guaranteed — but its what happens when the project is over that worries me. It’s amazing how  everybody abandons ship the day after launch. Chris is right,  Keep them distinct, otherwise you could be heading for trouble.