Case study: compliance with complex construction and multi-disciplinary teams

I managed a taxonomy project in a large-scale public sector construction project made up of multi-disciplinary teams from well-entrenched institutions like...

I managed a taxonomy project in a large-scale public sector construction project made up of multi-disciplinary teams from well-entrenched institutions like civil, mechanical and electrical engineers as well as planners, architects and over and underground railway designers. In short, this was ideal for building an efficient, elegant set of categories on a project driven by safety and legislative compliance and funded by public money.

If you are project managing risks and challenges you need all the artistry and science you can muster. You must start with the questions: why are we building this taxonomy and what is the business problem that we are trying to solve?

The answer to the first for me was simple: to save taxpayers money over the long haul of a complex project.For example, the project had already spent large sums on two separate asbestos audits on the same site as the reports and documents in the system were not tagged, paying twice for the same thing (duplication of effort).

The second driver was compliance. With ever-changing legislation, it was critical that the project could both audit itself and respond rapidly to calls for information from its political masters and the numerous Freedom of Information requests. The latter responsibility, which was increasingly used as a tool to eat up resources by opposition parties, meant that a lot of time was spent training people to tag e-mails and deposit them into the enterprise system from managers' private e-mail boxes, since they may have made commitments to external parties unbeknown to the project - several were.

Organisers wanted

So far so good. Now the fun, or lack of it, starts. Invite your colleagues to a Defining a Business Taxonomy workshop and most people will only turn up for the sandwiches. However, those that do take an interest will be your foundation stone for turning dumps of digital detritus into valuable recyclable corporate assets. Within any organisation there is an untapped wealth of people that like to see things organised. The latent librarians will tell you everything that's wrong with the current filing system and proffer a myriad of different suggestions. This job is not for the fainthearted which is why external taxonomy consultants are not cheap; and it is often with external "experts" that taxonomy projects begin and remember, all you will end up with at the end of your workshop session is a list of words.

However, start by finding the Rosetta stone of your organisation. In our case it was the Work Breakdown and Cost Breakdown Structures that were the key for engineers involved in defining what we were building. Crucially, that's where the big ticket items were described so that's where the cost savings lay. We started out defining a data dictionary to find a list of common terms that everyone used.

Keep taxonomy simple

At a workshop between two disciplines - overground and underground railway station architects - we found several terms had different meanings if you were above or below ground. I was advised that the battle about this terminology had raged for 100 years - so who was I to try to arbitrate it now. Therein lies a law: don't try to boil the ocean. Find the bits you can agree on and leave the disputes well alone. Avoid the tendency to make the taxonomy more complex than it needs to be, you don't need to describe every possible category, just the ones needed today.

Many of the cost overruns in major projects are because of a reluctance to resolve their inherent complexity to be able to report one view of the truth. With senior management often too busy with the truth of political expediency and other departments resistant to loosing control of their version of the truth, you need a compelling business reason to enter this minefield and sadly saving taxpayer's money is not one of them.

The taxonomy was built in an iterative fashion, with more content and broader categories added as necessary. The task of implementing the taxonomy design into, in our case a document management system, is as frustrating as it is rewarding. It is worth spending time auditing the capabilities of your existing, or proposed, system to see how much flexibility you have in getting down to the core of the program. We spent several thousands getting access to keyword list and design templates we had assumed were customisable. Check whether this will impact on your maintenance contract and the program's performance.

User buy-in

A key issue to take-up of the system was training. We found when you introduced the system to people already in place they were reluctant to change (they now had to tag documents they merely saved with an arbitrary file name before) but new starters got it straight away (often having come from previous, chaotic projects). I worked on the taxonomy project for five years. We had the resources to do it - it was a funded mandate. Ongoing training and a lot of hand-holding led to a compliant system with an elegant taxonomy at its core.

Pockets of resistance still occur, most notably with the executive's secretaries, who with a mix of inertia and straight forward insubordination - say "I don't want to do this" and manage to squirrel documents away out of sight. Despite the odd spanner in the works, a practical taxonomy was built into the critical areas of the system.

Read more on IT project management