I spent half a day earlier this week at the Best Practice User Group Congress. BPUG is concerned with the application and use of OGC products such as Prince2, MSP and MoR. As you might expect therefore there was little mention of alternative methods such as Agile. I didn’t have time to attend the conference sessions, so this is somewhat less than a full review: I did however take part in one round-table session and had a chance to speak to a number of vendors at the exhibition.
I’m planning to attend Agile Approaches for Delivering Business Value next week. It looks like an interesting set of sessions, and although I doubt I’ll be liveblogging, I aim to post some notes here as soon afterwards as I can. I’m particularly interested in two of the talks on the second day: “A Square Peg in a Round Hole: Agile and fixed-price contracts” by Duncan Pierce; “When XP Met Outsourcing” by Angela Martin.
I’ve clarified the process I have in mind, based on the previous two posts:
In Programme Procurement Strategy – 1 I briefly reviewed the approach from the OGC Risk Allocation Model for Project Strategy and Procurement. Thinking about how to apply that approach to my own programme, I quickly realised that the range of changes we are seeking to deliver (across technology services, business processes and management capabilities) does not easily sit into a single risk assessment. So I’m still attracted to the risk-based approach, but it is going to need substantial de-composition of the programme to apply it meaningfully.
I need to put together an analysis of procurement options for the programme I am shaping, as first steps in devising a procurement strategy. The main online reference I have found so far is the OGC’s Risk Allocation Model for Project Strategy and Procurement (pdf). The first part of that document examines the suitability of different contract types in relation to the nature of the organisation and the programme goal:
I’ve just got my hands on Benefit Realisation Management: A Practical Guide to Achieving Benefits Through Change by Gerald Bradley.
On my other blog I’ve been posting my process as I worked through the creation of a Quality Management Strategy. Post 1 Post 2 Post 3 Post 4 Post 5 One key learning point was that the management of benefits, whilst considered by MSP as a separate activity, is absolutely fundamental to ensuring the programme delivers value, so it is important to make that an integrated part of the Quality management Strategy.
Further reference to the [[MSP]] manual (p77, 2003 version) identifies three areas of programme activities where quality management is involved: Quality management of the governance arrangements – this corresponds to the top level “Governance Reviews” in post 3 of this series. Quality assurance and review of project outputs – this corresponds to the lower three levels in post 3 of this series. Configuration Management of key programme documentation. Drawing on this we need to add an area to our Quality Management Strategy (item 3 above).
At some point we will have to identify the who of Quality Management – who will carry out all of the activities. Looking at the last post it occurred to me that a useful simplifying assumption would be to divide the processes into three levels: Meta-Programme Activities <td style="color: #000000; font-size: 11px; cursor: text; margin: 8px; border: 1px dashed #bbbbbb;"> Quality activities which sit outside the programme </td> Programme Activities <td style="color: #000000; font-size: 11px; cursor: text; margin: 8px; border: 1px dashed #bbbbbb;"> Quality activities at the programme level </td> Project Quality Activities <td style="color: #000000; font-size: 11px; cursor: text; margin: 8px; border: 1px dashed #bbbbbb;"> Quality activities within individual projects </td> The activities in the first section are the responsibility of the SRO / Programme Director, often with external help such as audit.
In the last two posts of this series I have started down the line of understanding the value chain of a programme, and therefore what it is we need to quality assure. This post steps back for a moment to think about the sort of process we need to design in our Quality Management Strategy – the how of quality assurance. One of the major differences between a programme and a project is the very much higher likelihood of change in a programme than in a project: