Intranet Project Names - some ideas

"What's in a name? That which we call a rose
By any other word would smell as sweet."

In this famous quote from Act II of Romeo and Juliet, Juliet tells Romeo that a name is an artificial and meaningless convention, and the fact he is a Montague and she a Capulet (warring families) means nothing to their love.

However, there is some strong evidence from the UK's Cranfield University - and elsewhere - that the name one gives a project does have a marked impact on the behaviour and motivation of the people involved. It may surprise you, but the name you give to your Intranet Project could well be the most important decision you make in the early stages of mobilisation!

The Direct Approach

There is an argument in favour of naming your Intranet Project the - wait for it - "Intranet Project"! Often, so-called "secret squirrel" names (where one has to ferret out from colleagues what Project Banana is all about) serve only to create an unnecessary air of mystique (fit only for secret M&A projects). They can also serve to be divisive, by separating 'people in the know' from people outside the immediate project audience.

The functional approach

A functional name focuses on what the intranet does (e.g. search, find, access). This enjoys the same benefits as the direct approach, but affords one a little more poetic license. What about names like "Project Connect" or "Project Gateway", which serve to signal the core "must have" requirements for the project?

The conceptual approach

There is a problem with the direct or functional approaches; Research from Cranfield has demonstrated that people on projects tend to be very heavily influenced in their actions by the name of the project itself. If you call your project the Intranet project, it is a working intranet (i.e. the technology) that you will get. If your ambition was something much more visionary, such as a wholly new way of working for your people, you are likely to be disappointed!

The conceptual name targets what is achieved by the functionality, rather than the functionality itself. For example, if your company name was BigCo and your purpose was seeking to get everyone in the company working together, you could call the project "Project OneBigCo" or "Project Unity". For the aforementioned new ways of working objective, you could use "Project Future Workplace".

The abstract approach

The abstract approach deals with how the project makes people feel. For example, "Project Bliss" (for happiness), "Project Wizard" (for magic) or "Project Pulse" (for fast-pacedness). Although one world usually fails to capture all you are trying to achieve with an Intranet Portal, this approach can prove highly effective (particularly where counter-cultural).

If all else fails

Nothing grabbed you so far? Well there is no saving you, then! I suppose there are always the standard fallback options: names of greek or roman gods, names of planets, names of birds and names of dances. These have the added value that - if you spawn follow-on projects in a sequence - you have ready-made logical follow-on project titles. Incidentally, "Project Mercury" would be my recommendation for planets or gods (as Mercury was the roman god of communications).

For more ideas on project names, why not check out my presentation in the Intranet Portal Guide.

About the author:
David Viney (david@viney.com) is the author of the Intranet Portal Guide; 31 pages of advice, tools and downloads covering the period before, during and after an Intranet Portal implementation.

Read the guide at http://www.viney.com/DFV/intranet_portal_guide or the Intranet Watch Blog at http://www.viney.com/intranet_watch.

Intranet Portal Project - RAD or Waterfall?

In this short article, David Viney examines whether Rapid Application Development (RAD) or Waterfall development methodologies should be used during Intranet Portal projects.

Building bridges

I have often used the analogy of building a bridge to explain to business colleagues the difference between RAD and Waterfall.

Let’s say that we are in the middle ages and the Mayor of Kingston-upon-Thames is evaluating whether or not to build a bridge over the river to the north side, to replace the current ferry. The whole area has been growing rapidly and a bridge at Kingston should give his town a lead against competing local towns like Ham and Richmond (who also have their own ferries).

However, building a bridge presents problems. Firstly, the bedrock north and south of the river are very different. Secondly, the river is still tidal at this point and its path continues to vary across the floodplain. Finally – and perhaps most importantly – there is no guarantee that the projected growth in cross-river traffic will indeed materialise – or that people will wish to cross at this precise point, rather than further up, or down, river. A new bridge could prove an expensive white elephant and divert much-needed town resources away from other projects. The increased local taxes required could also scare the very businesses he is hoping to attract away to other local towns.

Option 1 - Waterfall

Waterfall, as a methodology, is all about building reliable systems. At each stage of the lifecycle, the results are correct. The Mayor’s engineer believes that - when building a bridge - the result needs to be safe, sound and capable of lasting for decades. He recommends a design phase, which includes thoroughly testing the bedrock by driving piles and developing ways to limit the future variance of the river’s course. During the build phase, the bridge would be tested to ensure it can take the loads that will be placed upon it and to deal with high winds or flood conditions. The engineer confirms that each stage would only start once the previous stage had been proved correct beyond reasonable doubt. The stone bridge will take five whole years to build (with a high upfront cost commitment). If the project were ever stopped, the value tied up in phases to date would be lost. The engineer reminds the Mayor that a collapsed bridge would not help his place in history!

Option 2 - RAD

RAD, as a methodology is all about building relevant systems. The argument runs that it is better to be there quickly with 80% of the functionality in 20% of the time, so as to take full advantage of the business opportunity. The Mayor’s political advisors recommend the RAD option; to lay a pontoon bridge first alongside the existing ferry. This can be achieved in just three months, using a series of boats with a makeshift road surface and swing bridge lock for river vessels to navigate. The pontoon bridge allows the business model to be tested very quickly; If the expected benefits materialise, then further iterations of the bridge can be constructed later on. Sounds good, but of course (overall) the costs will be higher than waterfall if a full, stone bridge is ultimately required. In the meantime, if the river changes course, or floods impact the area, then the pontoon bridge will be washed away. His chief advisor reminds him that a bridge five years from now would not help his re-election prospects two years hence!

The Mayor’s selected option

Hmm. Interesting, isn’t it. Not a clear-cut decision. There are good arguments for either approach. The Mayor’s decision will ultimately depend on (a) how sure he is of his own vision, (b) his financial and time constraints and (c) how changeable these factors are likely to be over time. In short, he has a trade-off decision of relevance vs. reliability.

Turning the analogy onto Intranet Projects

In chapter 16 of my Intranet Portal Guide, I explore these concepts in a bit more depth.

However – put simply – the answer for you will depend largely on how sure you are of your vision, the support of stakeholders, the availability of resources and the degree of change in your organisation and it’s requirements.

If you are operating in a stable business environment and are well funded and supported, then waterfall offers real benefits. You could establish an Intranet Portal that is well founded, scalable and secure. If not, then RAD could offer you the means to make some progress now at low cost and use the results of your early work to build a stronger case for future investment. It also allows you to vary the approach – or begin again – should circumstances or requirements change.

Most Intranet evangelists will find themselves perhaps in a mixed situation, where there is support and funding but there is also the risk of rapid changes to the underlying business environment and requirements. Here, I would recommend a mixed approach: Use a waterfall project to establish the underlying portal infrastructure (as this platform will be the bedrock on which you will build and needs to stand the test of time). Then use a RAD method to build the content and applications (developing solutions that are timely and relevant to businesses operating in a fast-moving and competitive environment).

About the author:
David Viney (david@viney.com) is the author of the Intranet Portal Guide; 31 pages of advice, tools and downloads covering the period before, during and after an Intranet Portal implementation.

Read the guide at http://www.viney.com/DFV/intranet_portal_guide or the Intranet Watch Blog at http://www.viney.com/intranet_watch.