Journalist’s note: This is my 2nd interview with Robert Buttrick, who is a very influential figure in the global PM field. This interview is specially centered on the topic of programme management. To know more about Robert Buttrick’s experience in project management, please read his two books: The Project Workout, The Programme and Portfolio Workout.
Introduction to the interviewee:
Robert Buttrick is an independent and influential advisor on portfolio, programme and project management, specialising in business-driven methods, processes and standards. He is also an Associate Teaching Fellow at the University of Warwick, a member of the British Standards Institute's committee MS2 for project management and is a UK Principal Expert on the equivalent ISO technical committee, TC258 (dealing with international standards on portfolio, programme and project management).
Robert Buttrick is also known as the author of the book The Project Workout. The book, as the flag ship publication on business-led project management, based on his field experience in the direction of portfolios across sectors as a successful practitioner, has been translated into a number of languages. Robert Buttrick is also a co-author of the PRINCE2(2017 edition) with a focus on practical considerations and tailoring, as well as a contributor to other books such as “Handbook or project portfolio management” Routledge, 2018; “Gower Handbook of Programme Management”, Gower 2016; APM Body of Knowledge (5th and 6th editions).
Due to his efforts, Robert Buttrick has received lots of awards. For example, in 2010, Robert received a Distiguished Service Certificate from the BSI for services to national and international project management standards, and in 2013 he was made an Honorary Fellow of the Association for Project Management (APM).
To know more about Robert Buttrick, please read the following interview or visit his website: www.projectworkout.com.
Part Ⅰ A programme has to work as a single entity
Q1. Do you still remember the first time when you were involved in a programme? What lessons have you learned the experience?
Yes, only at that time (1978-82) the distinction ‘programme’ didn’t exist. The programme I worked on was called a ‘project’! The lesson is that it doesn’t matter what you call something, it’s how you manage it that counts. Forty years on, we have more of a consensus on what a ‘programme’ is and can then define the practice which make a difference. I have worked on many of the standards and methods which brought this about. Labels can be useful, but it’s the results that matter, not what you call it; but defining what all those words means is important can save a lot of misunderstandings and hassle.
Q2. According to your observation, what are the common misunderstandings about or mistakes in programme management in practice?
The most common problem I see is not setting the work up as a programme, but rather designing a vertical organization like a traditional company line structure, with a CEO (programme sponsor), COO (programme manager), then a finance department, HR department, support office, quality department and a range of technical departments, depending on what the programme is to achieve. The heads of these departments are appointed, told to get themselves organized, and that is what they do. From day one, ‘silos’ are created, each with their own processes and ways of working. You can end up with half a dozen different project management, risk management, planning and reporting processes with their disparate tools. That leads to a lot of duplication and waste. Even worse, it won’t lead to effective team working. By all means, have the departments for specialist disciplines but make sure there is one set of tailorable management, planning, control and reporting processes and let the discipline based departments create their technical processes, using a common format. A programme has to work as a single entity. You need to design a matrix to ensure those working on the programme’s components (for example, projects), which form the horizontal dimension of the matrix, are using common processes and tools and have the same objectives. In this way, work can be focused on the values created rather than constrained by each department’s internal budget and disparate aims.
Part Ⅱ Programme processes must operate in the context
Q3. You’ve contributed to “Gower Handbook of Programme Management”. Which part did you write? What’s it mainly about?
I contributed to Chapter 24, An overview of the programme management process, and it’s about a lot more than just ‘process’! I begin by discussing if ‘process’ is the right word to use, or whether ‘method’ is better, as it implies a more fluid approach. I explain how processes on their own achieve nothing and must operate in the context of the programme’s culture, accountabilities, and support tools. In other words, context matters. I then propose an architecture for the programme management processes, dividing them between the integrative processes, supporting processes and specialist processes. This is now the way most standards are structured, although they might use different words, such as ‘theme’ for ‘supporting process’. I explain the different sources you can use such as MSP, ISO21503 and CMMI-Dev. I talk about the programme’s content the ‘programme components’, and how they should be managed. I describe some processes which you can use as a starting point, explaining that they need to be tailorable.
Q4. You’ve also written your own book, The Programme and Portfolio Management Workout, which came out very recently. Why did you want to do that?
I already had a very successful book, The Project Workout, which dealt with what we now call projects, programmes and portfolios. But in the 23 years since I wrote the first edition, the meanings of those words have become more commonly understood. I wanted to update the terminology and make the book more relevant to the subject as taught and practiced today. I also wanted to add more of my experience over that time period. As a result, the book started becoming rather fat! I therefore split the book into two volumes, one looking at directing and managing one project at a time (The Project Workout), while the other (The Programme and Portfolio Workout) looks at managing sheds loads of projects simultaneously. The separate books are aimed at people with different aspirations but are based on the same fundamentals and can be used together. In both books, I want to pass on the lessons I have learnt to help people think more widely about the topics. Those, who know me, say that reading these books is like having me in the room again, coaching and challenging them to think for themselves.
Part Ⅲ Programmes have a range of components, of which a ‘project’ is just one
Q5. What are the trends in Programme Management? In other words, in what direction should Programme Management develop?
Many programmes today are focused primarily on projects. We need to move to a situation where programmes have a range of components, of which a ‘project’ is just one. These ‘non-project’ components are often termed ‘other work’ or ‘other related’ work and can include support services (like a PMO), on-going improvement initiatives, such as 6Sigma and business as usual operations, such as service or product delivery. As an example, let’s look at an obvious activity which lends itself to being programme managed. In fact, it is programme managed, but those particular words aren’t generally used in this context. In product management, the programme comprises the development of new products (managed as projects), enhancement of existing products (managed as projects), the day to day in-life running of those products (managed as business-as-usual) and the withdrawal of products at the end of their life (managed as a project). In this example, the programme is more than a ‘programme of projects’. It is a programme of work comprising project and non-project content. The product manager (who is really a programme manager, but probably wouldn’t want to be called that!) has to balance the income from current products with the investment in new products, deal with innovation, competitors’ initiatives, regulatory policies (uncertainty) as well as maintaining a product portfolio people want to buy. I hope this example gives you a flavour of what true programme management can help you do and the type of knowledge needed. I go through this in much more detail in The Programme and Portfolio Workout and it is a practical way of achieving business agility.
Part Ⅳ Programme managers must operate at a more strategic level and be business leaders
Q6. Many people regard “Programme Manager” as the updated version of “Project Manager”. What’s your view? What do you believe are the top qualities / competences of a Programme Manager in the VUCA era?
I once heard of some research where the word ‘project’ was found to be associated with ‘failure’ while the word ‘programme’ was associated with ‘success’. I never found the source, but it seems to ring true! A programme, however, is very different to a project and a programme manager needs a different skill set to a project manager. This is not just my view; it is what is in leading sources, like the ISO 21500 suite of standards and the AXELOS methods. Despite what a lot of career pathways tell you, a programme manager is not a grown-up project manager. I think the ‘programme manager’ title is sometimes used in that way as it can be a tactic for getting a higher salary! If you want an even bigger salary, call yourself a ‘programme director’.
Programme managers need to operate at a more strategic level and be business leaders. Unless the programme is very simple, a programme manager will manage managers who manage managers until eventually someone manages someone doing some ‘real work’. In other words, programme managers are more remote from what is happening on the ground than project managers. As I mentioned above, a true programme is not only a set of projects; it can include ‘non-project’ work, such as business-as-usual. Programme structures are not usually obvious; there is no such thing as a ‘programme life cycle’. It’s true that programmes can be phased, but that is not equivalent to a project’s stages. Programmes have far more moving parts and precisely what those parts are is not usually obvious at the start; programmes often evolve as work proceeds.
Which brings me to the second part of your question: what are the top qualities of a programme manager in the VUCA era? Actually, I think VUCA is nothing new and programme management is suited to navigating volatile, uncertain, complex and ambiguous environments. But so are projects; it is just that projects tend to be simpler, having an obvious life cycle. A programme is likely to have many projects, each with its own life cycle, with dependencies, interspersed with non-project work. A programme manager needs to be able to deal with these larger, often complex pieces of work, know what the business issues are and define the scopes and objectives to minimize dependencies and pass as much authority to the lower-level managers as possible without losing viability, accountability and control. As far as business leadership goes, an MBA curriculum is probably more pertinent to a programme manager than a Master’s curriculum in project management. Programme managers need to have vision and focus on the outcomes, leaving delivery to the skilled project and specialist managers. A good programme manager is not necessarily a good project manager.
Part V We should use benefits and outcomes to measure the success of a programme
Q7. In your opinion, how should we measure the success of a programme?
That’s simple: benefits and outcomes. It is, however, harder to define the actual metrics to use as the reasons for initiating a programme can be almost infinite. Success (and how it is measured) needs to relate to wider sponsoring organization’s objectives and how the programme contributes to those. Success is related to why you wanted to do something, not about how you chose to manage it. A programme, because of the range of moving parts, is likely to have a set of nested success criteria as each component is likely to achieve different aspects of the objective. The programme sponsor is also likely to have to balance achievement of the component’s success criteria when they come into contention and make choices which are in the sponsoring organization’s best interests. Money also has to come into it, as without it nobody can do anything at all. Alongside this, stakeholders are likely to have their own views on what ‘success’ is, but that is another mine-field for the programme manager to negotiate.
Part VI Some moving parts in a programme don’t do what you expect
Q8. It’s said that failed projects should fail fast. What’s your understanding? Have you killed projects in a programme?
Yes, I have killed a lot of projects in a programme! For example, in one programme, costing about £1bn over ten years, we had four primary activities: developing new services, deploying the new services, running those new services, improving the business. There were about 30 services planned, and each new service had to be deployed in up to 200 locations (in this case clinics). When one service development project ‘failed’, we had to terminate 20 subsequent phase 1 deployment projects which were already under way. You might ask why we had started deployment when the service wasn’t ready. It was a matter of opportunity and risk. We wanted the benefits as soon as we could and the risk of starting deployments early was outweighed by the potential benefits if they were deployed later. By the way, many of the development projects did deliver on time, so it was a risk worth taking. We might have lost some money on that one service, but the successful ones, yielded far greater benefits than if we had waited until the delivery date for each service was certain. That’s the joy of programme management, some moving parts don’t do what you expect and your planning needs to reflect those risks.
Part VII How you engage stakeholders depends on who the stakeholders are and what you and they have at stake
Q9. What are your tips on stakeholder management in a programme?
It is the same as for an outcome and benefits focused project except that (often, but by no means always) programmes have a more complex web of stakeholders. Remember, programmes aren’t by definition bigger than projects and some programmes can be dwarfed by a single project. A programme is simply something you choose to manage as a programme. How you engage stakeholders is dependent on who the stakeholders are and what you and they have at stake. It’s independent of the management approach you choose to take. So, identify your stakeholders, understand their needs, know your friends and enemies, keep the influential ones close and use your team to spread the workload, keeping the stakeholders engaged. Ignore your stakeholders at your peril, as illustrated in one of my cartoons.
Part VIII It is the application of that knowledge that matters
Q10. Some readers complain that they have gained Programme Management Certificate, but still puzzled about the application in practice. Would you please offer some suggestions on how to apply theory to practice?
Knowledge is great but as your question implies, it is the application of that knowledge that matters. My advice is to get some hands-on experience to turn that theory into practice. Be careful, however, to join a well-managed programme. There is no point in learning from people who don’t know what they are doing. Becoming part of a programme support office is a good start. Remember that an interview for a job is just as much about you interviewing the company as it interviewing you. Find out if they actually are managing a programme formally or whether they are just using a trendy label for their work. If you have the certificate, will you know the questions to ask at your interview. Once in post, keep reading, keep learning, ask questions and broaden your experience.
Part Ⅸ Sustainability shouldn’t be an ‘after thought’
Q11. Sustainability has been advocated. In your view, how should we introduce sustainability into Programme Management?
In brief, sustainability should be introduced from the start and considered all the way through the life cycle of the solution, which can be beyond the end of the programme (depending on how you’ve scoped your programme). Sustainability should be considered in the way you do the work: in the design and the way you build, operate and ‘dispose’ of the solution. Sustainability shouldn’t be an ‘after thought’; it is a fact on the ground. Poor solution definition and ‘doing’ means poor sustainability. Good practices and a good solutions promote good sustainability. The key is, from the start, define what is meant by ‘sustainability’ in the programme’s context and then build requirements and constraints on that basis.
Part Ⅹ principles in programme management
Q11. To conclude, please summarize your principles in programme management.
There are so many lists of principles, including quite a few I’ve invented or contributed to myself! None that I have seen are ‘wrong’. I like to think of them as ‘differently right’ and adjusted to suit the person who wanted them and the context in which they are to be used. For example:
• the UK government’s functional standard on project delivery covers portfolio programme, project and ‘other work’ management and has one set of principles which apply to all of them.
• AXELOS has separate sets of principles for each of its portfolio, programme and project management methods.
On the basis a principle should be a universal requirement applicable in all situations, here’s another list of six principles for programme management, especially thought up for this interview:
(1) Ensure your programme is aligned to the sponsoring organization’s business strategy and objectives. If the programme doesn’t serve a higher purpose, then what is the point of doing it? Bear in mind that organizations can change course and this needs to be revalidated (see Principle 2).
(2) Revalidate the justification for undertaking the programme throughout its life, especially when making major commitments. Think in terms of strategic, economic, financial, delivery factors and risk. When you revalidate the programme’s justification, check the outcome is still what’s needed (see Principle 3).
(3) Be outcomes and benefits focused. Simply creating a ‘deliverable or ‘output’ is not enough. If the outputs you create aren’t used, they are useless. You should be able to trace your outputs to the outcomes which, in turn, realize the benefits. Outcomes can be achieved in many different ways, so use options to decide your preferred approach. Different solution options require different management methods which can vary radically in cost (see Principle 4).
(4) Make sure your governance and management approaches are appropriate and proportionate to what you are doing. Don’t follow process for process sake. That is what people who don’t understand what they are doing tend to cling to. Be as light as you can and as tight as you need to. Make sure your people understand the management approaches and are competent to use them, after all they need to work together and rely on each other (see Principle 5).
(5) Never scope your programme solely based on your line organization structure! Work in multi-disciplinary teams across organizational boundaries. It’s the outcomes you need and for that you need to engage the right people, regardless of where they come from. In this way you can minimize hand-offs (dependencies) and safely delegate decisions down the programme’s structure but not lose visibility. The team needs a common goal and this should be to be reflected in a plan (see Principle 6).
(6) Make sure your programme’s plan reflects the risks and has the flexibility to survive the unexpected. A programme can still be successful even if it includes some projects that don’t deliver as expected. If one approach fails, try to achieve the outcomes you need in a different way. If you are in a fast-moving environment and market, don’t take too long to deliver or you’ll be out maneuvered by the competition or emerging technologies. Every plan includes inherent risk, understand that risk and if it isn’t acceptable, achieve your aims in a different way. Don’t stay dogmatically wedded to your first idea.