• header 2
Wednesday, 05 February 2014 20:33

When is a program not a program?

Written by
Rate this item
(2 votes)

A common side effects of successful project and program management in organizations is the designation of activities as projects or programs which are neither really projects nor programs. 

 

One of the key points about a program, which sometimes gets forgotten, is that it is a finite activity with a clear end point. This end point in the case of a project may be a set of deliverables being created and implemented, and in the case of a program is usually a set of projects that lead to some set of benefits being realised or some desired outcomes achieved. The timescale of the program may be relatively short, but it can stretch to many years. Whatever the length of time, in a good program everyone involved knows what that end point is.

Critically it is the focus on the end point is that drives the program forward. The focus on end point differentiates the mind-set of a project or program manager from an operational manager. I know some brilliant operational managers – their daily focus is quite different from mine.

One habit I often find in organizations is the desire to ring fence a pool of resources to work on some undefined, but vaguely bounded area of work. Program management exists to achieve goals, benefits and outcomes – it is not a mechanism just to ring fence resources. Now of course to do a program you have to allocate some resources, but that is a requirement of the program, not the purpose of the program. Forget this and you risk the ever-lasting programs which are inefficient and achieve limited benefits.

 

The 20xx enhancement program

The classic case in point is the enhancement program. This is common in portfolios of IT programs. Look down the prioritized list of projects and sooner or later you will find something called something like the “2014 billing systems enhancement program”. This was often preceded by the “2013 billing systems enhancement program” and is likely to be followed by the imaginatively titled “2015 billing systems enhancement program”.

The reason these programs arise is usually because there is a real need to do some enhancement work on the system, but no one is quite sure what that is yet – or to be frank often no one can be bothered to properly scope and justify the work in the first place. This then combines with a desire to ring fence resources, as if this is not done the work will struggle to find the resources required later in the year. The annual budgeting process reinforces the habit. Every year someone has to build a budget. Creating buckets of money at the start of the year, aligned to groups of resources, eases the life of the budget holder when it comes to developing and justifying spend. Breaking a big pot of money into several smaller pots of money gives the appearance of science to the budgeting process.

 

Four reasons to reject the 20xx enhancement program

I don’t dislike these programs because they achieve nothing, often they do achieve some important things for the organization involved. The reasons I don’t like them are:

  • Inefficiency: usually, because no one has bothered to go through the rigour of scoping the work properly, of prioritizing the activities and of planning it out, they are inefficient ways of delivering the work.
  • Scope creep: whilst the bucket as a whole may be important, by making it a bucket all sorts of less important enhancements creep into the work. Resources working on the less critical aspects of the bucket of work would be better allocated to other activities. These buckets are notorious for scope creep.
  • Architectural/complexity risk: the systems that have constant enhancement programs often become unnecessarily complex and harder to maintain – reinforcing the need for an even bigger enhancement program next year. 
  • Wrong incentives: carry on too long with the 20xx enhancement programs and they become a self-justifying stream of work that is difficult to stop. Everyone involved is incentivised to keep it going to justify their roles in the organization.  Such programs send the wrong signals and develop the wrong management behaviour.

 

Go back to basics: scope and objectives

If you have a whole series of enhancements that you want to bundle into a program then go ahead and do it. But please scope the work properly, give it some clear objectives and make sure the work has a clear end point. Otherwise you will lose many of the benefits that good project and program management bring. 

 

Richard Newton is an author, speaker, program manager and consultant. Amongst his books are The Project Management Book. He maintains a blog and writes regular articles at www.changinghats.co.uk.

Read 29952 times Last modified on Friday, 07 February 2014 22:27
Richard Newton

Richard Newton wears many hats. Included amongst these are his work as a consultant, author, blogger, change leader, company director, and program manager. His most well known project management book is The Project Manager: Mastering the Art of Delivery. He is also the author of the best-selling Dream It, Do It, Live It which applies project management principles to achieving personal dreams.

His articles and blogs can be followed at www.changinghats.com. Information about his company can be found at www.enixus.co.uk. His books are available at bookshops and online sellers worldwide.

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

Recent blog posts