“A programme is made up of a specific set of related projects identified by an organisation that together will deliver some defined objective, or set of objectives, for the organisation. The objectives, or goals, of the programme are typically at a strategic level so that the organisation can achieve benefits and improvements in its business operation.
There is a close link between Programme Management and project management because the programme is made up of projects and is only successful if the projects within it succeed. The concept of a programme is that it should deliver more than the ‘sum of its parts’. In other words, without Programme Management, the projects would probably still be able to deliver their particular outcomes but these would not be co-ordinated or integrated into the achievement of a strategic business goal.” (definition source)
A programme is what the delivery of a large contract such as the arrangements of security services to the 2012 Olympic games would be classified as. It comprises a range of projects, drawn together in order to provide more than the sum of their parts. MSP (“Managing Successful Programmes” – which is what I am trained in) provides an administrative structure for managing programmes that is what the UK government reckons is the best way to get programmes delivered.
First thing you need to deliver a programme properly under MSP is a “programme definition document”. Here’s a template from BIS which describes what you need to have prepared even before you are approved to start running the thing. Those of you used to bidding for projects could compare this stage to the bidding template you complete and send to us. In the same way that you have to convince the likes of me to fund your project, I have to convince my managers to let me run a programme.
There are two components in particular I can only imagine G4S didn’t do or did very badly. From the template:
“14. Summary of key risks and issues
A summary of key risks/issues that will/might impact on achievement of programme objectives. An outline of and proposed risk mitigation actions, contingency plans and issue resolution proposals.
References to the Programme Risk and Issues Registers should be included.”
and, an organisational plan
” A list or structure diagram with names against key roles. ”
I’d say the most common reasons that I complain about bids, project plans and suchlike are the lack of a decent risk register and a lack of clarity regarding who would be doing the actual work. Both are management failings which, for me, can tip something between being viable and being unfundable. Of course, it’s OK (depending on the scope and nature of a project/programme) not to have all staff in post if you’ve (a) got reasonable looking plans to recruit them (pro-tip: not a 1 month open recruitment process, especially if that month is August) and (b) you’ve got some kind of mitigation in your risk register for when it goes horribly wrong.
From what I can tell, G4S had neither of these. Reading between the lines of comments made by the delightfully named Mr Buckles today they’ve been appointing staff on zero-hour contracts. Basically, by using just-in-time staff allocation and avoiding regular scheduling they can get out of fulfilling many of their standard obligations as employers (sick pay, leave etc) and thus save money. This is why Buckles was unable to say for certain how many G4S “employees” would turn up for any given task. Under a zero-hours contract an “employee” is not obliged to turn up – this may happen because an “employee” has taken up an actual decent job that supplies regular income, or even because they couldn’t be arsed.
Even with a description at that level, you could see that this is pretty risky behaviour on a contract that depended on a certain level of staffing. And there’s only really one mitigation that you could use – you have many (many) more staff on your books than you may need… which cuts out a lot of the savings you’ve made by treating “employees” like crap (eg not paying them for training time unless you decide to give them 5 days work)
Clearly G4S erred on the side of greed, and hadn’t got the required level of mitigation. This should have been raised in reports to the senior responsible owner (SRO). That it wasn’t (apparently) raised was a failure of programme governance – blame should be shared between who ever the portfolio owner was (either at DCMS or the Home Office) and the programme manager at G4S, but should fall primarily on the latter – as a programme manager you always escalate risks for the simple reason it means the risks are no longer just your problem! I guess the drivers are different in a public-private arrangement where organisational profits are at stake.