Implementing the Framework
Advice from other organisations
Finding help in implementing a project’s approach
Justifiably different – tailoring
The implementation task is very large but not so large that you should give up now! Implementing a project’s approach is not a single project.
‘If there are obstacles, the shortest line between two points may be a crooked one.’
BERTOLT BRECHT
You’ve read and understood the book, bought into the principles, and now you want to apply them to your organisation. You’ve some projects going on but you are not quite sure how many. You do not know what stage in the project framework they are. You might not know who wants the benefits or even who is managing them. You now want to do something about it – but what?
Advice from other organisations
I asked a number of organisations what their advice would be to anyone embarking on the introduction of a projects approach to business in their organisation, be it for the organisation as a whole or for one particular cross-functional activity such as product development. All the advice given matched that which you would find in any good book on the management of change. However, despite this body of common sense much of this advice had been ignored by many of the companies to their cost!
‘It is the true nature of mankind to learn from mistakes, not from example.’
FRED HOYLE
‘Top management’ support was always stated as essential, particularly as the ‘project approach’ relies on them as decision makers. This is one of the few business processes where they are required to ‘live’ the process rather than monitor it. Where they are not the fire-fighting problem solvers but a key link in the chain. If they don’t perform by making good, timely decisions, it will slow projects down at best or set off the wrong projects at worst. One chief executive of a major engineering group held back his implementation for six months until he was convinced that his board was really committed. This was in an organisation where cross-functional working and project management were already well established.
COMMITMENT OR INVOLVEMENT?
Consider the great British breakfast of bacon and eggs. The hen is involved but the pig is committed.
Other valuable advice included:
- Don’t underestimate the training and coaching effort needed.
- Don’t underestimate the resources needed to support your implementation.
- Use champions embedded in the business to promote the process.
- Roll it out in parts – you can’t do all of it at once.
Finally, keep any supporting documentation simple. One organisation had the basic process written on just ten sheets of paper. This was supported by a number of more detailed guides to aid the users with particular aspects.
Of course, you have to direct and manage your business regardless of whether you have a project process to aid you or not. Many organisations have operated as functional hierarchies for years and not even heard words such as ‘cross-functional’ or ‘project’. By the same token, there are organisations today where the use of the word ‘cross-functional’ is no longer needed. They always work in teams, drawing on the most appropriate people from across the organisation to work together in pursuit of objectives. They can’t conceive of any other way to work effectively. I know which sort of organisation I’d rather work in!
A projects approach will give you the capability to know:
- what you are doing to change your business in pursuit of your strategy;
- the interdependencies between your programmes and projects;
- the benefits and risks you are signed up to.
It does this by making projects, and hence the implementation of strategy, very visible. It does not reduce or affect your discretion to direct and manage your business as you see fit. In fact, it gives you the knowledge to enable you to make better informed decisions. It also enables you to delegate more than you ever have before. You can assign programmes or projects to your colleagues and subordinates but, because they are visible and defined, you do not lose sight of them.
Implementing a projects approach entails introducing complex changes encompassing processes, systems, accountabilities and culture. This book gives you an insight into the processes, the systems, accountabilities and cultures that have been shown to work best but it is impossible to be prescriptive about how it will look in your own organisation. The easier parts to implement are the processes and systems. These are tangible, they can be written down and created. However, structure and culture are another matter. As soon as you start changing the structures, for example, relating to decision making, the defence mechanisms of those who feel threatened will rise. Similarly, just because you have a process, it doesn’t mean that some will do anything but pay lip service to it. You have to grow a culture which wants to play the game and engages all your people from top to bottom. Earlier in this book I talked about the organisation which always looked to ‘people problems’ when their process broke down. They had learned that this was usually the root cause of breakdowns rather than the process itself. We also discovered that project management is one of the few business processes which senior management take a part in rather than watch from afar. It is therefore vital that your implementation includes full briefing of the roles that those key people are to take. Remember, this is not just about processes and project managers but is about project management in totality.
Corporate maturity
One of the greatest obstacles to the effective implementation of enterprise-wide project management is the corporate culture with respect to cross-functional accountabilities from top to bottom. There are a number of maturity models being published, the most prominent being CMMI, from the Software Engineering Institute. All have a set number of ‘maturity levels’, with defined criteria and best practices. CMMI, according to the official website, is described as follows:
Capability Maturity Model® Integration (CMMI) is a process improvement approach that provides organisations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organisation. CMMI helps integrate traditionally separate organisational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.
In other words, it seeks to be a set of best practices, which, if followed, will lead to business advantage. It has four levels of ‘maturity’, ranging from totally ‘immature’ to ‘optimising’:
- Level 1 is where most people are: ad hoc project management. In fact, by definition everyone who isn’t at level 2 or above is at level 1!
- Level 2 means you can do one project at a time, but maybe all your projects are done differently.
- Level 3 means you have a common way of undertaking all your projects. This is the minimum level I advocate, as evidenced by this book.
- Level 4 means you are truly metrics driven and are an organisation which is optimising its performance.
The CMMI handbook is not a gripping read. It is the only book I’ve read which I needed to go on a course to know what it really means to say! That said, once you get through the style and the jargon there is a lot of sense in it. Used properly and supported by the right consultants, CMMI can make a difference to organisations in the system and software engineering sectors. The main driver, however, seems to be that many government departments are starting to require it as a prerequisite to bidding. That can be its success and its downfall as many organisations are likely take CMMI on in order to ‘get the badge’ rather than to really make a difference to their business operations.
I have used CMMI and can reconcile it with my own ideas in The Project Workout. However, like the Project Management Institute (PMI) (see www.pmi.org) it shows its IT contractor industry roots and perhaps that is why it is so difficult to understand.
Another maturity model has been developed by PRTM (a management consultancy specialising in high technology businesses, see www.prtm.com). It has a five-level progression model from not doing projects at all, to being able to undertake not only one project but whole herds of them. I like the model as it acknowledges the ‘ignorant’ who have no realisation of the benefits business-led project management can provide and also acknowledges the importance of organisations working together (partnering), which is increasingly common today. Figure 28.1 summarises the model.
Questions
- Which level of maturity are you at now?
- Which level are you aiming for in your implementation and what timescale?
- Are you clear on the business reasons for wanting to improve?
Finding help in implementing a project’s approach
Finding help in putting the principles and practice outlined in this book into effect can be a daunting first step. The options include:
- asking a consultant to advise you;
- asking your in-house experts;
- finding out how others solve this problem (benchmarking).
Employing an outside consultant is an obvious and frequently used choice. However, their solutions may be resisted from within the organisation. ‘We’re different’, ‘That’s too theoretical’ and ‘You don’t understand how complicated our business is’ are commonly heard. Unfortunately, much good experience, advice and money are wasted if an organisation lacks trust and belief in what its consultants are saying. Before you ignore the complaints of your people, however, consider whether the consultants you have chosen (or propose to use) really know what they are doing. Check a number of consultancies and check their former clients for references. Making a wrong move at the start could be catastrophic. Having made the selection, the benefits the consultant will bring include expertise and experience. In addition, they are able to challenge and coach your senior team to an extent that internal staff are often reticent to do.
Figure 28.1 Maturity levels
PRTM’s research shows it is not effective to move up a level until you have sufficient mastery of the preceding levels. They also show that productivity can increase by up to 50 per cent for those on Level 4 as opposed to Level 1, with commensurate improvements in growth, profit and time to delivery. Levels 0 to 2 can, to a greater or lesser extent, be driven by forward-thinking middle managers, whereas Levels 3 and 4 are impossible to attain unless senior management want it. Excellence at this level really does come down to a question of: ‘How do we want to direct our organisation?’ If you are a business leader, that’s your choice.
Many organisations use their own people. They are cheaper than consultants and may even have been recruited from consulting firms in the first place. However, if they are seen as a ‘prophet in their own country who is not believed’, the result may be that they have less credibility than an external consultant. If you propose to use your own people, check them out as thoroughly as you would an external consultant. Look for evidence that they really know what they are talking about and that they can deliver the goods.
Nowadays the use of ‘benchmarking’ is becoming commonplace and is invaluable both to the commercial and the non-commercial sectors in improving performance and finding better ways of structuring and running organisations. Looking at other organisations enables you to look beyond your own immediate local problems and see how others really work.
That said, I have found that using a combination of consultants, internal staff and benchmarking is often the most productive route into the implementation maze if trust in the proposed solutions is to be generated:
- Consultants can give a dispassionate view based on their own specialist knowledge and bring to bear considerable experience in a particular field.
- In-house experts will know their own organisation, its culture and style; they will also have to live with any solutions which are adopted.
- Benchmarking gives you a wider perspective (‘other organisations really do it that way!’).
Often benchmarking may merely confirm that the approach being taken is correct but always has the additional benefit that it may suggest alternative and illuminating approaches and experiences. Both are very valuable and it is as comforting to know you are on the right track as it is to be put on the right track.
Remember, if benchmarking is to work, you must be receptive to new ideas and even old ones you may have previously discarded. Benchmarking findings may otherwise be lost in a fog of mistrust, as may the wisdom of consultants and in-house experts.
Justifiably different – tailoring
You may have wondered, as you read this book, whether the implied ‘one size fits all’ approach is really practical. Can you really direct and manage a small internal project using the same processes as you would for a major multi-million pound endeavour? Common sense tells you this cannot be right … and usually common sense is right! All organisations are different and all have an emphasis on different types of project. The principles and building blocks in the book are applicable to all of them. However, the detail may differ. In Chapter 12, we looked at how we could adapt a standard project framework to suit different circumstances. We were ‘tailoring’ the approach for specific needs and documenting this in the business case. Similarly we can tailor any aspect of any topic in the book. For example, you will decide, based you your circumstances, what your project framework will be, how your risk log will look, how your business case will be constructed. Having defined these, you need to ask yourself:
- What differences will I permit?
- What parts are mandatory?
These are your ‘tailoring limits’. They enable the users of your processes to make their own decisions, to alter some aspects of the process, to meet their needs. Projects are self-defining, in that the business case and its constituent project definition (Chapter 19) define not only why you are undertaking a project but also how you are undertaking it. In other words, it will state what tailoring you have applied. Approval of the document should imply approval of any tailoring.
‘Difference’ is a fact of life and you should use tailoring to enable people to take a legitimately different approach, where the circumstances require it. Formal tailoring creates the control over the ‘differences’ and stops it becoming a ‘free-for-all’.
A strategy for implementation
Boil the ocean and eat an elephant
The implementation task is very large but not so large that you should give up now! Implementing a projects approach is not a single project. You cannot do it all at once, the scale of the changes needed are too extensive. You, therefore, need to split the project up into smaller parts, each of which will satisfy a particular need and give you some definite benefit. Each of these parts should be run as a project, using all the discipline that a projects approach entails. You can then ease your way forward a step at a time and start reaping the rewards early. As a start you could use the tools, techniques, lessons and principles in this book. What better test is there for a project framework than to use it in its own creation!
One word of warning: you will need to be very firm on maintaining the principles that a projects approach relies on. As the framework starts to bed in it will throw other processes and procedures within your organisation into sharp relief. Sometimes it will show them up to be inadequate. This is not necessarily the fault of the new projects process – the other procedures may always have been inadequate, it’s just that they were hidden. Alternatively, it may be that the side effects of the new project process had been missed during your trial stage. The temptation is always to stop and fix every ‘new problem’. Resist this. Keep on implementing the parts you decide to implement. If the ‘new’ problems have been with you for a number years lying unnoticed, a few more months will do no great harm. If you stop what you are doing to fix everything you find, you will end up being diverted to do more and more until you will indeed be trying to eat the elephant.
Building your implementation strategy
When undertaking complex change or business process reengineering we are often advised that it should be done in tranches, moving from one ‘temporary mode of operation’ or ‘island of certainty’ to another. Put some change in place, let it settle, put some more in place. This assumes a linear and sequential transition from one state to another. It also assumes that you can plan the overall implementation order and configurations at for each tranche, in advance (see Figure 28.2(a)).
Without trust in the solutions, the solutions will not work
A board of senior managers was listening to a presentation on the findings from a benchmarking study (Part One of this book!). A few of them were shaking their heads, commenting that ‘The approaches being presented are not used in the ‘real world’. The chief executive stopped the presentation stating: ‘You may think these approaches don’t work but the organisations we talked to are highly respected and successful and they do use them. This is the real world: forget about what you think we could or could not do in this organisation and listen.’
The design of the basic staged project framework was completed. It was agreed. It was ready to be introduced. However, one small question was raised:
Executive: ‘The gates require us to make decisions – how do we do that? Could you design a decision-making process? We need that before we go any further. We need to know how to prioritise.’
Project champion: ‘Why do you need that now? All I’ve done is design a management framework for projects. I haven’t touched decision making. You make decisions on these things now, so continue the same way until we work out a better way.’
What had in fact happened, was that by rationalising one part, the fundamental aspect of decision making was shown to be lacking. You can’t ‘process’ decision making, only process the points when they need to be made. You can, however, provide a capability to provide information to enable you to make informed decisions – but that relies on having a basic framework within which to manage in the first place. Delaying the implementation of the staged process until decision making is in place would not necessarily solve the problem and would probably lead to implementation being delayed until all process components (resources, business planning, fund management, etc.) were defined and approved. In practice, this probably means that nothing is ever implemented.
Figure 28.2 Islands of certainty and progressive change
Often the advice on implementing complex change is undertake a first tranche of changes, pause to allow the new changes to bed in (island of certainty or temporary mode of operation) and then move on with the next set of changes. In contrast, using a strategy of continuous change, moving from configuration to configuration, will give you the freedom to choose whether to carry on without limiting yourself to what may be arbitrary islands.
The advice to split the implementation up into projects and hence manage them as a programme is sound. However, the concept of progressing from one planned state to another can be unrealistic. The implementation will not be a ‘painting by numbers’ programme. Overall, it will start off as a fog and you will need to feel your way forward. Further, even if you did create a road map detailing your islands of certainty, you may impose constraints on your freedom to capitalise on implementation opportunities as they arise. Using a strategy of continuous change, moving from configuration to configuration, will give you the freedom to choose whether to push forward or pause every time a new project is set off (see Figure 28.2(b)). Such decisions must be taken in the knowledge of the prevailing workload in the organisation and level of acceptance you have achieved so far.
Assume that you have decided to split your implementation up into projects as follows:
- high level design of the final state;
- staged framework and project management;
- decision making;
- strategic alignment;
- fund management;
- release management;
- resource management;
- business planning and forecasting.
Depending on where your organisation is now, you will have a certain amount of confidence in your current operational capabilities for each area of implementation covered by these projects. For you, some of the projects listed here will be painting by numbers, some will be quests and others may even be fogs.
If you start with the painting by numbers projects, you will have more confidence in delivery and hence in securing some benefits. As for the others, you will not know how long they will take or the order in which they can be completed. Neither will you really be sure on the timing, as much of the change relies on the development of a projects culture. So you cannot predict any further islands of certainty – you are in uncharted territory. Your starting point has affected your implementation strategy from the very first day. Don’t despair, however, concentrate on what changes you want to see happen. Define these in terms of ‘conditions of satisfaction’ or Recognition EventsTM and then work out, through back-cast planning, how you achieved these.
A possible implementation strategy would be:
Project set 1. Build a high level picture of what you ultimately want to achieve and define a programme of possible projects – classify them as painting by numbers, fog or quest. This picture is often called a ‘blueprint’ and should never be confused with a project definition.
Project set 2. Implement the staged framework and project management method.
Project set 3. Implement any other painting by numbers projects you have identified. You must look for early benefits if the programme is to be seen as credible.
Project set 4. Work on the remaining quests and fog projects as soon as you can make resource available, implementing them as soon as they become clear and the conditions in the organisation are right.
The overall design (Project set 1) is critical to sound implementation. This book is a reference to help you identify and design the elements of the framework for your organisation. You will also need to know how you are currently dealing with all the activities which will be a part of your future project framework (your present mode of operation). Do not spend too long on this. You need only know sufficient to make sure that your new framework fits into the organisation and that there are no gaps. Designing the new framework can be dealt with on an iterative basis. You will not design it correctly the first time; you are bound to make a few mistakes. Accept this and plan for it. A very effective way of designing and validating the framework is to take a part of it and trial it on a number of projects. Use the learning from these to refine the approach before moving into wider implementation.
‘A man who makes no mistakes does not usually make anything.’
EDWARD JOHN PHELPS, 12 JANUARY 1899
After completing your overall design you should implement the staged framework itself (Project set 2). The benefit of putting this in place first is that it provides the foundation block and hooks that all the associated processes need to lock onto. The teams undertaking the other projects will have a known reference point to join onto (look back at Figure 14.3). They cannot help but align to each other as they are all referenced to the same anchor (represented by the gates). The work scope for this set should include basic guides outlining the framework, together with foundation training for project sponsors, project managers, line managers and team members. You should also have project coaches available to guide newcomers through the framework – training, on its own, is seldom sufficient.
The choice of the next implementation projects is critical (Project set 3). They must be those you know how to do and what to do and which will remain stable once in place. They should be ones which, when coupled with those that follow, will ensure you progress up the benefits chain. In this way, you build a launch pad very quickly from which you can progress the remainder of the implementation. Decision making and establishing a project list should be a high priority.
You may then undertake your remaining projects (Project set 4) in any order, at any time, creating continual change toward your objective rather than moving from island to island in any predesigned order. This does not mean to say that there will be no critical dependencies between projects nor any overall programme plan. On the contrary, in order to have this flexibility you must be sure of your high level design and of the possible configurations you may pass through on the way. It may also be that the particular systems or related processes in your organisation will require some elements to be completed before others. You need to consider this in the investigative stages of each project and design your operational configurations accordingly. To do this, you may need to implement temporary systems, structures and processes along the way. For example, you will need to have a project portfolio list very soon after putting the staged framework in place, if you’re to maintain control. That does not mean you must have the finished database, fully networked and operating on everyone’s desk. A simple spreadsheet may be sufficient to start you off. It could even be beneficial as a prototype to help you decide the design requirements for the final system.
You should also try to ensure that one of the early projects provides management information and reporting which will be useful to the decision makers and others involved in the process. Reporting makes the process visible and serves as a driver of behaviour. Again, this helps set the scene for a cultural shift. Provided you use the new-found knowledge responsibly, the shift will be in the right direction. If you use the new information to expose ‘wrong doers’ and punish them, do not be surprised if people become less enthusiastic about the process and work to undermine it.
When undertaking any of the projects, do not assume you need do them throughout your whole organisation at the same time. It is usually better to implement the new way of working on a particular portfolio of cross-functional projects, for example product development. Use this as the vehicle to refine and bed in the new processes, systems and structures and to start growing the new culture. Remember that business projects are usually by nature cross-functional, therefore, you will not be able to implement the framework on a phased basis, function by function. Do take into account, however, that if you implement in a phased way, you will probably come across some boundary issues where people will insist that certain projects are ‘outside the new process’. Expect and accept this. Many people will take the opinion that they can move their projects forward quicker outside the project framework and a few of them may be right, in the short term at least. As the disciplines become better established the advantages of working within a known framework will become obvious – projects will meet their objectives.
As some of your process infrastructure may be broken before you even start, it does not matter in which order the remaining projects are introduced. You choose the order which suits your own circumstances and the timing of when the quest and fog projects come to fruition (Figure 28.3). At the start you will notice inefficiencies but these will reduce as more of the ‘final configuration’ comes into being. People may even start to solve some problem areas outside the formal programme. As they will be aligned to the core staged framework there will be little danger of conflict. In this way, certain parts of the organisation can adopt certain elements before others if it suits their needs at that point in time. The fact that people do this is evidence that the approach is naturally gaining acceptance and that part of the cultural shift is happening.
Figure 28.3 Implementation of a projects approach
Think of the implementation of a jigsaw. The work from Project set 1 will give you a view of the final picture, although some parts may be fuzzy. Fill in the new pieces as projects are completed. The picture will become clearer as more of the pieces are in place. Do not think of it as building a wall. In a wall it is not possible to put the coping stone on until the bricks below are in place. With a jigsaw, you can put any pieces in place as and when you see fit.
WHAT DO I DO WITH THE EXISTING PROJECT PROCESSES? A CONVERGENT STRATEGY
You will most probably have some parts of your organisation already using a projects approach. They may also be backed up by excellent good practice tools and guides. Should you ask them to throw these away in favour of an organisation-wide approach which is as yet unproven? If you try this you will meet resistance. Your aim is ensure that change in your business is managed well and properly directed. Your aim is not to force people into a straitjacket process. Make sure you involve the key players who are champions of their local project processes. Have them design the detail of the new process adding whatever they can from their own toolkits. Don’t insist they follow the new process from day one. Start off by saying it is for those people in the organisation who have nothing and it is for the senior managers who will act as project sponsors or project board members. You can then ask them to show how their local processes align to the new one. Where possible, ask them to adopt any new terminology (especially stages, gates and key roles) and any templates. Over time, the local processes will converge into a single ‘best way’.
How long will this take?
The time taken to establish a viable project framework depends very much on your starting point. If you are an organisation that is used to cross-functional working and puts more emphasis on role than formal job description, much of the culture will already have been established. If, however, your organisation is a very functional-led hierarchy where rank is highly prized, the change will be a shock. If you have stable leadership, the speed with which you can move forward will be greater than if your leadership suffers frequent change. In fact, if your organisation is one where change is relentless, make sure that you implement in bite-sized chunks so that at least part of the jigsaw is established prior to a change at the top. Many implementations have failed as they never quite got there before the old top team went. Nevertheless, a period of two to three years for fully establishing a project framework, fully integrated into the business (shown on pp. 173–175) would not be uncommon.
A staged process together with its associated documentation and training can be launched within three to six months of a decision to move forward. After that aim to have another major piece of the jigsaw in place every three to six months. Remember that one factor which will influence your rate of change is the state of the business processes and culture in aspects which influence projects. The better they are, the quicker you can move forward.
BEING HELD ACCOUNTABLE
If you are an invisible project sponsor or manager on an invisible project which few people know exists, let alone what it is for, you may take your accountabilities less seriously than if your name is published to the organisation in a list against the project with key milestones appended. In the former case failure can be hidden, objectives can be recast to suit performance. However, in the latter you are being asked to deliver on a ‘promise’ and being held accountable. This may sound hard, but remember that the project has been approved in full knowledge of the risks and that stopping the project, if circumstances dictate it, is a success – you are not expected to be Superman or Wonder Woman.
