Feature

posted 13 May 2005 in Volume 1 Issue 10

The human side of intranets: Part 1

When it comes to intranet development, the relationship between content owners and developers is often fraught with tension. But with a little common sense and a healthy dose of interpersonal skills, the differences between the two should not be irreconcilable. By Paul Chin

We speak and write often of the theories behind knowledge and content management, the methodologies for classifying information, and the new technologies that arise to facilitate solutions we thought unfeasible in the past. But this represents just one end of the intranet development spectrum.

At the other end are real people who need to put all of this into place – and to do so efficiently.

As intranet professionals we arm ourselves with an arsenal of information, techniques and tools in order to build and maintain an effective intranet. But we also need to consider the subjective issues associated with development – interpersonal skills, user acceptance and corporate culture – with as much weight as the technology used to build the system. Otherwise, all of this theory and technology won’t amount to much if we don’t have the basic social skills and common sense to handle our relationships with team members and end-users.

In this, the first part in a series exploring the human aspects of intranet development and management, I’ll look into the often polarised relationship between developers and content owners and what can be done to alleviate this.

Irreconcilable differences?

It’s said that birds of a feather flock together, and a truer statement can’t be made of the divide that often exists between those who develop an intranet and those who manage its content. Although both groups must work together towards a common goal, there has always been an unmistakable us-versus-them attitude that ranges from the surreptitious to the overtly absurd.

This divide exists not so much because of some fundamental shortcoming in employees’ interpersonal skills, but rather because of a lack of communication, misconceptions about each party’s role in an intranet team, and a fair amount of territorialism.

Content owners and developers have very different responsibilities, both during development and in day-to-day system management. And it’s ironic that an intranet – a tool that aims to foster an atmosphere of co-operation and knowledge sharing – should be borne from two groups who are so often at odds with one another; but it doesn’t, and shouldn’t, have to be.

So, how do you prevent the unfortunate barrier between the “techies” and “non-techies” from adversely affecting the outcome and health of your intranet? It starts with an understanding that this barrier is man-made; and that through communication and tolerance of your colleagues’ viewpoints, these problems can be avoided altogether.

Advice for content owners

Your role as content owners and providers is to manage the heart and lifeblood of an intranet: its content.

While a basic knowledge of your intranet’s technological backbone may be useful in dealing with your developers, you shouldn’t have to be overly concerned with, or be subjected to, superfluous technical details on any practical level.

Even though it may seem at times that IT professionals speak an entirely foreign language, there are some things that you can do to ensure a good working relationship with your technical intranet counterparts:

1 – Present detailed intranet requirements

Intranet developers make poor mind readers, and they hate having to waste time chasing you down for clarifications on your business processes. To avoid this cat and mouse game, it’s important that you provide them with a formal set of system requirements. Once you have spelled out your needs, your developers will be in a much better position to tell you what can and can’t be done within the available timeframe and resources on hand.

2 – Avoid ad hoc changes to specifications

If changes or additions need to be made to original intranet specs, you should always make them to your developers through official channels – whether in the form of a memo or an e-mail – rather than through casual conversation.

Written spec changes create a paper trail that enables you to keep track of your requests and developers to prioritise their tasks.

3 – Don’t encroach upon your developers

You must have enough trust and faith in your developers’ abilities to carry out what needs to be done without needing to constantly look over their shoulders. Becoming a backseat driver will only cause resentment among the developers; they know what they have to do and should be given the space to do it. If you need to know something, just ask – but don’t hover.

4 – Provide developers with a ‘Big Picture’

You should always plan for the future and provide developers with your entire vision of the system rather than only what’s needed in the here and now. This allows developers to plan ahead and avoid backing themselves into a technological corner. With a ‘Big Picture’ view of the intranet, developers will be able to create a system flexible enough to accommodate future expansion.

5 – Never dump content-management tasks onto developers

Developers already have their hands full with issues of development, deployment and security. Don’t add to their stress by delegating content-management tasks to them – it’s not their job, it’s yours. You should never assume that just because you don’t have time to do it, that IT will. This will get you a one-way ticket onto their blacklist.

Advice for intranet developers

Your ultimate goal is to deliver a secure, stable and intuitive intranet that will enable content owners to act with a certain degree of self-sufficiency. The system must be user-friendly and manageable by non-technical personnel. It won’t do content owners any good if you deliver a system that can only be maintained by those who built it – if you do, expect a call from your content owners just about everyday because they can’t understand how the intranet operates.

Intranets, although based on technology, are content and community driven. And while it may be tempting to lace the system with the newest technology, don’t forget who’s at the receiving end of all this. The final result must fit their vision, not yours.

Here are some other important bits of advice to bear in mind as you’re working with content owners:

1 – Stick to project deadlines

A system like an intranet – especially a high-volume intranet involving multiple departments and groups – requires a lot of careful planning and co-ordination of project deliverables. The completion of one component may be highly dependant on the outcome of another component; even a single delay can have a rippling effect along the entire length of the project timeline. It’s crucial that you inform content owners of any potential for missed deadlines ahead of time so that scheduling can be adjusted never drop the bomb a day before a deliverable is due.

2 – Offer alternative solutions

No one likes bad news, but it’s naive to think that everything will always go according to plan. When development problems do occur, never approach content owners with a list of your woes. If you want them to trust your judgment on technology matters, don’t put the responsibility of coming up with solutions on their shoulders. Instead, explain the problem and offer up a list of suitable alternatives.

3 – Avoid tech talk with content owners

Never bring up overly technical issues when in meetings or other forums with content owners unless they have a technology background as well. Non-technical content owners will feel like a third wheel when caught in the middle of a technical discussion. If there’s a technology issue that needs to be looked into, it’s best to take the conversation outside of the meeting and talk it over with your fellow developers.

4 – Listen to content owners

Your job as a developer is to provide content owners with what they need, not what you think they should want. Always take the time to hear out content owners’ ideas and suggestions—even if it’s not feasible or if you disagree with what they have to say. This will go a long way towards removing that long-held stigma of the conceited IT team who think they always know what’s best for everyone.

5 – Make a post-production commitment

Unlike some IT implementations, an intranet doesn’t have a definitive end-point. It’s a constantly growing entity and as such you shouldn’t vanish after the system is rolled out into the production environment. Content owners still need training and general support from you.

Advice for both content owners and developers

There’s no reason to allow the relationship between content owners and intranet developers to deteriorate into fisticuffs. Building a healthier working relationship between the two groups involves:

1 – Holding regular face-to-face meetings

Resolving minor issues through e-mail or over the phone is fine, but key members of both groups must meet in person on a regular basis in order to measure project progress, discuss major stumbling blocks that can affect deadlines, and review potential changes to original intranet specs.

2 – Keeping the lines of communication open

Although both groups have their own roles to play, and it may not always be possible to meet in person, try to at least keep in touch – even if it’s just to ask them how they are doing and if everything is going according to schedule. Both groups will be appreciative that the other hasn’t disappeared on them.

3 – Respecting others’ priorities

Don’t expect everyone to drop what they are doing when you need something from them. You have your priorities, but so do they. Demanding that they see to your requests first belittles what they do and will strain relations.

4 – Avoiding feature creep

A lot of frustration – on both sides – can be caused when an intranet’s list of features constantly grows. Whether you’re working on your initial intranet implementation or a new version, once you agree upon the specs, stick to them.

If new features are constantly added – pushing deadlines further and further – the system will never get completed. This is tantamount to running a race where the finish line is moved farther and farther the more you run. Instead, save all non-essential additions for future versions of the intranet.

5 – Being flexible

You should always feel free to bring up any concerns you have regarding the intranet, but you need to be flexible enough to accept the fact that there will be times when you just won’t win your argument. When this happens don’t be so stubbornly unyielding as to hold up progress. Sometimes you have to compromise between what you would like to do and what you’re able to do.

Making it work

The problems experienced between content owners and intranet developers are mainly a matter of perception. When they do occur, it’s your handling of the situation that ultimately determines the outcome. And although each group approaches an intranet at different ends of the development spectrum, eventually they all have to meet in the middle.

Paul Chin is an IT consultant and freelance writer. Previously, Paul worked as an intranet specialist in the aerospace and competitive intelligence industries.

<SIDEBAR>

Content owners: Roles and responsibilities

Collecting and filtering intranet content;
Finding and identifying “dark data” - useful intranet content that may be hidden away in the form of Word documents, PDF files, e-mails, hard copy documents, spreadsheets - that’s not easily accessible by a large intranet audience;
Developing a logical content structure that will eventually form the basis of an intranet navigational system and user interface;
Identifying sensitive information that needs to be secured, and deciding which users and groups should have access to this information;
Maintaining overall content integrity and avoiding data pollution by ensuring that only relevant content is posted.

<SIDEBAR>

Intranet developers: Roles and responsibilities

Providing content owners with all the tools and training required to manage their section of the intranet with autonomy and self-sufficiency;
Designing a consistent and intuitive user interface;
Developing intranet applications to handle dynamic database driven content;
Implementing an effective intranet security model, and controlling access to the system based on user permissions granted by the content owners;
Ensuring the overall integrity of the intranet’s infrastructure.