Synesthesia

This is a follow on from UML Profile for Benefits Realisation Management – 1. In  that post I described the basic UML profile I have created for modelling project benefits in line with Bradley and Ward & Daniels

Having started to apply the profile successfully, I wanted to extend it to model measures,

These were modelled by meta-classing Class

As can be seen from this diagram, I have added a number of tagged values (which are modelled as attributes in the UML profile) to cover off the typical data that needs to be captured in relation to a measure.

I wrote yesterday about using a general purpose UML modelling tool to create project Benefit Maps.

In that post I described using Enterprise Architect’s ability to create custom UML profiles to create the beginnings of a custom modelling language for project benefits management.

In this article I walk through the basics of that UML profile.

Classes

The first task was to model the core objects of the benefits model – Objectives, Benefits, Disbenefits, Business Changes and Enablers.

These are all modelled as stereotypes of the Requirement metaclass:

The more observant of you will have noticed that there is also an enumeration called BenefitvalueType. this, together with the attributes on the Benefit and Disbenefit classes create a tagged value named “Value Type” in the final model, constrained to the different Sigma Value Types.

The Sigma Value Types are used as a way of classifying benefits -  this aids with the identification of measures, and also stimulates a conversation with stakeholders about missing benefits.

Relationships

The second part of the profile contains the relationships needed for the Benefits model. As I noted before, I have decided to use realisation and dependency links to model different aspects of the Benefits model. These are included in the profile by creating new classes of the same name that redefine the relevant metaclasses, thus picking up all the default behaviour.

The profile also includes a redefinition of Association, which I will use in the next part of the model, modelling Measures.

As always, I welcome comments!

How can visual models improve the flow of work during programme shaping?

This is the sixth post in a series about applying the lessons of lean (especially lean software development) to the shaping phase of programme management.

In previous posts I have talked about amplifying learning, the application of the ideas of flow and a value stream to programme shaping, and touched on sources of “waste” in the typical programme environment.

In this post I want to talk a bit about (visual) models.

I’ve found two sorts of model useful when pulling together a programme – models of the shaping process itself, and models of the programme design.

Modelling the Programme Shaping Process

In previous posts I’ve talked about looking for flow in the programme shaping process. Every organisation, and to some extent every programme, will have a different flow for the shaping process.

For most this will involve some number of iterations of capturing and designing information, creating programme artifacts, and seeking approval from various stakeholders.  I have talked about keeping work-in-progress to a minimum, and the classic tool for managing that is a kanban board.

Modelling the Programme Design

The other area where models are vital is in describing how the programme will work and what it will deliver – in other words, the design of the programme itself. Programme documentation has always been a way of sharing a model of how things will work and what will be achieved, but I think there are lessons we can learn from other disciplines to make the documentation more useful.

Many traditional programme documents are heavy on words and light on diagrams. Words are vital for providing detail, but they are not the best choice for communicating the relationships between concepts, nor for illustrating causal chains (for example from enabling projects to capabilities to benefits to outcomes).

I’m suggesting that as programme managers we can usefully make more use of visual models to augment our programme documentation, and to model the relationships between different parts of the documentation.

There are specialist tools (e.g. ChangeDirector) which make extensive use of graphical techniques, however not every organisation will have access to these. I have had some success in using general purpose UML modelling tools to support programme shaping work, and it’s an area I am actively exploring further. One background project that I hope to blog more on later is the creation of a UML Profile for Programme Management

I’d like to hear from other programme managers about their experience with visual modelling.

Picture credit: David Larabee

This is the fifth post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.

In  previous posts I have talked about the application of the ideas of flow and a value stream to programme shaping, and touched on sources of “waste” in the typical programme environment.

Again borrowing heavily from the Poppendiecks for my conceptual structure, I want to think about learning in our context, and how we can make it work better.

Programme Shaping as a Learning Process

What are we learning about during programme shaping? A few thoughts:

• Stakeholder expectations and perceptions;
• The shape of the perceived problem, the nature of the programme objectives, the expected benefits and how they relate to each other;
• The enablers and business changes that will support the benefits;
• Increasing amounts of detail and quantification around benefits, costs, risks;
• Alternative solution approaches and trade-offs;
• The quality criteria that will be imposed at decision gates, and/or that we may determine for ourselves;

As we learn more about these areas we progressively build and refine our product – the design of the programme as a system.

This sort of learning process can be likened to the Deming Plan-Do-Check-Act cycle (PDCA).

So our question becomes “how do we iterate the learning cycle faster during programme shaping?”. Drawing on the agile software approach, I suggest the following themes:

Iterating Faster

If we are going to learn faster about what shape of programme is most likely to be acceptable and successful, we need to increase the speed with which we plan, develop and review our growing programme design. Translating good practice from the agile and lean engineering movements we get the following points:

• Break the programme design work down into small deliverables;
• Clarify the stakeholder requirements for each deliverable – “what will good look like?”;
• Build quality in explicitly;
• Actively constrain the number of deliverables started at any one time;
• Frequent feedback from stakeholders. Look at physical proximity (e.g. where the team sits), access to diaries, collaboration technology.

Build Shared Understanding

A central challenge to effective consensus building comes from the intangible nature of the concepts under discussion and the relationships between those concepts. Approaches that offer visual modelling to support rapid understanding of conceptual relationships, supported by the right blend of numerical and textual “backing information”  to support deeper understanding and analysis are helpful here.

In my experience a visual meta-model of the programme shaping artifacts is also a useful tool to clarify the dependencies between different outputs.

Simplify Programme Documentation

Published methodologies such as MSP are often (or are often interpreted as) document heavy. The work to synchronise work products expands exponentially with the number of separate but inter-dependent documents. Following the lead of others (sorry no references to hand) I find it helpful to think of different programme documents as merely different views into the programme model.

In the ideal case this will be literally true, with the model held in a central computerised repository that can create the necessary views. However many programmes will not have that luxury, and are faced with maintaining a set of separate documents. In that situation I have found the following ideas useful:

• Actively simplify the document set, don’t just produce every document that is listed in your favourite (or mandated) methodology). For each document ask yourself what question that document answers, or what decision it supports. If you can’t answer, then you may well not need it. Adopting this approach successfully may require active engagement with, and influencing of, the”quality police” – PMO, Internal Audit etc.
• Model the documentation set to clarify dependencies between documents. The systems design principles of high coherence within a document and low coupling between documents are a good guide. If all you have is Visio, then that’s better than nothing, but I’ve found that a UML modelling tool can be very useful in this regard.
• If possible, automate production of documents from a common source. For example, with the right modelling tool it may be possible to auto-generate some documents, moving a step towards the nirvana of an all-encompassing data repository.
• Use a version control system to track document history and tag consistent sets of documents. My personal preference is Subversion, as it is free, available on several platforms, well-known, and supported by a number of tools.

Synchronise Work Frequently

In the initial stages of programme shaping there may only be one or two people involved, so keeping the work in sync is often “just” the problem of keeping the document set consistent. Once more than a couple of people are working on the idea then it becomes increasingly possible for the work to diverge, increasing the risk of re-work being needed. Until someone invents automated integration tests for programme documents we are faced with using the design of our shaping process to keep the work on track.

• Faster iterations, changing relatively small parts of the concept at each pass, are the first step;
• Keeping documentation as simple as possible, with well-designed and understood inter-dependencies between documents;
• Taking a set-based approach to solution design. For example if you had a team working on high-level technology decisions for the enabling projects working alongside another team looking at organisational decisions, encourage each to maintain a set of options in their design. As the programme shape firms up, each team can narrow their options.

I’d be interested in dialogue to sharpen these ideas, do please comment below!

(Image credit: Karn G. Bulsuk)

This is the fourth post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.

In the last two posts I started to explore how we could find the value stream in the “messy” stages of early programme shaping. In this post I will turn to the concept of “waste” in our context.

In the classic Toyota Production System, seven types of waste are identified:

1. over-production
2. idle time
3. transportation
4. inventory
5. motion
6. over-processing
7. defective units

Leaning heavily on the work the Poppendiecks did to translate these concepts to software engineering, I suggest the seven types of waste for programme shaping are:

Over-production

e.g. producing documents which do not add value, and which have to be kept under configuration management

Waiting

e.g. time the team are idle waiting for decisions

Hand-offs between groups

Always an opportunity for tacit information to be lost, and the reason many organisations perceive a need for excessive organisation

Too much work-in-progress

For example creating work products long before they are needed. This “gums up the works” with documents which have to be kept under configuration management, and becomes a source of distraction

Motion to find needed information

How often have you found the situation that a critical piece of information is held by one person, and that person is in another department, or another building?

Over-refining work products

e.g. Adding levels of detail or polish which do not add to the value of the document to support decisions or execution

Defects in the work produced

e.g. Plans which do not fit strategy, products which do not stakeholder expectations, or inconsistency between documents.

I’m sure that each reader will be able to add their own examples. In later posts I’ll look at possible solutions.

Next – how do we design the programme shaping process to amplify learning?

This is the third post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.

In the previous post I started to explore how we could find the value stream in the “messy” stages of early programme shaping. Before I go on to explore the concept of “waste” in our context, I want to say a bit more about the value stream.

The key outcome of the programme shaping process is a clear understanding of the “Why”, “What”, “How”, “When” and “Who” of the programme. Different methodologies have different names for products that address these questions, and sometimes different names for the products at different stages of their development.

For example in MSP 2007, in the pre-programme and Initiating a Programme stages, most of the key questions are addressed (in outline form) in the Programme Mandate and Programme Brief, but during Programme Definition these expand into products such as the Blueprint, Benefits Maps, Benefits Realisation Plan, Project Dossier, Programme Plan, Programme Definition and Business Case, not to mention the planning and documentation around programme governance.

Regardless of the particular nomenclature, the process is one of iterative discovery and design. What we are doing through this time is architecting the “programme as management system” – the system goals, the programme “engine” and the feedback/control mechanisms.

So the challenge to find a Lean approach to programme shaping is the challenge to find a Lean approach to designing a management system.

In the next post I will explore the concept of “waste” in our context.

This is the second post in a series of thought experiments on applying Lean/Agile principles to the early shaping stages of a programme.

Here I am using “programme” in the widest sense – to borrow a definition from MSP2007 “a temporary, flexible, organisation created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives”.

The core of all lean approaches is to identify the value stream – what activities take place to generate value from the process. For example, in software development, what sequence of activities has to happen to create production applications which deliver benefit to the customer? So how do we map that to the early, often “messy” stages of a programme?

Standing back from the detail of a programme, we can see that it is (like any business activity) an investment of time and money to move the organisation closer to its goals. I think you can structure the problem as a series of steps from the strategic to the specific:

1. What challenges does the organisation face, and what objectives will it adopt?
2. What areas of change would make good programmes?
3. What would a specific programme address?
4. What specific benefits will the programme deliver?
5. What does the programme have to do to deliver the benefits?
6. (and then down into the projects and business change activities)

Many commentators would suggest that (1) is the province of strategy development and that (2) is the realm of Portfolio Management, but for the moment I’m going to elide them together – I’m trying to find the flow of value rather than establish discipline boundaries. Having said that, most of us who get involved in programmes can usually only monitor (1), so I think there is a fairly natural (albeit fuzzy) line between (1) and (2).

In terms of the programme shaping flow, we can start to see a series of intermediate products at increasing levels of detail, requiring increasing investments of time, money and resources, and which eventually (should) generate benefits that flow back up the tree. Before we can identify the value chain associated with all this activity, we need to determine how the organisation will assess value. It seems to me that the clue is in the definition of what a programme delivers – “outcomes and benefits” – and the key to evaluating those is benefits realisation management. It won’t surprise anyone when I say that in my opinion benefits mapping and related analysis is at the heart of an effective portfolio and programme process.

So the second clue about finding the value stream is to focus on benefits at each stage.

The third element is to decide how we recognise “good” quality at each stage – i.e. something that delivers value to the stake-holder. Sadly, we have no equivalent of the software world’s automated unit, integration and user tests for programme artifacts, so we need to turn instead to guidance such as MSP 2007 Appendix D “Programme Health Checks”, OGC Gateway reviews, or any other audit and evaluation approach used within an organisation. To optimise our value stream we have to optimise the flow of our work products through those constraints.

In the next article I’ll start to explore the concept of waste in our context.

This is the first of a number of exploratory posts to express and refine my thinking on the subject. I want to pull together a selection of experiences with programme shaping by looking at them through the filter of lean/agile theory.

Traditionally programme management, especially in public sector, is heavily influenced by stage gates. Having said that, the authors of more recent methodologies (e.g. MSP 2007)  recognise the need for iteration and conceived a “transformational flow” of work that delivers benefits over time.

The area that I am particularly interested in exploring is the shaping stage of a programme – the early part of the process when the stakeholders come together to agree the benefits to be achieved, the shape of the organisation after the change, the set of initiatives that will be needed, and the business case.

I see strong parallels between programme shaping and the world of software development – both are dealing with the development of concepts, and the progressive discovery of knowledge about the area of concern. So I freely acknowledge that my thinking is heavily influenced by pioneers in the field of software development such as the Poppendiecks and David J. Anderson. Of course the challenge in drawing lessons from a different field is not just to find the translation, but to recognise where the concepts differ, so I would expect that my views will move around as I develop the thoughts.

The areas that I think need to be explored are:

• Understanding the value chain of programmes, especially the programme shaping stage
• Identifying the flow and where the “pull” comes from
• Applying lean principles
• Exploring what it looks like in practice – people, techniques and tools

Next Post

Delivering successful IT-enabled business change (PDF), published by National Audit Office November 2006.

Summary

IT-enabled business change essential for reforming public services.

Many examples of failure, report examines 24 examples of success to draw out key factors, projects from £k20 to £M800+.

For the critical success factors identifies key questions to assess likelihood of success.

Critical Success Factors (and related questions)

Ensuring senior level engagement

• Is the board able to make informed judgements about the department’s capacity to manage change?
• Does the department have in place a decision making structure that will ensure strong and effective leadership of the IT-enabled business change?
• What incentives exist to drive performance?

Acting as an intelligent client

• Does the department have the necessary programme management skills?
• What is the natural division of duties between the Programme and Project Management Centre of Excellence and the Chief Information Officer?
• How will the department establish and promote an open and constructive relationship with suppliers?
• How clear is the department about the business process that it is seeking to change or develop?
• Does the technology exist to deliver the change?

Realising the benefits of change

• Beyond immediate technical success, how will wider benefits be secured?

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’m going to start with the Blueprint, since that is where our final outcomes are defined. For each area of the Blueprint I will examine each outcome, and analyse against the risk framework from the OGC guide.

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:

• Understand overall programme goal
• Think about life-cycle of that goal, and of the sponsoring organisation – i.e. Volatility
• Understand the difference between Inputs, Outputs and Outcomes
• The more volatile the goal or the organisation, the less likely that you will be able to successfully procure for Outcomes, or possibly even for Outputs.

The document then goes on to consider the risks related to organisational capabilities. The earlier in the value chain Inputs-Outputs-Outcomes, the more skills are required within the organisation for integration and change management, and the more vulnerable you are to opposition from within.

The last area of consideration is the ability of the market to supply a particular  service.

Once all three areas have been analysed, it’s likely that further iteration will be required to converge the  solution.

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.

Another insight was the importance of considering quality as a series of “nested loops”…

Further reference to the [[MSP]] manual (p77, 2003 version) identifies three areas of programme activities where quality management is involved:

1. Quality management of the governance arrangements – this corresponds to the top level “Governance Reviews” in post 3 of this series.
2. Quality assurance and review of project outputs – this corresponds to the lower three levels in post 3 of this series.
3. Configuration Management of key programme documentation.

Drawing on this we need to add an area to our Quality Management Strategy (item 3 above).

I’m puzzled that the section on Quality Management makes no reference to Benefits Reviews (they appear in the chapter on Benefits Management), but as I’ve noted, they are critical to ensuring the delivery of Value, so in my opinion they should be integrated into this strategy.

Earlier posts in the series:

• Quality Management Strategies – 1
• Quality Management Strategies – 2
• Quality Management Strategies – 3
• Quality Management Strategies – 4

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:

The activities in the first section are the responsibility of the SRO / Programme Director, often with external help such as audit.

The activities in the second section are the responsibility of the Programme Manager, assisted by the Programme Office

The activities in the third second section are likely to be the responsibility of the individual Project Managers, often assisted by the Programme Office

Earlier posts in this series

• Quality Management Strategies – 1
• Quality Management Strategies – 2
• Quality Management Strategies – 3

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:

• Firstly, the programme itself may change direction over its lifetime, reflecting changes in the surrounding environment;
• Secondly, the precise makeup of the project portfolio may change to deal with new opportunities and threats, or to accommodate changes in programme direction;
• Thirdly are the inherent changes within each project in the portfolio.

So the process(es) we invent and document in a Quality Management Strategy must be designed from the start to accommodate change in any of the inputs. That implies ongoing review at a number of nested levels.

Earlier posts in this series

• Quality Management Strategies – 1
• Quality Management Strategies – 2

I found this diagram useful to explain how the various activities and plans within a programme combine to add value for the programme sponsoring group and stakeholders:

Why do we need a Quality Management Strategy?

In an earlier post I wrote about my confusion when starting to think about how to create a quality management strategy for my programme.

Let’s go back to basics – why do we need a Quality Management Strategy?

Fundamentally it’s about ensuring (to an acceptable level of certainty) that the Programme will deliver what it sets out to deliver.

And that is about Value.

A Programme delivers Value through achieving Outcomes which deliver Benefits.

So the starting point for a Quality Management Strategy has to be around the shaping and validation of Outcomes, and the identification of Benefits.

Shaping of Outcomes is essentially a political process – framing the programme so that it meets the perceived needs of the sponsoring group.

Linking of Outcomes to measurable Benefits is a critical part of defining the Programme, and includes the identification of Benefits, devising a Benefits Management Strategy and validating the Benefits Realisation Plan.

So the first step in our Quality Management Strategy must be the processes around Planning and Realising Benefits.

That’s why Benefit Reviews are important.

I’ve been thinking about how to put together a Quality Management Strategy for the programme I am shaping. Question is, where to start…

The MSP Manual says:

[…] used to define and establish the activities for managing quality across the programme

which sounds tautologous to me.

In Chapter 9 on Quality Management, a bit more detail appears:

The Quality Management Strategy defines what criteria will be used to assess quality, what quality activities will be incorporated into the management and delivery of the programme, who will be responsible for carrying out these activities, and how the programme will meet required audit and organisational standards for quality assurance and quality control.

In Appendix B there is more specific guidance on the contents:

Description of the quality assurance, review and control processes for the programme, covering:

• What will be subject to quality assurance, review and control, and the quality criteria to be applied.
• Who will undertake quality assurance, review and control activities
• What will trigger those activities (time-based, event-based or associated with risk occurrence)
• What actions will be taken depending on the results of quality checks
• Configuration management and change control procedures
• Defined responsibilities for quality management
• Information requirements to support quality management
• Procedures for use of support tools for quality management activities e.g. change control software
• Resource requirements for quality management

All of which will be very useful to describe the headings, but which doesn’t ask the fundamental question – why are we doing this? A later post…

Shared bookmarks for del.icio.us user Synesthesia on 2007-03-20

• APM SIG: Governance of Project Management:

  Keywords: Project_Management, Programme_Management, MSP

Shared bookmarks for del.icio.us user Synesthesia on 2007-02-06

• IT Governance — An Integrated Framework and Roadmap: How to Plan, Deploy and Sustain for Competitive Advantage:
  Paper from Computer Associates this paper proposes a comprehensive and integrated IT governance framework and roadmap which identifies the appropriate current and emerging best practice methodologies for each of the major IT Governance components that mu
  Keywords: Governance
• Magic Quadrant for IT Project and Portfolio Management Applications:
  Gartner report, June 2006
  Keywords: Project_Management, Portfolio_Management, Gartner
• max’s Project Wisdom – Issues and Considerations:
  Some useful checklists
  Keywords: Project_Management, Programme_Management

The UK Department for Education and Skills are major users of Programme and Project Management. To aid programme startup, they have an approach known as The 22 Questions.

As an aid to meeting facilitation, here are the 22 questions as a MindManager Mindmap.

Shared bookmarks for del.icio.us user Synesthesia on 2007-01-12

• Reliable Project Delivery:
  The Reliable Project Delivery programme is a key element of the ‘Transformational Government Enabled by Technology’ Strategy and has been set up to develop measures to increase the success rate of the government’s major IT related programmes and pro
  Keywords: MSP, Programme_Management
• How To Think Like a Computer Scientist: Learning With Ruby:
  Book published under GPL Free Documentation Licence
  Keywords: Ruby, ComputerScience
• Podcasts from CIPD:
  Chartered Institute of Personnel and Development podcasts on a range of management subjects
  Keywords: Podcast, Management, ChangeManagement
• Managing Business Benefits: Key Principles:
  OGC Checklist for SROs and Programme Managers
  Keywords: MSP, Benefits_Management, Programme_Management
• Risk Allocation Model for Project Strategy and Procurement (OGC):
  Guidance for risk analysis of outcomes, outputs and inputs and selection of appropriate procurement and project approaches
  Keywords: MSP, Risk, Programme_Management
• NAO/OGC list of common causes of project failure:
  The top eight…
  Keywords: MSP, Project_Management, Portfolio_Management

I’ve just heard from Pearce Mayfield that I have passed the Managing Successful Programmes practitioner qualification -although the result isn’t on the APMG/OGC site yet.

Relocated from MSP blog at http://www.synesthesia.co.uk/msp/2006/10/17/mod-approach-to-benefits-realisation-management/

Update 1: As Nick Spargo points out in the comments these links are now dead. If anyone can point to the modern equivalent, that would be appreciated.

Update 2: Matthew Davis points to http://www.aof.mod.uk/, but the specific link he posts is now dead.

A series of documents from the UK Directorate for Defence Acquisition about Benefits Realisation Management

• BENEFITS REALISATION MANAGEMENT – “All you ever wanted to know but were afraid to ask” [Word]
• Example benefits strategy [Word]
• Example of a populated benefits model [Powerpoint]
• Example of an initial benefits brief [Powerpoint]
• Example of analysis tools [Excel]
• Example of a benefits ranking model [Excel]
• Example of a Benefits Profile [Word]
• Example “Measures and Owners” brief [Powerpoint]
• Template for capturing measures and owners [Word]
• Simple Benefits Tracking Document [Word]

Summary of Comments made on this post in original location

1. Nick Spargo (30/04/2008) pointed out that these links had expired.
2. Matthew Davis said (05/05/2009) “I think that you will find that the ams website has been superceded by the acquisiton operating framework and that it will be some time before the benefits work is republished as per this link:http://www.aof.mod.uk/aofcontent/tactical/ppm/content/whathappen_ppm.htm?zoom_highlight=benefits“

Shared bookmarks for del.icio.us user Synesthesia on 2006-10-16

• Scaling Agility: Agile Systems Engineering:
  Great collection of links from Brad Appleton on scaling Agile methods to enterprise systems engineering
  Keywords: Systems/Engineering, Agile, SystemsEngineering
• Scaling Agility: Agile Program Management:
  Brad Appleton has assembled a great collection of links to resources about scaling-up agile methods to the programme management arena.
  Keywords: Programme_Management, Agile, MSP

Via Brad Appleton‘s excellent post of links to Agile Programme Management resources, a paper on Combining Agile Methods with Stage-Gate Project Management.

Based on studies in three engineering companies, the conclusion is that are benefits from both the management and engineering perspective.

Good things:

• Agile method add microplanning and day-to-day control to the stage-gate methods
• Engineering teams felt more in control of their work
• Stage-gate approach improves ability of agile methods to interact with other engineering teams, other functions (such as marketing) and senior management.

Things to watch out for:

• Need to manage expectations
• Challenge on large projects of finding a “customer representative” as required by Agile methods

I spent last week on the Managing Successful Programmes course.

The trainers were good, the group size was good (9 of us), and the other delegates were an interesting and friendly bunch from a range of industries. Between us we covered print, broadcast and online media, telecomms, manufacturing, software, and a couple of flavours of consultancy.

I’d recommend this course to anyone who was interested in MSP – the training is well-adapted for adult learning, and has a clear emphasis on providing the skills to get through the exams. It is however an intensive week – in particular on the first three evenings there was two to three hours of homework each night. The homework is framed as “optional”, but as a large part of it is practice in answering exam questions, I would imagine that it would be hard to get through the exams without doing the homework.

I managed to pass the Foundation exam without much difficulty, but I won’t know the result of the Intermediate and Practitioner papers for about 8 weeks – apparently the APMG examiners are over-worked at present!

The material is still very “close to me” in my mind, so too early to reflect properly on what I have learned.

(Cross-posted from my MSP blog)

Shared bookmarks for del.icio.us user Synesthesia on 2006-10-08

• EFQM Excellence Model Overview:
  The EFQM Excellence Model was introduced at the beginning of 1992 as the framework for assessing organisations for the European Quality Award. It is now the most widely used organisational framework in Europe and it has become the basis for the majority o
  Keywords: Programme_Management, MSP, Quality, PerformanceMeasurement
• The Goal Question Metric Approach:
  Original paper by Basili, Caldiera and Rombach
  Keywords: Programme_Management, MSP, PerformanceMeasurement
• David Seah : The Printable CEO™ Series:
  A whole set of focusing and productivity tools, paper-based…
  Keywords: Personal_Productivity
• Recovering folders in Thunderbird:
  Get your mail back!
  Keywords: Thunderbird
• CDBurnerXP Pro:
  Freeware for Windows XP – the program can write CD-R, CD-RW DVD R/RW DVD-R/RW discs.
  Keywords: Software/Utilities, DVD, CD

One of the reasons I’ve been quiet in this blog has been that I have started another blog specifically focused on Managing Successful Programmes.

When I set that blog up, I was planning on attending a training course in June on Managing Successful Programmes (MSP), leading (hopefully) to the practitioner certificatation. MSP is the UK Office of Government Commerce (OGC) approach to ensuring the success of major change programmes.

I’ve set up the other site as an online learning diary, and a central place for various notes. To support the blog there is also a wiki for more long-form notes.
Unfortunately the course I was attending has been withdrawn for June by the provider. Looks like I shall now go in October. Inevitably my motivation to go through the pre-work has been somewhat reduced, however I shall continue to post over there – I’m finding lots of ways to introduce key elements of the MSP approach into day-to-day work.

This should also mean that I have a little more online time to keep this place up-to-date!

I had a good example the other day of the potential of the Stakeholder Power/Impact Matrix.

I was discussing with a colleague the framing of another potential programme, and quite informally drew a rough matrix in front of him. I explained the meaning of the two axes and then with him discussed our first impressions of who should appear on the chart, and where they should be placed.

We found the exercise illuminating, not least because the small discipline of deciding where each person or group should go triggered us to articulate some deep-seated and potentially difficult issues around certain individuals

(re-posted from the soon-to-be defunct MSP Blog)

Shared bookmarks for del.icio.us user Synesthesia on 2006-04-19

• Programme Management Articles:
  Archive of articles on the PMG site
  Keywords: MSP, Programme_Management
• Programme Management Bulletin Board:
  
  Keywords: Community, MSP
• Overview of Managing Successful Programmes (MSP):
  Succinct overview of the OGC-approved approach to major change programmes.
  Keywords: MSP, Programme_Management
• Pearce Mayfield – Programme management – Managing Successful Programmes:
  Overview of MSP course
  Keywords: Courses, MSP