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 – Business Case ROI

Intranet Portal – Business Case ROI

by: David Viney

The days of easy money are over

In these postdotcom days of the 21st Century, the hype attached to IT is well and truly over. The modern Board is deeply suspicious of large IT projects with questionable benefits and a longterm payback period.

The good news is that a worldclass portal implementation has the power to completely transform your organisation and touch everyone, from the office of your CEO to the lady in the canteen.

First a little on Costs

Sorry, but the cost of the software is only a relatively small part of the overall bill; with other major costs in hardware, process change and integration activities. Your first (and major) portal project is (in terms of cost) more an infrastructure investment than it is an application.

As a rough rule of thumb (for a user base >10,000), budget for £250 per desktop to put in the essentials (including portal and content management solutions). If you are also integrating to (and exposing) your ERP or CRM systems, add £150.

Direct Benefits

Based on my experience, Direct Benefits (those that you can directly bake into line budgets and make an individual directorate accountable for realising) are only 2025% of the total prize and will not generally cover the portal implementation costs by themsleves. Direct benefits include reduced printing and distribution costs, decommissioning legacy intranets and FTE savings in operational areas (including IT development & support, Finance & Procurement ledger processing and HR employee services).

Soft Benefits include improved employee satisfaction, better communication and corporate belonging, the importance of which should not be underestimated in your business case. After all, there is always an emotional, as well as a rational, reason for every purchasing decision.

However, the bulk of portal benefits are Indirect Benefits, where time saved in line areas leads to (for example) reduced call times in call centres, higher sales, faster time to market for new products, fewer failed projects and so on. Benefits realisation is the issue with such benefits. After all, you can’t fire 10 minutes of a person a day! The time they have saved is real ultimately saving cost and driving sales but it cannot be readily tracked to either.

Making the Business Case: A 10 Step Approach

In chapter 8 of my (free to access) Intranet Portal Guide (see http://www.viney.com/DFV/intranet_portal_guide/before/business_case.html), I outline a 10 step approach to making the portal business case.

1) Seek External Legitimacy

Consider using a leading consulting firm to lend weight to the business case. They can bring with them experience (from having done it before elsewhere), a knowledgebase (of facts and figures about the benefits other companies have achieved) and a fresh perspective on your organisation, valued by executives.

2) Benchmark other Organisations

I have included in my guide details of publicdomain benefit claims from early UK & US portal adopters, including British Airways, BP, Ford Motors Company, IBM, Bell South, Dow, Cisco and BT. Showing your Board that others have delivered real benefits lessens the feeling that their decision is a ‘leap of faith’.

3) Collect Hard Metrics

Direct benefits may be only 1525% of your total benefits, so work hard to identify savings in Intranet & Collaborative decommissioning; Print, Postage & Distribution Costs, Processing Manpower reductions; and Third Party expenditure savings.

4) Use a Comprehensive Time Survey

In my guide, I suggest that you survey several hundred (representative) users to establish how much time per day they expect to save by using key portal functionality. This will help you to put a financial value on indirect benefits. I outline 10 sample questions and provide benchmark results you could expect to see.

5) Build a Wall of Benefits

When you are trying to build an ROI based on indirect benefits, you can expect those benefits to be challenged vigorously. By having literally hundreds of individual line items and a big overall total, you improve your chances of surviving the Finance ‘Red Pen’. In my guide, I outline 101 benefit ideas to get you going.

6) Link to the Strategic Agenda

Tie the investment closely to the Strategic Agenda of your organisation. If there is another key initiative currently grabbing all the attention at board level (e.g. CRM or ERP) then make sure your portal case complements, or ideally completes, that strategic picture. Use camaoflague if necessary, as all is fair in love and war!

7) Identify 23 Killer Apps

That will focus the attention (and support) of key sponsors. Look for winwin apps, where the user loves using them but the provider department also extracts key benefits. For example, a selfservice HR application where the employee can keep their details uptodate easily and the company can reduce employee service heads.

8) Use a Cost Avoidance Argument

Your investment will reduce future project costs. After all, a portal is essentially a free infrastructure, a free user interface, a free user client with prebuilt security & authentication and a free development framework. HP and others have saved up to 20% on development costs, postimplementation. You could too, so raid the budgets of other approved projects!

9) Consider Larger Scope

Could you make your case if you include internet and extranet in scope? An extranet allows you to securely expose part of your intranet to slected third parties, including B2B customers, suppliers, regulators and government agencies. The incremental cost is quite low, once your intranet platform is there, but the benefits can be large!

10) Use Innovative Phasing

Most companies budget on an annual cycle and are under huge pressure from investors to deliver shortterm profitability. The bitter pill of portal costs might be easier to swallow if you spread the implementation over a two year period.

Conclusions

Making the business case for a corporate Intranet Portal will not be easy. You will need all your reserves of patience, cunning and good olffashioned hard work. Good luck and don’t forget to check my guide for more detail, help and tools.

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 December 08, 2004

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