Complex project management
•Download as PPTX, PDF•
2 likes•8,775 views
A presentation by Carolyn Limbert, made at the APM South Wales and West of England branch seminar 'Project Controls: A 1 day Seminar' on Wednesday, 2nd October 2013
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Complex project management
Similar to Complex project management (20)
More from Association for Project Management
More from Association for Project Management (20)
Recently uploaded
Recently uploaded (20)
Complex project management
- 1. Complex Projects Carolyn Limbert, Principal Planner, Harmonic Ltd, October 2013 “I think the 21st century will be the century of complexity” (Hawking, 2000)
- 2. Outline ● What is Complex? ● Complex Projects ● Planning and Control in Complex Projects ● APM View on Complexity
- 3. What is Complex? Making Mayonnaise? Building a Jumbo Jet?
- 7. Aircraft Carrier – Complicated or Complex?
- 8. National Audit Office – Complex Projects MoD – Ministry of Defence DfT – Department for Transport DCSF – Department for Children, Schools and Families DCLG – Department for Communities and Local Government DCMS – Department for Culture, Media and Sports HO – Home Office MoJ – Ministry of Justice DWP – Department for Work and Pensions DH – Department of Health (National Audit Office, 2009) DECC – Department of Energy and Climate Change HMRC – HM Revenue & Customs
- 9. Back to Basics New view on PM Technical Technical Schedule Schedule Cost Cost Context Financing (Strategic Highway Research Program, 2012) “The intrinsic complexity of projects, in part, is driven by political, social, technological and environmental issues, as well as tight fiscal pressures, end user expectations which may change dramatically during the life of a project, and government instability.” (ICCPM, 2012)
- 10. Complex Projects Low Uncertainty Closure Implementation Scope: WHAT Mobilisation Objectives are to be achieved Definition Concept Initiation High Uncertainty Low Uncertainty Delivery: HOW To implement objectives Adapted from; (Dombkins, 1997)
- 11. Complex Projects Low Uncertainty Closure Scope: WHAT Objectives are to be achieved Mobilisation Definition Concept Initiation High Uncertainty Low Uncertainty Delivery: HOW To implement objectives Adapted from; (Dombkins, 1997)
- 12. Complex Projects (Remington, 2011) Expert based consultative leadership Experimental, collaborative leadership Simple, best practice leadership Crisis leadership, directive, rapid action to prevent collapse Tipping point: usually no way back Control Processes are clear Things go to plan Complicated Complex Chaos Risk events escalate rapidly Innovation & learning high
- 13. Planning Complexity System Engineering Project Processes Enterprise Processes Enterprise Environment Planning Assessment Control Management Decision Risk Configuration Information Investment Making Management Management Management Management System Life Cycle Process Technical Processes Process Management Guidelines Stakeholder Requirements Architectural Resource Management Requirements Analysis Design Definition Quality Management Implementation Integration Agreement Processes Enterprise Environment Management Investment Management Verification Transition Operation Validation Maintenance Disposal
- 14. Planning Complexity System Engineering ● You cannot optimise a system by separately optimising its components ● Focus on defining customer needs and required functionality early in the development cycle ● Understand the whole problem before you try to solve it
- 15. Planning Complexity Upfront Planning: Scope ● Scope start with the Finish ● Scope Management; • Product Scope – Required Deliverables meeting the agreed specifications – WHAT? • Project Scope – Work required to deliver the product scope – HOW?
- 16. Planning Complexity Agile DSDM – MoSCoW Prioritisation Must have Should have Could have Wont have* • The Project cannot deliver on the target date without this • There is no point deploying the solution without this requirement • The solution will not be legal / safe / fit for purpose • The requirement is important but not vital • The requirement may be painful to leave out but the solution is still viable • The requirement may need some form of workaround • The requirement is wanted or desirable but less important • If the requirement is left out, the impact is minimal • Project team has agreed it will not deliver this requirement • Requirement is not needed for the solution, and is a low priority * This time…
- 17. Planning Complexity Rolling Wave Design Build Planning Detail Plan Project Timeline Gate Review Planning Period Test Handover Support
- 18. Planning Complexity A suggested approach: Design Phase Should Have Requirements Must Have Requirements Subsystem A Subsystem C Subsystem B Subsystem E Subsystem D Could Have Requirements Subsystem G Subsystem F Project Timeline Must Have Design Elements Should Have Design Elements Could Have Design Elements
- 19. Summary ● Ambiguity heightens complexity ● Upfront scope planning contributes to project success ● Fight the rush – you don’t want to have implementation starting with no scope definition and no planning ● Prioritisation – Know your Must Haves from your Could Haves
- 20. APM Project Complexity Matrix
Editor's Notes
- What do we really mean by Complex?, Is there a difference between complex and complicated?, How is planning undertaken differently to traditional projects? What knowledge and competencies are required to deliver complex projects? I am going to explore the debate around planning Complex Projects.Before I start, just a bit about me;My name is Carolyn Limbert and I work for as the Principal Planner for Harmonic Ltd – a professional services provider, working across multiple industries within Project delivery.My experience lies mainly within the Defence Sector where I have worked for a number of large Defence companies on some of their most complex projects. I have also been involved in classified projects which introduces an extra level of complexity to the project environment – clients include Lockheed Martin, Aircraft Carrier Alliance and BAE systems
- The use of the word, complex is causing much debate amongst project management practitioners.The question everyone asks; Is my project complex? Every Project Manager should consider their project complex in some shape or form – In this presentation, I want to explore complexity, and really get some discussions going around what is a complex project and what is a complicated project.In order to do that I will first talk around the theme of complex and what we mean by it?I will then take this definition of complex and have a look at how effective planning and project control can support a complex projectFinally, I will show you a few areas you may wish to explore within the APM, as they develop their views on complexity.
- I’m going to talk through some different views – some of which you may or may not agree with but will be food for thought…An interesting analogy was quoted in a blog on the subject from a book by Mark Earls.He presented two situations and asked the reader to judge which is more complex – Mayonnaise or the Jumbo Jet?Lets break it down;A Jumbo jet is made up of millions of tiny parts. If you had the time, patience, skill and a good manual, you could take the plane apart and eventually put it back together again.Mayonnaise on the other hand is different –It is the result of the interaction of its ingredient and the way you add them to each other. You cant take mayonnaise apart to produce the original ingredients and then recombine them. You don’t know how the mayonnaise is going to turn out until you add the ingredients together – any slight change to the ingredients, quantities, the method of adding them together, or even the ambient temperature of the room can have an unknown effect on your end result. Its not the recipes fault – it’s the element of the unknown, the bits the recipe cant tell you and to a degree, no matter how many times you make it, there will always be an element of uncertainty that you cannot control.So he proposes that complicated is reducible and re-combinable. Mayonnaise is neither one of these things which is what makes it complex.I know the system’s engineers among you may not agree with this but its one view to consider….
- This is another comparison which shows different scenarios as you move through from simple, to complicated to complex.What I found interesting was the more I looked at the difference between complicated and complex, the element of ambiguity and the world of the unknown was the key differentiatorRaising a child, as all parents can appreciate is a perfect example of a complex situation. It doesn’t matter what your past experiences are, children will never fail to surprise you and you can never raise two children the same and expect the same outcome.You can however build multiple Jumbo Jets using the same approach, and be confident that if you follow a consistent approach and there are no extenuating circumstances, you can create a number of jumbo jets that can all fly and operate in a consistent manner. Likewise with sending a rocket to the moon, again, extenuating circumstances aside – There is a fixed route to doing this, the objective and outcome is clear. With the correct level of expertise, you can model and understand the environment to ensure that design and procedures are going to result in a successful mission.So before I move on, just one final example;
- Did anyone see this image doing the rounds on the internet when it went viral in 2010? Can anyone tell me what this is?General Stanley A Mc.Chrystal, the leader of American and NATO forces in Afghanistan, was shown this PowerPoint slide in Kabul that was meant to portray the complexity of American military strategy and obtaining Afghanistan stability. He remarked dryly in the meeting; “When we understand that slide, we’ll have won the war”This represents a truly complex system – If one of these tiny aspects changes, then we cannot predict what the effects are on other sections of this system. The aspects of the unknown in this scenario are huge. The level of unpredictability is unmeasurable.
- So how does a fiendishly complicated jumbo jet, or rocket to the moon become complex?My view: People and the External EnvironmentPut a crew and passengers into the jumbo jet or a crew on-board of the rocket, then you need to consider Human Factors, and add other factors in like the weather and try to figure out what might happen on the flight. Try and plan for all eventualities. Suddenly we go from complicated to complex. You could study the lives of all these people for years, and the weather patterns for years, but you could never know all there is to know about how they will interact. You could make some guesses, but you can never know for sure. And the effort to study all the elements in more and more detail will never give you that certainty.
- As I mentioned in my introduction,I spent a few years working within the Aircraft Carrier Alliance. Now this project is undoubtedly complicated. But is it complex?It has been quoted as being one of the biggest engineering projects in the UK behind the Olympics.On paper, you could argue that it is complicated rather than complex. The carrier was separated into modules or blocks, each of which are then built and integrated together like a large jigsaw. With enough knowledge and expertise, you could understand the intricacies of the design and the build standards. However, add into the mix;The fact that this is not just being conducted within one organisation, but within an alliance of multiple organisations, all with their own operating structures and procesesThe different geographical sites on which the carrier is being constructed and the logistics needed to ensure transport to Rosyth and then onward integration is a smooth processThe instability of the environment that the carrier project has had to navigate through in its historyThe volume of change the project has undertaken over the yearsSuddenly the environment and the factors that contribute to a projects success or failure make this large complicated build an extremely complex project.So now we have a view of the world of complex and complicated systems….You don’t have to look very hard to find a project that has failed in recent times. Is the reason for failures complexity? Are projects getting more complex? Or merely more complicated
- This graph shows the total cost in billions of pounds the top 43 of the most complex government projects in 2009 separated out by department. With so much money invested in projects, instead of having them contribute to the further statistics on project failures and over-runs, how can we optimise our Project Management approach to best manage these complex projects?
- Traditional PM dimensions can be summarised in the well known Triangle of Technical, Schedule and Cost. In order to be successful, you need to control these three aspects to successfully deliver a project. Now we all know that when you try and put that magic combination into practice, its not as easy as it looks on paper. Reality takes over, and as you try and control these aspects, other things get in the way.In analysing their project success factors, the Highways Research Program added another two dimensions into their view of Project Management, which they deemed are essential for the PM to manage and understand in order to be successful on modern projects;ContextThis refers to all external factors that have an impact on the project. Context factors can be some of the most difficult to predict and manage. Context includes stakeholders, environmental issues, legal and legislative requirements, local issues and project specific factors.FinancingIt is no longer sufficient to merely know the projects cost. The owner must know how the project will be paid for and integrate that knowledge into the scope of work. The mechanisms of financing can have a direct impact on the project design, the speed with which the project can be delivered, and the ability to achieve contextual requirements. Projects are often allocated a fixed cost profile which must be adhered to. This impacts every aspect of the project’s management.<READ QUOTE>So with this in mind, how do we classify a complex project and does complexity change over time?
- Taking any project as an example; How can we categorise that project in terms of how complex it is?Traditional thinking shows the complexity scale in terms of what the objectives of the project are, and how the project is going to implement them.If you then take the APM project lifecycle and overlay the different phases over this complexity chart, then traditional thinking shows that you gradually reduce the complexity of the project as you progress through the lifecycle, understanding the objectives upfront, then implementing the objectives throughout the implementation phase. Both risk and uncertainty is reduced throughout the project lifecycle.
- More often nowadays, you see projects that have incomplete undefined objectives right the way through to mobilisation and through into implementation. This means that the project is stuck in the “complex” environment with a high level of uncertainty as to both what the objectives are and how to implement them. This means that by some miracle, the project has to launch itself from an area of high uncertainty to an area of low uncertainty in one phase of the lifecycle – a difficult task, especially if your environment changes around you at the same time…
- So any project will fit somewhere along the scale of complexity. In its simplistic form, you have Control vs Chaos.On the left hand side, you have a controlled project. Objectives are simple, processes are clear and things go to plan. You can operate best practice leadership and have a good result.On the right hand side is chaos. This is crisis point on a project, where risk events escalate quickly. The PM needs to implement rapid action to prevent collapse, and if this is not successful, there is often no way back.In the middle is where most projects sit. Two of the largest UK projects which can be defined as Complex are the Olympics and the Aircraft CarriersNow, think about the Olympics as a complex project. London 2012 was delivered on time and within budget. It was a successful complex project. But how did the management of the project contribute to its success?They provided significant upfront investment in scoping and planning the programme. It is the acceptance that the front end of a project costs money. Whether it is the private sector or the public sector, clients don’t like spending money at the front end. But if you spend more money on investigation and understanding what you really want, then there is a lot less risk of getting to the end and realising the end product is not fit for purpose. The established their requirements at an early stage, and could therefore provide a strong plan for execution.Interestingly, the project limited innovation, and avoided high risk, high innovation solutions to their issues, and opted for scaling tried and tested approaches. This decision actively stopped the project from entering a chaotic state, and instead focused on having experts collaborating and providing leadership. They also had a structure to allow for rapid decision making, which allowed the project to stay on plan.Within the Aircraft Carrier Alliance, collaboration was also high, with multiple businesses that were usually competitors working together for the same common goal. Alliancing was a new concept for Defence projects at that time, so the approach was experimental. However, because of the complex nature of the stakeholder map, there were often different stakeholder agendas, with each of the stakeholders trying to achieve different objectives. This made the environment difficult to navigate.The Carrier project due to its size and complexity, struggled with the definition and control of requirements. There were a number of design U turns which increased cost and also increased ambiguity.Decision making was slowed down quite significantly by the complex web of suppliers and subcontractors, and their differing internal operating procedures. Messages also had a high risk of turning into “Chinese Whispers” and as a message moved through the hierarchy, there was a risk of that message becoming distorted or diluted by the long chain of communication.This stopped the project from managing itself into a complicated state, and infact the design phase and a significant section of the build and integration stayed truly complex.
- So now we have got to grips with Complex Projects, and what we mean when we say complex, I want to look at Planning and Control.It is important within complex projects to establish the core link between the Systems Engineering Lifecycle Processes with Project Management processes.As highlighted, Planning and Control are two critical areas which reside in both frameworks, therefore Project Planning and Control must take into account both Systems Engineering approaches and Project Management approaches.The importance of the alignment of approaches has been recognised by INCOSE and the APM, and they are currently working together to further define this relationship and provide amongst other things a competency framework which will go a long way to demonstrating the competencies required to manage complex environments utilising both PM and SE concepts.
- To provide a top level overview, Systems Engineering philosophy is underpinned by three important points;You cannot optimise a system by separately optimising its componentsFocus on defining customer needs and required functionality early in the development cycleUnderstand the whole problem before you try and solve itI talked about the Olympics as a successful project, and how its success was down to its upfront scoping and planning. If we fail to follow this good practice and if we fail to provide the project with an adequate upfront scoping period, then we are undermining the systems engineering philosophy, and are rushing into a problem that is not fully understood, and the customer needs are not fully defined.It is also important to factor in key aspects of whole system testing into the planning process throughout the project to ensure that the solution is fully tested before delivery. Taking the Olympics against as a case point, they set aside the last year for testing their system to make sure that upon delivery all issues had been resolved.Can we honestly say that we follow this philosophy every time we operate a project, or do we allow external factors to push and rush the process, meaning that ultimately we fail in our objectives?
- Taking the theme of upfront planning, I want to touch on how a complex project could be planned;It is an impossible ask for a project to plan to infinite detail every aspect of the project upfront. The planning time for that would be unacceptable for even the most forgiving of customers. And it is impossible to be certain of that level of detail so early on in the lifecycle. Change will happen.It is however crucial to establish the scope upfront, and have that agreed by all stakeholders.Scope starts with the Finish. You need to understand where you are going, and understand your problem before you can begin to design a solution. Scope Management is fundamentally centred around the WHAT and the HOW – WHAT are your required deliverables and HOW are you going to deliver them. Systems Engineering principles can help define both of these aspects, and from this you can start to develop a WBS structure which helps you on your way in planning your project.However, how do you establish priority? What if time is an issue?
- Upfront early project requirements definition can benefit a great deal from applying some of the DSDM Agile methodologies, such as the MoSCoW Prioritisation method.This prioritisation model takes each of the requirements and assigns it a criticality of;MUST HAVE: These are the requirements that are completely non negotiable. Without them, the project will not provide a solution to the customers problemSHOULD HAVE: These are the requirements that are still important, but with some pain, could at worst case be taken out, however there would need to be workarounds and stakeholder management and buy-in to remove these requirements from the scope of the project.COULD HAVE: These are what I call the “nice to have” requirements. Without them, the project solution will still deliver, however there is value to adding these requirements in for a more complete system. These are the requirements where if time becomes tight, are the first to be cut out of the scope.WONT HAVE: These are the requirements that have been agreed by the customer and project team are non essential and are therefore being left out of the scope of the project deliberately. This is not to say however, that if the project is awarded an extension, or if there is a delay elsewhere, then some of these non essential requirements cannot be added in at a later date if they do not detract from the main project priorities.This approach could be flowed down through all of the subsystems of the project, to ensure that there is a consistent prioritisation approach that is clearly communicated and agreed with Systems Engineering and the Customer and documented accordingly. This allows for flexibility within the project in its approach to development without deviating from the scheduled end date, which is often immovable in projects.This was the case for a recent classified project I was the Lead Planner for. It had a short timescale to deliver a high level of project requirements. The project was slipping behind schedule as unforeseen technical complexities were becoming apparent along the development phase. As a result, the project needed to cut some of the scope out to still preserve the end date which was fixed in time. The project had not prioritised their requirements upfront, so as a result had to spend additional time at the critical part of the project deciding which requirements were less of a priority therefore could be removed from the project scope. A key lesson learned from that project was to prioritise requirements and scope upfront, so that if this situation was to occur again, then quick action could be agreed and implemented.
- Complex projects span multiple years, and span multiple phases of a product lifecycle, including maintenance and support.It is often not possible to foresee the future activities in a project with consistent detail over the entire period of the project. You don’t know what your testing schedule will be until you are sure of your design for example. Therefore planning is often done in waves or stages, with the activities in the near term planned in detail and the activities in the longer distance of time left for future detail planning.Rolling waves are typically anchored to key milestones or gate reviews of the project, marking a significant advancement in the design, or the completion of one phase of the projects lifecycle.Where detail is known, packages of work are planned to the level of detail available and until their natural end date. Upon reaching each of the planning periods prior to a major gate review, further detail is planned out where known for the next phases of the project. Ideally, the planning detail should be reviewed as part of the gate review process to check its realism and to ensure that it is bought into by the stakeholders.This approach helps a project where detail is not known upfront, and planning time is tight in its initial stages, however tight control of the planning windows must be established to ensure that the schedule is continually developed to ensure scope is managed and timescales delivered upon.
- So I now want to bring together all of the key learning points that I have touched upon throughout this presentation into a suggested planning and control approach for complex projects.I believe complex projects require a more adaptive flexible planning approach to allow for the development of the system and the gradual move from a complex state to a controlled and completed state. By cherry picking elements of Agile methodologies and Rolling Wave planning, it is possible to integrate them in an effective way that can still utilise APM Project Management best practice.To demonstrate this I am going to zoom in on the lifecycle and focus on a typical Design situation. Taking the MosCoW Prioritisation, I am going to separate the design phase into three key sections – The Must Have Requirements, the Should Have Requirements and the Could Have Requirements. This forms the basis of your Rolling Wave.Under this, a number of different subsystems will fall into each category depending on their criticality to the overall system design. This will put the order of design into some form of priority.Taking each subsystem in turn, you can then prioritise the design activities using the MoSCoW prioritisation to help to schedule the activities that form the design for the subsystem.What you then have is a fully prioritised network of activities that will allow the project to hit its milestones.Add on top of this the review points, and at each review point the project makes a decision as to if they need to remove scope or add scope back into the schedule depending on its performance to date. Prioritising the must have’s gives the project a lot better chance of success.
- So in summary, the key points to take away are;Ambiguity heightens complexity – It is the unknown aspects that cause complexity. Trying to eliminate ambiguity in any way possible allows for the project to transition from the complex end of the spectrum to the complicated area.Upfront scope planning contributes to project success – This has been proven in the Olympics. By investing in upfront scope definition and planning activities, you are lowering the ambiguity and increasing your projects chance of successFight the rush – Remembering that you want to try and lessen the complexity through each stage of the lifecycle. Challenge the processes. Ask continually, how am I actively lowering my ambiguity and increasing my understanding?Prioritisation – Know your Must Haves from your Could Haves. Utilise Rolling Wave and MoSCoW techniques to help you to schedule in a prioritised way, so that if you do have a milestone that is fixed in time, you can trade in scope by eliminating your Could Haves. Agreement of this categorisation upfront from both your customer and your project team will save a lot of disagreement if your project slips behind schedule and the team are trying to avoid failure.
- Just as a final note, The APM has a Project Complexity Matrix which can be found within the APM Competency Framework, where you can compare your project against a set of criteria to establish its complexity.
- To become an APM Registered Project Professional (RRP) you must be able to demonstrate management of a complex project. This questionnaire is intended to help you determine if you meet the project complexity criteria for APM Registered Project ProfessionalThis is a good place to start to judge your skills and experiences in the world of complex projectsThankyou for your attention today, and I welcome any questions or comments.