Author: Neville Turbit

Navigating through an Organisational Process

In most large organisations, when there is a sense that something is complex and hard to manage, what typically happens? Usually, people put in place a structure so that they can control the function. The hope is that if you make a path for people to follow, you can see where they are.

Problems with this approach

There are two assumptions in this approach that can cause grief.

One Size fits All

The first assumption is that everyone can fit down the same road. In most cases the reason a function is complex, is because there is not necessarily one way to do it that suits every situation. This is not because there are many ways to achieve the same end, but because there are many ends, which may require different paths.

If we had to design a process to get people from their home to their place of work, they may be able to go by car, bus, train or ferry. They can leave at different times. They can take different routes. They can walk or ride a bike. Even after covering those options, you need to account for the times they are not leaving from their usual home, or making a diversion on the way.

With IT projects, one team may need to follow a completely different path to another in order to get to a similar point. There may be very good reasons for this. A degree of flexibility is needed in any standard process. One project may be small and combine several steps (e.g. instead of doing a testing strategy, followed by developing test scenarios followed by a formal test plan, and finally inputting into a testing tool, they may do it all as one step).

That is not to say a process is not required. The process needs to be massaged to suit, rather than complete useless work because somewhere, a document says it needs to be done. The trick is to know the limitations of massaging.

Everyone follows the Road

The second assumption is that everyone knows the road exists. I have seen comprehensive documents that describe a process in intricate detail. Even if they are read, are they understood? Even if they are understood, are they followed?

So in summary, trying to impose a structure on a complex situation is well intentioned, but will not necessarily solve the problem.

Case Study

Many years ago I was involved with an Insurance company that had appalling business processes. One of the main reasons was that the processes were not documented, much less consistent. If there were three ways to do something, they found five ways. The result was that their IT systems could perhaps support one or two ways of processing, but caused problems for other variations.

Training was impossible, as there was no standard model to train people. To solve the problem, we held workshops to identify the one common way everyone could use, and documented that approach. This became the standard model, and systems were designed to that standard. The whole exercise took a couple of years but at the end, everyone knew how to undertake each business process. More importantly, they saw it as their process. They had specified it. They also understood the problems deviating from a standard process could bring.

Problems were minimised but at a cost. The analysis and training demands were enormous. Staff were routinely spending one to three days a month training or working on standardizing processes. Contrast this with an IT project where many of the staff may be contract, and training is a luxury nobody believes they can afford. Whilst everyone should be trained, in reality we all know that will never happen. Another approach is called for.

The Project Advocate.

It is useful to draw a comparison with the legal system. We can represent ourselves in court. We can buy kits to allow us to process all the legalities of a house purchase. We can prepare our own will. In most cases however we rely on a legal advocate or lawyer. A law graduate once told me he had trained to become a librarian. Much of the training is to know the legal process, and which book to find in order to look up laws, statutes, precedents etc.

In IT projects, we need a “Project Advocate”. We need a person to work with the project team and help them navigate through the process. For example, if one of the first major steps for a project is to put together a funding proposal and gain approval, it is much easier if the project has a person who can guide them through the process.

In order to be successful the person needs to have:

• A through understanding of the project processes within the organisation
• Knowledge of the people who should be involved in the process, and the lead time required
• Understand the implications of shortening or omitting steps
• The support of the organisation, the Project Manager and the key players on the team
• The ability to guide the team through the process

The Project Advocate will probably belong to a Project Office. They will be trained and experienced in navigating a project from inception to conclusion. The organisation will need to insist that as soon as a project is even considered, a Project Advocate be allocated.

It is not a full time role, and it is not intended to take away the authority of the Project Manager. It is an advisory role to the Project Manager and the Team as to what is required to navigate through the labyrinth of processes and governance within most organisations.

The benefit to the organisation is better control of projects and better compliance with organisational requirements. The project will be completed more quickly, and with less fuss because things are less likely to be overlooked. Deliverables will be better engineered. The Project Advocate will be able to draw on past experience to ensure corporate expectations are being met.

Any Project Manager will tell you of their experiences in retrofitting documents and procedures to meet corporate standards that were unknown to the team when the documents were first prepared.

Project Advocate Responsibilities

The typical responsibilities would be:

• Provide guidance to the PM regarding the process for establishment, and running of the project
• Provide guidance to the PM regarding the expected format and content of deliverables
• Insure the PM understands the process for gaining approval for deliverables, funding and resourcing
• Explain to the team, the process to be followed at each step of the project
• Assist the team with their planning so that there is enough time to undertake required steps in the process
• Identify where particular areas (e.g. Auditors, Architects, Approval Boards) need to be involved
• Provide examples of typical documents and templates for the team
• Ensure the team have access to common tools and techniques used in the organisation
• Recommending ways in which the process can be modified in line with accepted company policy
• Assist the team direct communication to those who need to be aware of particular issues

Responsibilities do not include:

• Managing the project
• Telling the Project Manager how to run the project
• Preparing particular documents. This is a dangerous step, as it may mean the Project Advocate is becoming just a resource on the team and is losing the overall perspective needed to do their job. Their job is advisory rather than responsibility
• Trying to change the standard process to fit a particular project unless unless this is done as part of an overall process change
• Arguing the case for bypassing particular key steps that they believe should be completed
• Approval of deliverables or submissions

Summary

A Project Advocate is not an overhead. An Advocate is an expert in the particular way in which the organisation undertakes IT projects. The Advocate is a navigator giving advice to the captain. The navigator can chart the course but in the end, it is the captain who will decide where the ship is to travel. In the end, a ship with a navigator is more likely to arrive safely, than a ship with a captain looking for the rocks, and only when he sees them, taking evasive action.

Copyright Project Perfect