Intranet Portal Guide - Intranet Watch

Intranet Portals - Search and Taxonomies

Knowledge Management for beginners

Knowledge Management (KM) can be defined simply as the process through which organizations generate value from their intellectual and knowledge-based assets. Knowledge assets are often grouped into two categories:

(1) Explicit Knowledge:

Generally, everything and anything that can be documented, archived and codified. Examples include patents, trademarks, business plans, marketing research and customer lists.

(2) Tacit Knowledge:

The rest. Tacit knowledge is the know-how contained in people's heads. The challenge inherent with tacit knowledge is figuring out how to recognize, generate, share and manage it.

Most often, generating value from such assets involves sharing them among employees, departments and even with other companies in an effort to reach – or go beyond - best practice. For explicit knowledge, the focus can usefully be described as “connecting people to things”, whilst for tacit knowledge, the focus is “connecting people to people”.

Search technologies made simple

There are essentially two types of search technology: structured search and unstructured search:

1) Structured Search:

In a structured search (example Yahoo) the user clicks down through a directory of categories to find the material sought. The tree structure of the directory is called a taxonomy, with a root node at the top that applies to all objects and nodes below that classify more specific subsets of the total set of objects. A well-known example of a taxonomy is Carolus Linnaeus's Scientific classification of organisms. The root node is (implicitly) “organism” and nodes below are Kingdom, Phylum, Class, Order, Family, Genus, and Species.

In Yahoo, the root is “Directory” and there are 14 main nodes, including Society & Culture, Social Science and Reference. If I were searching for best man’s speech tips (which I was not so long ago), I could try (on Yahoo) clicking down the branch of the tree: Directory > Society and Culture > Weddings > Speeches and Toasts. Alternatively, I could try Directory > Social Science > Communications > Public Speaking.

There are obvious pros and cons to structured search. The main con is that I might head down several blind alleys on the tree before finding the most useful branch. The main pro is that – once I have found that branch – I am likely to find a whole collection of relevant material gathered together in one place.

For the librarian (maintaining the taxonomy), there is another key con. As our wedding example illustrates so well, there are often two or more places one could put any given information. Oh the agonies of choice!

2) Unstructured Search:

In an unstructured search (example Google) the user enters a series of keywords into a search engine, which searches an index of content (regularly crawled) and brings back results, ordered by closest match to the search string.

The main pro of an unstructured search are that I do not have to second-guess where the right branch is on the taxonomy tree, but rather leap in at the leaf I am looking for. The cons are rather less obvious and the main one is that some materials I might actually find very useful may not come up in the search. This can be due to my poor selection of search terms, deficiency in indexing / search algorithms or poor metadata in the content itself.

Should I implement search functionality and, if so, how?

Search invariably scores well on any prioritisation of intranet functionality and is generally “out-of-the-box” with your portal solution, so I would definitely recommend you include it in the scope of your project.

It may not surprise you to hear that the most effective search implementations allow the user to chose between structured and unstructured search options and to easily navigate between the two. For example, my unstructured Yahoo search on “best mans speeches” takes me straight to a relevant document, but also tells me where it sits in the directory. By clicking on the directory category, I can bring up all the other materials in that area (where I ultimately find the best resource for my need).

To implement the structured search part of your solution, you will need to develop a taxonomy structure for your organisation and the information resources your people need to do their jobs. This can be quite a challenge! For example, should an HR grievance policy be found under ABC Co > Human Resources > Employee Services Unit > Policy or under an ABC Co > My Employment > My Rights > Grievance branch?

My advice is to keep it simple and give it room to evolve and change. An ideal taxonomy should be flat and broad (having no more than three levels) and should suit the provider or creator of information rather than the user of it (as they are the people who will populate your library and you need it to be easy for them to do so).

To ensure the unstructured component of your solution is effective, you need to ensure firstly that people avoid jargon in the body of their documents (using instead keywords that users will recognise) and secondly that a high percentage of documents contain decent metadata. Metadata can be simply defined as "data about data". For example, the grievance document metadata might include author: Tessa Jones, job title: Employee Relations Officer, department: Employee Services, function: HR, subject: Employment, title: Grievance policy.

Can search help with tacit knowledge sharing?

Absolutely! Many organisations fail to recognise this. Connecting people to people (for that 10 minute telephone conversations that could save a week’s work) is often much more valuable than storing documents.

You should create a well developed yellow pages database, where people have entered augmented their white pages details (job title, email address, telephone number) with information about their skills, experience and interests. Then – when someone searches for grievance – in addition to (a) the word document policy, the results also include (b) a link to Tessa Jones’ Yellow Pages entry and (c) a link to the Employee Relations teamspace, where Tessa – and her line colleagues across ABC Co – collaborate on policy development and employee relations management.

Some final thoughts

The humble search function can be the most powerful agent for improved knowledge management your organisation has ever invested in. By extension, therefore, it can become the definitive “killer application” on your intranet portal. However, it is vital that the search capability can acccess all the information and people in your organisation and that result relevancy is high. This is not as easy as it sounds and requires proper planning and detailed work.

Intranet Portals - Personalisation and Customisation

The key difference between an (old-fashioned) Intranet and a Portal

What typifies a modern intranet portal is that there is a standardised user interface (“UI”) with a built in system for user authentication. In other words, the user signs in to the portal rather than simply accessing it. This brings us to the key difference; an intranet portal knows who you are, whilst with an old-fashioned intranet, the user is anonymous.

If the user authentication is properly linked to your employee data, then the portal will know things like (a) what grade the person is, (b) which department they work in, (c) what location they work at and (d) what job they do.

If the portal authentication is also liked to a metadirectory (along with the authentication for all the other systems the user needs to use in their job) then the portal will additionally know (e) which applications the user needs to do their job and (f) the rights the user has (from their security profile) to access different application functionality.

Finally, if an infocube-based web statistics package has been installed, the portal will know (a) which areas of the portal are accessed by the user and (b) the frequency and depth of that access.

The opportunity to personalise the portal experience

Clearly, given the knowledge above, it is possible to personalise the UI for each individual user. For example, if the user works in the sales function, then the homepage that greets them upon logon could be the Sales team homepage. If they work in Leeds, the facilities link on their homepage could be to maps, traffic, fire orders, etc. about the Leeds office (rather than anywhere else). If their specific job is as a field sales manager, then field sales performance graphs and management dashboard could be displayed on the homepage.

If the user is of a grade that places them on the company insider dealing list, then additional (price sensitive) real-time data might be displayed on the screen (which other users would not see). If statistics tell us that they are not reading important communications, then messages could be served to them that draw their attention to what they are missing. Finally, if they use functionality from three different (legacy) systems to do their job, then these could be brought together and surfaced via a portlet application on the portal page.

The prize is clearly a smoother and more integrated user experience, with key information “pushed” at the user in a way they can’t ignore and always no more than a single click away.

The depressing truth about personalisation today

Many portal vendors have undertaken research with their existing customer base to explore (a) how many customers have made extensive use of personalisation and (b) how many surface key business applications via their portal. The results do not make encouraging reading (with less than 20% achieving much beyond what Plumtree call "the empty portal").

This prompts an obvious question. If the benefits to the user of personalisation are so obvious, why have companies not taken advantage of them? In fact, based on my experience, there are multiple reasons not to personalise, which I group into “bad” and “good” reasons.

Bad reasons not to personalise

There are a number of typical failings that tend to stem from a lack of courage, poor understanding or personal prejudice:

1) Failure to link through to employee data and/or a metadirectory
This can be due to a number of factors, including (a) the costs of software seen as too expensive, (b) a perception that implementation will be too difficult or prone to failure, (c) a lack of confidence in the quality of employee data and (d) realising too late that this work is important and having failed therefore to include in project scope or business case costs

2) Failure of vision and/or lack of confidence in personalisation benefits
Typical problems include (a) a lack of experience of using portals and thus a lack of awareness of the possibilities, (b) a nostalgia for the old-fashioned style of intranet navigation, (c) an unhealthy focus on the intranet simply as a communication channel, rather than as a business tool and – perhaps most interestingly - (d) a perception that personalisation is synonymous with (or otherwise encourages) individuals failing to observe and comply with single, enterprise-wide processes and policy.

Good reasons not to personalise

There are actually several valid objections to personalisation, which you would ignore at your peril. The two most notable are:

3) The whole is more than the sum of the parts
Many portal projects are built on the concepts of (a) increased knowledge sharing between teams, (b) better awareness of the “big picture” of what is happening in the company and (c) a sense of belonging to a single, enterprise-wide community. By personalising teams and individuals into “ghettos” where they only see information and applications directly relevant to them, the opportunity is lost to have them explore the intranet presence of other colleagues.

4) Log-in as a barrier to user adoption
A (valid) concern that requiring people to log-in each time they access the portal will act as a deterrent to them doing so, thereby reducing the portal benefits through a reduction in intranet usage. This has lead to some customers disabling the log-in feature! Of course, such problems can be overcome through the implementation of a single sign-on application, where rights to access the portal (without a separate log-on procedure) are granted when the user logs onto the network. However, companies often fail to plan or budget for such changes.

So is personalisation the right thing to do? If so, how can I make it happen?

On balance, of course, the benefits of personalisation, for most organisations, far outweigh the risks and costs. After all, why buy a Ferrari, then only use it to do the school run? If you were never going to use the portal for these advanced functions, why did you buy one? It would have been much cheaper to invest in your traditional intranet!

If you are looking to make it happen, however, you must recognise the organisational, financial and technical challenges inherent in the work. Firstly, you should ensure that your business case contains the full costs of integrating the portal with employee data and metadirectory capabilities. Ideally, you should also extend this to a single-sign-on solution if you can afford it.

Secondly, you should showcase to sponsors what personalisation looks like, so that they can improve their understanding of the opportunity. Finally, you should not underestimate the technical grunt work involved in cleaning up your employee data and systems rights.

Do not neglect customisation

I define customisation as the ability for users to customise their own portal settings and appearance (as distinct from how I am defining personalisation, where the portal provisions information and applications authomatically, based on the user’s profile). By letting users “do it themselves” you allow for the possibility that they may wish to share knowledge and collaborate with people outside their immediate role. You can also learn (by observing their behaviour in customisation) where you could improve upon your personalisation.

Some final thoughts

Personlisation should be a key element of your early visioning work with sponsors and drive costs and benefits in your business case. If you find at that stage that the return on investment (ROI) is not there, then you should perhaps question whether a portal investment is really for you! A mini is adequate, after all, for the school run!

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 Portals - Collaboration through Team Rooms

Knowledge Management for beginners

Knowledge Management (KM) can be defined simply as the process through which organizations generate value from their intellectual and knowledge-based assets. Knowledge assets are often grouped into two categories:

(1) Explicit Knowledge
Generally, everything and anything that can be documented, archived and codified. Examples include patents, trademarks, business plans, marketing research and customer lists.

(2) Tacit Knowledge
The rest. Tacit knowledge is the know-how contained in people's heads. The challenge inherent with tacit knowledge is figuring out how to recognize, generate, share and manage it.Most often, generating value from such assets involves sharing them among employees, departments and even with other companies in an effort to reach – or go beyond - best practice.

Where Collaboration technologies can help… and hinder

For explicit knowledge, the focus can usefully be described as “connecting people to things”, whilst for tacit knowledge, the focus is “connecting people to people”.As such, structured and unstructured search technologies are usually the core of strategies to encourage greater sharing of explicit knowledge; the user searches for a document either by typing some text into a search engine or by clicking through a document taxonomy.

Similarly, a well structured “yellow pages” directory, where one can search for people with particular skills or experience, forms the centrepiece of tacit strategies; where the aim is to connect people often for 10 minute telephone conversations / requests for help that could save a week’s work.Both explicit and tacit strategies are, however, much enhanced when combined with Collaboration or “work-group” technologies. By creating “communuities of interest” around cross-functional themes, individuals can share documents, plans and other material, find and discuss issues with subject-matter experts and even allocate tasks and calendar items to each other.

For example, a community for “customer insight” might have members drawn from call centre operations, marketing and IT teams (to name but a few) who share a common interest in better understanding the customer need. They could each contribute into the team space document repository materials that (once added together) create powerful new insights and possible future revenue enhancement. By sharing, they (a) gather a sense of belonging to a wider network of similarly minded people, (b) gain knowledge that helps each to better achieve their objectives and (c) gain recognition for being an expert in their particular area.

Benefits (for your business case) include: (a) better customer service through improved response times, (b) faster new product development and time to market, (c) enhanced employee retention through rewarding knowledge sharing, (d) reduced Opex through the streamlining of processes, (e) reduced IT network and storage cost growth through a reduction in email file attachments.

There are, however, risks to collaboration, where poorly implemented. For example, if individual community documents are not accessible through the overall portal search, then you risk creating information silos, where only a select few can access information that is of much wider use. Also, part of your portal benefits are likely to stem from people visiting all areas of the site and learning about other departments and teams. If people spend all their time in their own team rooms, the benefits of this wider perspective will be lost.

Typical Team Room Functionality

Most intranet portal offerings contain some collaboration functionality, either (a) as a standalone optional module, (b) as a partly integrated standard portlet or (c) as a fully integrated function, combined with email systems.Typical elements include:

1) Shared Calendar:
The team can maintain a single calendar of notable team events or shared deadlines. Where not fully integrated to email systems, this functionality is sometimes only sparingly used.

2) Discussion Forums:
The team can set up and post to threaded discussions, where issues or opportunities can be fully explored. It can take time for people to really get used to using this functionality and taking such discussions off the email system. A key role is that of the moderator, who can (a) spark new discussions, (b) invite people to join them, (c) deal with any abuse of etiquette and (d) capture and structure the result (e.g. a key decision) before archiving the thread.

3) Shared Documents:
The team can workflow, version control, security protect and store / retrieve documents, including policies, reports, analysis and plans. This functionality is often the most heavily used and of particular value for project teams, where many hundreds of key documents may be created in the course of delivery.

4) Allocate Tasks:
The team can set-up tasks and allocate them to themlseves or other team members. Reminders appear in the team calendar and (where there is email integration) in the email inbox of the task owner. Again, it can take time to get people usign this functionality but – once working well – can be of immense value for teams driving at particular outcomes and deadlines.

Some final thoughts

Collaboration technologies can be a very powerful addition to your knowledge management strategy, complementing structured search and yellow pages functionality. It is important to get the implementation right. In particular, to really think about ways to move people from email to teamrooms (e.g link to files in a teamspace rather than attach them) and to ensure that documents in teamrooms can be accessible via the wider portal search functionality.

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 - The Benefits Realisation Plan

The Millennium Experience

A successful project is one that delivers on-spec ('quality'), time and cost. Right? Well consider these two projects…The Millennium Dome was delivered on time for the 31 December 1999 and safely within a budget (fixed in 1998) of £289 million. The Project was also delivered to quality, albeit against a Specification that had been adjusted several times during the project to simplify the scope of work required (and ensure that time and cost deadlines could still be met). However, visitor number targets were greatly overestimated, the business a total flop and the whole endeavour deemed a failure by many.

The Millennium Wheel (or "London Eye") opened one month late on a dreary February morning in 2000 (following problems raising the wheel and then safety & quality issues with one of the 32 pods). It was also over budget, with building costs of £70m (against the £25m British Airways had originally planned to spend). However, an average of about 10,000 people a day now ride the wheel, making the London Eye the UK's biggest tourist attraction (and generating £15 million of trading profit a year) - a healthy return on investment for the shareholders.

A New Mindset for Change Projects

Traditional methodologies for change / project management (of which PRINCE is an example) tend to focus primarily on time, cost and quality. Benefits are all too often only implicitly recognised and the accountability for realising them is assumed to lie outside the project.

However, the pace of change within our society, industry and business grows ever faster. Somewhat paradoxically, there is an ever-greater need to ensure that changes 'stick' (delivering sustainable benefit and competitive advantage to the organisations making them). Most businesses have already achieved greater efficiency and effectiveness within single functions or processes; The challenge of the 21st Century is increasingly how to realise end-to-end change across a boundary-less business.

Rarely (these days) will a single customer sponsor a single project, delivering a single system into a single department.

The leadership challenge is thus how to engage multiple sponsors and change agents across the whole business to deliver excellence in change and the ruthless pursuit of business benefits and true return on investment (ROI).0

The Case for a focus on Benefits Management

Recent research from the Cranfield University School of Management finds that 78% of IT-enabled change projects (in large UK companies) fail to deliver business benefits. 47% believed assessment of business benefits in business cases was poor or worse and 79% said that all the available benefits were not captured during that assessment. 45% believed benefits were overstated in their organisation to get investment approval.

Arguably, this will only change when project managers and their people become accountable for - and obsessed by - delivering business benefits and value through Change, rather than simply projects to time and cost.

Benefits Defined

Soft Benefits (sometime called "non-quantifiable" benefits) are those intangible improvements to be obtained from a change, including improved employee satisfaction, better customer satisfaction, increased knowledge sharing and re-use of intellectual capital. Whilst it is often accepted that such benefits do lead to financial gain, it is deemed impossible to demonstrate a proven causal link that would enable one to place a financial value on the benefit.

Direct Benefits are those which lead to a measurable impact on the bottom-line of the organisation, including increased revenue, reduced costs of sale / improved margin, operating cost reduction (e.g. through reduced headcount) and improvements in working capital (e.g. through a faster debt collection cycle). An individual or team can be held directly to account for achieving them and providing evidence of their realisation.

Indirect Benefits are those which facilitate or enable bottom-line impact, without leading directly to realisable items for which can individual or team had be held accountable. Such benefits include cost avoidance (i.e. costs not currently budgeted that might otherwise become payable) and capacity creation (where efficiency savings free up people to undertake high-value adding tasks but do lot lead directly to the release of FTEs or other costs).

The Benefit Realisation Toolset

In the Benefits Realisation section of my free-to-read Intranet Portal Guide, I outline a number of tools that can be used to better manage benefits on the typical portal project.

1) An enhanced Business Case:
Many business cases simply do not sufficiently reference Benefits. Make sure that you dedicate at least as many column-inches to benefits as you do to costs. Split benefits between soft, direct and indirect. Ensure that direct benefits are included in the ROI, NPV or IRR calculations and that the people who will be accountable for their realisation have signed them off.

2) The Benefits Blueprint:
Create a document that shows how your benefits link to actual business process changes, projects or deliverables and changes to systems. Suitable tools can be found in Cranfield's Benefits Network approach, the Six Sigma toolset and as add-ons to PRINCE. Position the overall result in the context of your vision and strategy. This will help you capture all the benefits and to sharpen what you need to do to achieve them.

3) The Benefits Realisation Plan:
The key control document, a good Realisation Plan includes, for each benefit, (a) a description of what the benefit is, (b) how much it is worth, (c) who will be accountable for it's realisation, (d) when it will be realised and (e) where it will impact. If there are risks or dependencies to the benefit realisation, these should be noted and managed in the plan. Finally, it should be clear in the plan how the benefit realisation will be objectively measured and evidenced (e.g. through the monitoring of key performance indicators).

4) Benefit Evidence:
In my guide, I suggest the use of Benefit Sign-off sheets, whereby the benefit owner identified at the Business Case and Planning stage is expect to sign-off once she is satisfied that the benefit has been realised. Evidence supporting the sign-off should also be attached to the sign-off sheet. This is a good discipline, to keep everyone honest.

Conclusions

The 21st Century Project Manager needs to be obsessed with delivering business benefits and value through change, rather than simply projects to time, cost and quality. There are tools that can help, including in particular the Benefits Realisation Plan. Good luck and don't forget to check back with my guide for further help and templates you can download.

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.

Managing Project Risks and Issues

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 1-3 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 Counter-measures

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 counter-measure in the risk plan. Where a risk can be eliminated, then this will be the counter-measure. 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 Off-Specification;
(Q) - A Question has been raised that needs to be resolved;
(S) - A Statement of Concern has been raised by someone;
(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 counter-measures 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 Managing Risks and Issues 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.

Stakeholder Analysis and Stakeholder Management

What is a Stakeholder?

Try “define: Stakeholder” in Google and you will be surprised by the huge differences in the way this simple word is defined. It perhaps proves - in a way - just how confused people get about Stakeholder Management and how inconsistent the different approaches to it can be!

My simple definition is “anyone affected by a decision and interested in its outcome”. This can include individuals or groups, both inside and outside your organisation.

Stakeholder Analysis

The first step in Stakeholder Analysis is to assess the Influence and Importance (two different things!) of each individual Stakeholder or Stakeholder group.

Influence is defined as the extent to which a stakeholder is able to act on project operations and therefore affect project outcomes. Influence is a measure of the power of the stakeholder. Factors likely to lead to higher influence include the extent of control over the project funding and the extent to which the stakeholder informs decision-making around investments in technology and business change.

Importance is defined as the extent to which a stakeholder’s problems, needs and interests are affected by project operations or desired outcomes. If ‘important’ stakeholders are not assisted effectively then the project cannot be deemed a ‘success’.

Where Stakeholders are both important and influential, then they are primary stakeholders and must by fully engaged in the governance and steering of the project, if it is to succeed. Where Stakeholders are either important or influential, then they are secondary stakeholders and need to be actively managed during the project.

The second step in Stakeholder Analysis is to understand the current position of each Stakeholder with respect to the project objectives and expected outcomes. For this purpose, a series of Stakeholder Interviews and Surveys should be undertaken, to understand the degree of engagement and the degree of commitment.

Engagement is a measure of how well the Stakeholder understands the challenges the project seeks to tackle and the strategy, plans and outcomes. A low engagement score signals a lack of understanding.

Commitment is a measure of how supportive the stakeholder is. A low score signals hostility, whilst a high score signals strong support.

Ideally, of course, any project wants engaged, informed stakeholders who actively support the project objectives and outcomes. An ill-informed supporter can be just as dangerous as a well-informed objector!

Stakeholder Management

There are many different suugested approaches for Stakeholder Management. In the chapter on influencing (stakeholders) in my (free to access) Intranet Portal Guide, I offer a simple, tried and tested, four-way approach:

1) Partner
Primary stakeholders (with high influence and importance to project success) are likely to provide the project ‘coalition of support’ in planning and implementation. As such, you should partner them to increase their engagement and commitment (revising and tailoring project strategy, objectives and outcomes if necessary to win their support).

2) Consult
Secondary stakeholders with higher influence but lower importance need to be ‘kept on board’. You should consult with them to actively seek their opinions and input for key decisions (and not only those which may affect them directly). It is unlikely you would alter your strategy as a result of such consultation, but you might well alter your tactics (e.g. the who, when or where of project plans) to maintain higher levels of commitment.

3) Inform
Secondary stakeholders with lower influence but higher importance need to be kept informed of decisions taken that may affect them directly. It is unlikely that they would play an active role in making those decisions. However, were they to highlight a particular issue with a decision, it is likely serious consideration would be given to refining the decision made.

4) Control
Control is appropriate where a stakeholder isn’t important or influential and they need help only to respect any decisions taken. Objections to or issues raised are unlikely to be given serious consideration (as they would otherwise divert valuable management attention and resources).

Conclusions

Stakeholders are key to successful Project Delivery in the modern organisation. Both Stakeholder Analysis and Stakeholder Management are vital tools and should be used iteratively throughout a project to keep everyone on the same page. Be aware that different approaches are appropriate for different Stakeholder types. You can't keep all the people happy all the time. Check out my guide for more hints, tips 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.

Intranet Portal - Business Case ROI

The days of easy money are over

In these post-dot-com 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 long-term payback period.

The good news is that a world-class 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 20-25% 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 under-estimated 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, 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 public-domain 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 15-25% 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 2-3 Killer Apps...
That will focus the attention (and support) of key sponsors. Look for win-win apps, where the user loves using them but the provider department also extracts key benefits. For example, a self-service HR application where the employee can keep their details up-to-date 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 pre-built security & authentication and a free development framework. HP and others have saved up to 20% on development costs, post-implementation. 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 short-term 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 olf-fashioned 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.