Intranet Project Names Some Ideas

Intranet Project Names Some Ideas

by: David Viney

ก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 faour of naming your Intranet Project the wait for it กIntranet Projectก! Often, socalled ก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 fastpacedness). 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 countercultural).

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 followon projects in a sequence you have readymade logical followon 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.

This article was posted on November 08, 2004

by David Viney

Managing Project Risks and Issues

Managing Project Risks and Issues

by: David Viney

What is the difference between a project risk and a project issue and what different types can I expect to encounter? What tools can I use to manage the risks and issues on a Project? This article offers some possible answers, drawn from experience on Intranet Portal deployments and the PRINCE methodology.

Inherent (or Business) Risk

Inherent Risk is the risk that exists in the environment around your portal project. It will tend to be unique to your organisation; itกs culture and politics. For example, if you have a fragmented business (either geographical or functional), then this will create a higher inherent risk of poor communication.

Project (Specific) Risk

Project Risk is the risk specific to your project. Some Project Risk stems from the nature of what you are doing; there are certain risks common to any project (e.g. the unfamiliarity to users of the technology you are deploying). However, most project risk is under your direct influence; for example the skills of the project team, the level of governance effectiveness and so on.

Stage Risk

Finally, there is กstage riskก which is the risk associated with the particular activity of any given phase of the project plan.

The Risk Log & Risk Plan

In order to stay in control of the risks to your portal project, it makes sense to have a formal log of all risks, to which anyone involved with the project is entitled to add. You might use a formal workshop to first populate the log.

Assessing Risks

Each risk (however derived) can be assessed using a simple methodology, whereby the probability of the risk being realised (กlikelihoodก) and the size of the impact on the project objectives (กseverityก) can be measured.

The simplest system (based on the PRINCE project management method) is to give a score of 13 for likelihood and severity (where 1 is low and 3 is high). From these scores, the importance of each risk can be measured as the product of likelihood and severity.

Clearly, any risk of importance 9 demands immediate attention, followed by risks rated 6 and so on.

Risk Countermeasures

The importance of each risk should be regularly maintained, based on the extent to which the likelihood and severity of impact change over time.For each risk, one should enter a countermeasure in the risk plan. Where a risk can be eliminated, then this will be the countermeasure. Where it cannot be fully eliminated, then risk mitigation actions will be the most appropriate.

Issues Log

A Risk is something that is yet to happen, whilst an Issue is something that has already happened. It may well be convenient to use the Risk Log to also track any issues on the project. Issues will generally fall into one of the following categories:

(R) Request for a change (in the scope of the project)

(O) An item has been identified that is OffSpecification

(Q) A Question has been raised that needs to be resolved

(S) A Statement of Concern has been raised by someone and

(I) Other issues.To score issues, just ascribe an importance score (of between 1 and 9).

Managing Risks and Issues

Once you have put a Plan in place, then it is important to regularly monitor and report on the countermeasures that have been deployed and whether or not they have been successful in reducing the overall risk profile of the project.

For templates and examples of risks and issues pertinent to intranet portal deployment projects, please check out my chapter on Risks and Issues (see http://www.viney.com/DFV/intranet_portal_guide/during/managing_risks_issues.html) in the (free to access) Intranet Portal Guide.

If you act, manage and report regularly on risks and issues, you will have substantially improved your chances of project success!

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.

This article was posted on March 27

by David Viney

Intranet Portal Project RAD or Waterfall?

Intranet Portal Project RAD or Waterfall?

by: David Viney

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 KingstonuponThames 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 crossriver 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 muchneeded 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 reelection prospects two years hence!

The Mayor’s selected option

Hmm. Interesting, isn’t it. Not a clearcut 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 tradeoff decision of relevance vs. reliability.

Turning the analogy onto Intranet Projects

In chapter 16 of my Intranet Portal Guide (see http://www.viney.com/DFV/intranet_portal_guide/during/development_methodology.html), 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 fastmoving 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.

This article was posted on November 01, 2004

by David Viney