Introduction
We have to admit that there was a time when we viewed a "program", i.e. a project management program, as simply a glorified project. That is, a very large "project" that spanned a much longer time frame, could be broken down into a series of "phased projects" or sub-projects, and therefore had an extra layer in the work breakdown structure. It probably also had a lot more stakeholders, and therefore had a higher level of complexity. In other words, the management of a program was much the same as managing a project, but more so. When was that? Oh, we'd say around the development of the first project management body of knowledge (PMBoK) for the Project Management Institute in the 1980s.
Since then, an erudite and talented group of people in the UK has dispelled all of that. They have developed and published a guide to program management the purpose of which is to help "ensure success with major projects and programs of business change".[1] This original work was published in 1999, and notes the shift in intent - not just very-big-projects but "business change" - and this change is described as:
"Program management is a pragmatic approach that will help organizations deliver and realize the required benefits, innovation, and new ways of working that will take them through the next decade."[2]
And while we are on this transformation, we should note that the description of "change" is also important. The term "Change Management" is often loosely bandied around. Does that mean "business change" as defined above or does it mean monitoring, managing and documenting changes to a project's scope, quality, time and/or cost? Obviously we should use better practice and be more specific and call it either business change management or project change management, according to our intent.
Since the original 1999 work, a new team, that has included four of the original team members, has taken the transformation even further by producing a much-updated second edition in 2003. In his Foreword to this 2003 edition, Sir Andrew Turnbull observes:
"In the [UK] Government context, Program Management is what the best policy makers have always done, though they might
not have called it that: thinking through the end-to-end process to translate policy into delivery plans and delivery plans
into desired outcomes. In a commercial context, Program Management is being used to deliver corporate strategies for increasing
market position and shareholder value."[3]
Well, that's certainly nice to know. We only wish we could say the same for some of our governments in North America.
But Sir Andrew concludes his Foreword even more forcefully. He states:
"I commend Managing Successful Programs to you. If you are one of our partners in the private or voluntary sectors, you're bound to find it useful. If you work in Government, you cannot afford to ignore it."[4]
So what is this book, Managing Successful Programs (MSP), all about? Actually, it is a companion to the OGC's publication: Managing Successful Projects with PRINCE2, the UK's equivalent of the Project Management Institute's Guide to the Project Management Body of Knowledge, and that we compared back in 2002.[5] As MSP explains in the Introduction:
"Change is now a way of life for all organizations. New or improved services are delivered, new processes are introduced, supplier relationships change, and organizations merge and divide in response to political or market forces. Organizations strive to achieve excellence by improving practices and services, to be better prepared for the future, to make innovation possible and to encourage new ways of thinking about doing business. Where there is major change there will be complexity and risk, and there are usually many interdependencies to manage and conflicting priorities to resolve. Program Management is a structured framework that can help organizations deliver change."[6]
More particularly, the focus of the book in the context of business change management is threefold. The nature of a "program" may be either:[7]
- "Making and Delivering", i.e. Construction, engineering, or IT, and as evidenced by "Specification-led, output-driven, high clarity/low ambiguity, reactive adjustments to scope", or
- "Organizational Change", i.e. Business change management, as evidenced by "Vision-led, benefits driven, good clarity/some ambiguity, reactive adjustments to scope, clear levers", or
- "External or societal change", i.e. Policy, strategy, as evidenced by Vision-led, outcome-driven, ambiguity and clarity co-exist, proactive adjustment of scope, loose levers.
So there you have it in a nutshell. In the context of this range of program management description, the purpose of the MSP guide is to explain the characteristics of programs, the concepts of program management, and the main roles, activities, processes and products of the approach.[8] Interestingly, as you progress from 1 through to 3 in the list above you notice a shift from deterministic type projects to probabilistic types. That is, from those with typically well-defined product scope and hence relatively low ambiguity, to those with typically difficult-to-define scope deliverables and hence with high ambiguity and risk.
1. Managing Successful Programmes by the Office of Government Commerce (OGC), published by HM Stationery Office, UK, 1999 (original edition), Foreword
2. Ibid.
3. Managing Successful Programmes by the Office of Government Commerce (OGC), published by HM Stationery Office, UK, 2003 (second edition), Foreword, p v
4. Ibid.
5. See Comparing PRINCE2 with PMBoK® (Book review) at http://www.maxwideman.com/papers/comparing/intro.htm.
Since then, both documents have been updated, the PMBOK Guide in 2004 and PRINCE2
in 2005.
6. Managing Successful Programmes, p3
7. Ibid, p6
8. Ibid, p7
|
