Bitter experince warning
Unfortunately, the term "intranet" has...
What's unfortunate about this is that it has become, like so many other terms overloaded into the Corp::Media::Lexicon Class, a wooly, nebulous term that noone can quite put a handle on. Examples:
The company that commisioned Sachii & Sachii (or similar entity) to 'improve their corporate image'.
After much money and many surveys, the advice was
"Put pictures of puppies and 'groups of nice people in picturesque locations' in the Corporate brochures.and "Oh! Add a vision statement". -- The company made sanitary wares!
Customer facing? Something to do with Feng-shui? An office where all the desks face windows?
Transparent? You mean that our customers can see through our hype?
Unless your company still requires the use of sneakernet for file transfer, or has an internal snailmail system for delivering inter-office memo's, the chances are that your company all ready has an "intranet". Of course, I realise that the term has much greater connotations that 'internal network', but the point I'm making in my own clumsy way is that an intranet as and of itself is not a 'thing to have'.
It is a piece or set of hardware and infrastructure that, when managed properly, can aid the company bottom line by improving the availability and timely dissemination of useful information.
Every word and phrase in that (rather stupid) sentence is important.
This is the what.
Essentially it is hardware. The main distinguishing factor is that it exploits the availability of a 'browser on every desktop' to obviate the need to write custom clients for every different networked application that is written.
This is the why.
Too many times, it has become a 'must have' item on the BoD's annual shopping list for no other reason that it's felt "we should have one". Unless there is at least notionally, some financial benefit to having one, it is likely to do the company more harm than good. It will never generate revenue, but there should be some demonstrable financial benefit from having one. Saying that it will save client development costs on company client server and/or MIS applications isn't good enough, unless there are some planned and they have passed a cost/benefit analysis.
If it ain't a source, its a sink.
Don't be the guy responsible when the sink flows faster than the source, you won't like it.
Don't under-estimate the propensisty of companies of almost any size to generate prodigious amounts of data and for the producing departmental heads to believe that their data is 'required reading'.
Data is not information.
The cost of converting data to information is typically 3-10 times the cost producing or gathering it. You'd be amazed at the amount of time people will spend manually or programmically prettifying their local data for use on the intranet. Everyone and his dog will want to become a FrontPage guru.
The higher up the corporate ladder the source of the information, the less likely the need for widespread availabilty but the more likely the unjustified desire to see that information disseminated. And the harder it will be to say no.
If you can, try and get the BoD's or whomever the decision makers are, to agree to an abstract definition of types of information (and what constitutes "information") that should be made available and sustained on the intranet.
Also, try and get pre-agreement that whomever (departmentally) is responsible for requesting that information be made available via the intranet, regardless of whether they are the producers of the raw data, is also responsible, in departmental financial terms, for the conversion, maintainance and verification of that information.
That will reduce the demands from some departments, that other departments make their data available this way, without justifying the cost/benefit to themselves.
Like all corporate projects, the key here is for the authority to go hand-in-hand with the responsibility. That means financial responsibility as well as the "who-screwed-up" kind. It's very easy for internal, non-profit departments, and their budgets, to be abused on mill of unreasonable demands and expectations. If the requesting departments have to pay for the things that they demand, even if only in internal funny-money terms, then they are much more likely to consider those demands and the costs of them more carefully.
You can have it if you pay for it is a pretty good regulator. Just don't be tempted to
You need applications. One or more applications that would benefit in terms of availability, reduction in cost, or some other way, from the presence of an intranet, before you need the intranet itself. Ie. It's no good saying if we had an intranet we could do this or that. It really should be:
We have this existing use or application of data that needs to be re-written and would benefit from wider use and would be cheaper if we leveraged the web browser for the interface.
or
We have one or more MIS projects that have passed cost/benefit analysis and we could utilise a web interface to minimised development costs and provide universal coverage.
If you are the guy who neck is on the line if the project fails, it is important to make sure that those holding the purse strings are aware of the potential costs as well as the benefits. And that they don't see it as some magic bullet or corporate band-aid for some other ill (real or perceived). That pretty much means that you need to spell this out up front, in writing or in public, and that way (depite my loathing of the phrase) manage their expectations.
In my experience, more IT projects are percieved as failures because they didn't live up to unrealistic expectations, than because they failed to deliver on some technical specification, or went over time or budget.
It's a fine balancing act. Good luck.
Examine what is said, not who speaks.
In reply to Re: OT: Intranet Design
by BrowserUk
in thread OT: Intranet Design
by Theseus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |