assembly  line in a WWII factory
PHOTO: Birmingham Museums Trust

Mass production allows us to enjoy a vast array of relatively inexpensive, reliable products and services. While the economy still needs custom products and solutions, the trend is clearly towards mass production. Yet building and maintaining intranets remains as time-consuming as ever.

We've seen a steep increase in the number of out-of-the-box products in recent years. In my opinion, they only provide improved content editing functionalities and provide some data integration and business process management capabilities.

The “production” of an intranet is not only labor intensive, it's prone to mediocre results, due to limited specialized intranet knowledge from the stakeholders. Also, because the content production and structuring standards often vary by each department, the overall digital employee experience suffers and leads to communication gaps.

Cost, and especially hidden costs, are another major issue. Countless internal meetings, content writing and rewriting are likely to offset the cost of licenses and IT implementation services.

The top issue to me is how the intranet team approaches each department, typically by asking what their issues are and how a new intranet could fix them, which often opens the Pandora’s box and leads to a nearly endless, unstructured approach. There has to be a better way.

Where Intranet Design Typically Goes Wrong 

The number one objective of an intranet is to help users do their tasks. Each such task is someone else’s service. So, if you want your intranet to help employees accomplish their tasks, this means that each such service needs to be well presented in the intranet.

Each service has a process owner and belongs to a department that delivers this service to the internal customers.

The typical approach to intranet design is to work with departments as a whole, but this is where things often go wrong. Some of the services end up being ignored while the department management focuses on speaking about their profiles, their projects, how they do things and less on exactly how their services are being consumed by the employees.

Also, the content structures of different departments will have little in common, which leads to inconsistent employee experiences.

What information do you have to manage with respect to a service? To perform any activity, the users need two types of information:

  1. Support information that teaches you why and how to do the task. This information takes the form of procedures, forms, training materials, support contacts and so on.
  2. Transactional information, such as a holiday request, an invoice, an order cancellation. Business line applications manage this information. Not all internal services have an app to support them. In some cases, employees must contact an email address or phone number to get things done.

While managing the support information is within the scope of an intranet development, managing transactional information should be managed with the existing software development processes.

Most of the intranets I have seen are being built from an information producer perspective. There are managers describing their teams, their work, their procedures. I'm suggesting an approach that focuses on an internal service consumer perspective. This ensures that all the relevant employee tasks are translated to internally provided services and properly documented.

Related Article: Intranet Alternatives to SharePoint

A Mass-Production Approach to Intranet Development

To mass produce an intranet, its development must be broken down into smaller standardized activities that can be executed in a simple manner by the involved employees.

Such an approach requires the use of standardized intranet operations and activities, page templates, reusable software components. While certain activities will still involve a deep understanding of the customer challenges and requirements, you can get a much higher degree of standardization than the traditional intranet design process.

Not only will the results be much quicker and require less effort, but by applying the method described below the enterprise will become a lot more flexible and efficient.

So, how do you do it?

Step 1: Identify All Internal Services

Identify all of the internal services provided to employees. While it is not a bad practice at all to raise the question “what are your main issues, challenges, or improvement objectives?” use this information to build some sort of high-level understanding of the department objectives and move on.

The question you should immediately follow up with is: “What services do you provide internally?” This makes the discussion a lot more specific. Also ask what the service's priority is for the department.

You can even find the services provided by a department by going through the job descriptions of the positions within that department. An online survey is also a simple way to collect data at this phase.

The whole idea is to streamline this process as much as possible by focusing the discussions on services more than anything else.

The result of this phase is a list of all the services provided internally, with their owners, priorities and business impact attached to them.

Related Article: Poor Information Architecture Is Hurting Your Business

Step 2: Agree Which Internal Services Will Make it Into the Launch Version

Along with other key intranet functionalities, such as a news feed or an employee directory, you and your stakeholders will have to decide which services to include in the intranet at launch.

Chances are high that some people will not be able to complete their commitments by the launch date, while others will move a lot faster than expected, so some flexibility might be required here.

Step 3: Document Each Internal Service

Ask the process owner of each service to provide all available support information. Here is an example list with such information, ordered by probability that the information is already available:

  • Procedures, forms, policies.
  • Support contacts (emails, phones, link to ticketing app).
  • Names of the people who should receive feedback.
  • Links to the app supporting the service (if it exists). It is advisable that whenever possible to use a deep link to the exact screen that supports the service.
  • News or recent changes related with that service.
  • Frequently asked questions.
  • Educational resources.
  • Motivational resources (why is that service important for both the user and the organization).

All the collected information will be put on the intranet using standardized page templates that:

  • Simplify the content collection and presentation for process owners.
  • Provide a consistent digital employee experience for the internal customers.

The information can be manually inserted in the page as text or links. But a better way is to tag and store it in dedicated repositories and then selectively display it on the service pages, either with the help of generic tools such as React webparts or, even better, with the help of dedicated components.

Users will on occasion raise requests for the development of small apps. Two things to keep in mind when these requests arise:

  • Keep a record of each request in order to have a clear view of the enterprise needs for digitalization.
  • Don't delay the implementation of the intranet based on such requests — they should be done by a different resource stream. The primary objective of an intranet project is not to develop new apps but to deliver support information to employees.

Related Article: Get Your Intranet on Track With Effective Improvement Cycles

Step 4: Keep Track of the Progress for Each Service Page

Maintain a table with the following columns:

  1. The internal service name.
  2. Departments (there can be multiple departments owning a service, think Business Travel that splits between Travel Administration and Accounting).
  3. Process owners.
  4. Priority/phase.
  5. Business impact.
  6. Target level of detail, can be classified as:
    1. Basic (forms, procedures, support contact, feedback contact) for simple services.
    2. Fair for those services with lower business impact, might include additional types of resources mentioned at step 3.
    3. Full for those services that have visible impact to the business results, should include almost all resources mentioned at step 3.
  7. Current level of completeness, can be non-existent, intermediate or matching the target level of details.
  8. Commitments for the current planning period and their status.

Step 5: Build the Navigation Around Internal Services

Navigation is one part that is specific to each company and to the level of intranet maturity. This is the one area where “artisan handcraft” has the most important role. Yet there is still room to improve.

The objective of navigation is to give employees access to the services. One approach here is to tag each service page with several types of metadata — e.g., department to which this service belongs, product or business line, etc. and automatically generate a list of all services that apply to a specific topic. You can go as far as automatically generating sections of the top navigation with all the services that can be consumed by the employee in a specific context (product, department, etc.).

Sound Complicated? Think Again

All of this might sound overly complicated. But if you start to think how it would work for a couple of support services you will notice that it simplifies the work of everyone involved:

  • The process owners get a clear benefit and a simple model with what information they need to put together in order to serve their customers better.
  • The intranet manager has a simple roadmap for the development of his intranet.
  • The internal customers find in the intranet comprehensive information to support them with their tasks.
  • The business functions of the enterprise work a lot closer together and feedback reaches the exact people who can take action.

Please let me know in the comments below how this model applies to your specific case.