Project Management Software
Specialists in Project Infrastructure
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.
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:
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:
Responsibilities do not include: