Program Management

download this column in pdf

	I like this column
	881 persons like this column

One of the key characteristics of asset management[1] is the principal- agent relation between asset manager and service provider. It does not really matter (especially in the infrastructure industry) whether the service provider is external or internal. The number of potential service providers is not that large, thus even if the service provider is an external organization, the relation will easily evolve into  a strategic partnership. And because of this long term relation, the external organization becomes somehow an internal party, comparable to the very tight relation car manufacturers have with their suppliers in Just In Time production systems. Sometimes people claim it is easier to work with external service providers than with internal service providers, as the external gets paid directly by the asset manager and thus has a stronger incentive to please the asset manager. This may be true, but in practice it really is the last resort to stop paying external service providers. A party that is not paid will not have an incentive to think in the interest of the asset manager. The internal service provider has that incentive, and it is often easier to exchange informal information. Both variants thus have their pros and cons.

What does not change between the variants is that the asset manager really has to act as the principal. That means that it has to be indicated clearly what the asset manager wants to be realized and that the knowledge of the service provider is used to get there as efficient as possible. At the same time, the service provider will have to act as the agent, which is accepting that another party determines what has to be done, and that the justification for existence has to be derived from the most efficient realization. In practice, however, we tend to see that the parties do not keep to their assigned role. Employees working on the principal side of the gap may develop into behaving little potentates, wanting to determine in detail what the agent is doing ( up to the color of the paper used in the mobile toilets on the construction side). On the other side, some agents still act as the decision maker and send orders back because they do not comply to their (internal) guidelines. Or, if the asset manager asks them to come with suggestions on how to solve the problem, they step back and say that is the asset managers job, not theirs. This kind of behavior can easily escalate into a permanent state of war. Everybody wants to be taken seriously in its working environment and if your counterpart does not do that, somewhere a line has to be drawn. The individuals in the organization thus maintain their ego’s, but with respect to the interests of the organization as a whole it is a disaster. Before you known it, agreements can only be made via the board of directors, limiting the amount of detail drastically.

What tends to work in those situations is program management. In program management, a team[2] of employees both from principal and agent assumes responsibility for translating the targets into agreements on the production and oversees (by monthly meetings) progress on those agreements. But even more important, they oversee the realization of the intended results. It is one thing to agree on replacing 10% of the tarmac each year, but it is of vital importance to the principal that the whole system is renewed in 10 years, and not the same 10% every year as it is so easy to work on because there is hardly any traffic.

Within such a progress meeting it is of great importance that it does not start by claiming that people have to work harder, or that more money is needed. It is best to jointly determine first what has been  achieved, what has been agreed on what would be achieved, and only then to judge (again together) whether the target has been met. For targets that have not been met an analysis has to be made why the target has not been met. In some cases it will be due to some natural variance (like slightly more complicated projects or more sick leave than usual), in some cases it will be due to external influences (for example tough weather) , a third party did not do its part and many more other potential explanations. It is possible that no such explanation exists, and then the logical conclusion is that the service provider has been lazy. But only if an agreement is reached on the cause for the unsatisfying results, measures can be discussed. The natural variation will be caught up without measures, for some causes additional measures can be defined on how to get back on track (and who pays for that, though that should be agreed beforehand) and in some cases it just as to be accepted that the backlog will be definitive. That may seem strange for individual projects. Huge fines can be involved in being late. But realizing that programs consist of many projects, and within organizations often dozens of programs run in parallel, sometimes even working on the same risk, it is not necessary to panic if one project or even a program is lagging. It should not be a structural problem, but accepting a small deviation can be more effective overall than trying to be perfect in each and every detail.

Source: http://www.fotosearch.com (c) Antrey / www.fotosearch.com Stock Photography

A last remark considers the kind of people working in program management. From the principal side, sometimes it is suggested that is has to be the engineer who developed the program. That is the person that knows the details by heart, and is the best to judge whether the intended result is achieved. From the side of the agent, it then would be the program leader, in direct supervision of the field engineers. But this is not a very fortunate combination, as this team might get lost in technical details. To exaggerate a little, where the light switch should be. It can be very helpful to put program management in the hands of people on some more distance from the technical reality, like a procurement officer and an account manager. In a technical world, this may get an adverse response, as it is impossible to manage a project without technical knowledge? In itself, that is correct, but program management is not about technology but about working together and managing. As techies have a tendency for wanting to be right and to be recognized for that, working together is mainly considering the needs of the other. There is no I in team after all.

<< back to overview