The general idea that bundles of projects need to be managed has quickly developed into a body of theory and some software products. Aimed at senior management, those are the vital ingredients for a 'big thing'. They allow the opening up of a whole new sector for high-priced software, along with ample opportunities for substantial consulting assignments. Just what is needed, as ERP and CRM fade into the mundane.
Project management has been difficult enough and seems lately to have adopted a theoretical bias. There has been much enthusiasm for certifying project managers. Unfortunately, the absorption of some theory and the completion of a set of multiple choice questions seems often to yield certified but unskilled project managers. One might, therefore, have some reservations about building another level of theory on top of already shaky foundations.
While it seems to make sense to align projects with business objectives, it is harder to see how this can fit with the further claim that projects thereby conform to long-term objectives. A problem with businesses--and to a lesser extent government - is a preoccupation with short-term goals. And for business, they are primarily financial, with less than obvious links to practical questions.
This lack of long-term goals is perhaps the inspiration for the suggestion that organizations should maintain 'islands of stability'. On those islands, the ground is said to be firmer under foot. Perhaps most projects are conducted away from the islands of stability and are thus best handled by people who can walk on water?
Like all big ideas, program management looks to be a reaction against an earlier trend. Views tend to oscillate between the two poles of the narrowly project oriented approach and the broad, integrated approach. Recently, the tendency has been to emphasize the advantages of keeping people focused on the project, ignoring wider organizational considerations. The latter are seen as a distraction that delay and sometimes confound projects.
In software, the project approach has been inimical to notions of reuse, since typically reuse of software requires extra effort in its creation. When the policy is to concentrate on specific project goals, such costs are not acceptable. Wider advantages are lost but that is seen as an acceptable price to pay for the efficient implementation of projects.
In the nature of things, after a period where that kind of notion holds sway, there is a reaction. So program management brings back the stress on the advantages of coordinating projects so as to maximize advantage. Inevitably, this downplays the potential loss of concentration for individual projects. It is impossible to be sure that it is not worth the occasional irrelevant project if the benefit is that each project is efficient and cheap.
A problem that often sneaks up on us seems to fit with neither approach. When infrastructure grows old and weary it is liable to become a brake on all new projects. Likewise, software that has become excessively complicated through repeated developments and fixes reaches a point where it works but is uneconomic to maintain. It is hard to see how projects to deal with issues of this kind fit easily with any theoretical approach.
There is an air about program management that suggests yet again that if we notice a problem, then somehow a computer system will solve it, as if by magic. The cited examples of projects that stupidly run in patently opposite directions do make one wonder how much software is needed for senior executives to take responsibility for ensuring that information is shared.
Like all theoretical movements, program management contains some nuggets of good sense. History suggests that we will have difficulty making much use of them before we become submerged in a new kind of status quo and start looking for another big idea.