1. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 1 Programme and Project Management in a Systems Engineering (SE) Environment Terry Winnington

2. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 2 Aims of this Session To look at how the now traditional art of Project Management relates to Systems Engineering To examine some of the issues that arise To introduce some tools and concepts that can be used to reduce problems (and re-scale the problem to fit humans’ minds) I am not differentiating here between Programme Management and Project Management The presumption is that you are aware of Gantt Charts and Critical Path Analysis

3. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 3 INCOSE 2007 – Special Report Integrating SE with PM Generally –the best Project Managers have been Systems Engineers –the best Systems Engineers have been Project Managers The two roles cannot function effectively without integration Types of projects that benefit most –Multidisciplinary –New technology –Technically complex Many aerospace project combine all three of these!! Source : INCOSE Insight September 2007

4. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 4 Conceptual Framework A PROJECT is a temporary endeavour with a beginning and an end i.e. not part of a repetitive routine Its objective is to deliver to meet the requirements (specifications) within time and budget constraints To warrant the use of a full blown SE approach requires a project of considerable complexity – e.g. Polaris, Apollo (where many of the SE approaches originated) The underlying reality is that requirements, circumstances and constraints change as the project proceeds – the Project Manager has to manage both the baseline plan and the impact of changes

5. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 5 Recognise this?

6. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 6 SE attempts to overcome the limitations of a traditional sequential development by:- Maintaining focus on customer requirements Testing understanding of the requirements by defining acceptance tests Modelling the system to explore the problem and solution spaces Validate the system model and design by applying acceptance tests Repeat the process through the system hierarchy

7. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 7 Typical Project Profile Concept Development Engineering Commissioning

8. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 8 Notes on Project Costs Cost savings opportunities are concentrated on the front end as is flexibility The development and engineering phases may overlap in concurrent engineered programmes Risks late in the programme are likely to incur high costs and may even be fatal (RB211, A380)

9. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 9 Good Practice for Project Managers To ensure you know where you are trying to get to you need unambiguous and validated requirements Investigate alternatives early in the programme and model them as completely as necessary Identify critical risks and resolve them early – if possible before the engineering phase is triggered If necessary extend the concept phase and early development phases before triggering full-scale development – use your Stage Gates as they were intended – as a checkpoint

10. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 10 So What is an Ideal Start for a Systems Engineered Project Stakeholders all identified Requirements determined and documented Conflicts resolved System architecture established System components defined Work Breakdown Structure Established

11. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 11 The Project Team Key players ideally involved in the concept development phase The SE function will normally report to the programme manager The concepts will be developed co- operatively between the SE function and specialist engineers

12. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 12 Evolution of the proposed system (design)

13. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 13 The SEPA Funnel Barber, K. et al, 1999;Application of the SEPA Methodology and Tool Suite to the National Cancer Institute, Proceedings of the 32nd Hawaii International Conference on System Sciences - IEEEXplore

14. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 14 Creation of the System Hierarchy and Tasks The process of task creation continues iteratively through the hierarchy Tasks will be mapped to requirements throughout (derivation analysis) All requirements need to be addressed (coverage analysis) This traceability will be maintained throughout the project This traceability will need to be maintained though organisational and contractual boundaries

15. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 15 Work Breakdown Structure (WBS) – Fans Out From the Bottom of the SEPA Funnel

16. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 16 At the Lowest Level – Work Packages Represent units of work at the level that they are performed. They should:- –Be clearly defined and identified to distinguish one package from another –Contain clear start and finish dates (once allocated) –Specify a budget in measurable terms (money, labour-hours, etc.) –Limit the work to relatively short times to provide clear and imminent deliverable allow timely measurability minimise work-in-progress financial commitments. –State what tasks have to be completed before others can start (dependencies)

17. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 17 Managing Uncertainty Some of the requirements will not be finally established and may be subject to change - these should be identified as they represent a considerable risk to the project. Some requirements are desirable but not mandatory - prioritising these is vital to reduce the risk of resource misallocation Early modelling and prototyping can reduce uncertainties quickly in the initial System Requirements Document Having experience of similar projects always helps to reduce the uncertainties in planning i.e. experience helps improve estimating Getting a Buy-In from the stakeholders is vital to managing the consequences of uncertainties

18. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 18 Typical Documents Developed by a Project Team Statement of Work (SOW) –Narrative of the overall scope of the work to be done Project Milestones –Dictated by contract conditions –Senior Management “go/no go” decision points –Project Manager’s critical review points Specifications –Precise performance criteria agreed with the customer Work Breakdown Structure (WBS) –Identifies the work packages

19. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 19 WBS Facilitates The PM Toolkit

20. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 20 Cost Accounting – Key Management Tool TASK 1 TASK 3 TASK 2 Work Packages Tasks

21. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 21 Linear Responsibility Chart

22. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 22 Workload Peaks Require Levelling – some guidlines TIME-CONSTRAINED Use early dates in the plan to generate a loading histogram. Fix all critical path activities Reschedule other activities within float to obtain a resource utilisation that best utilises the available personnel Maintaining a consistent team throughout key phases is a critical success factor RESOURCE CONSTRAINED Allow all activities to start as early as resources allow. When more than one activity is to start but resources are not available, give priority to those with the earliest latest start date. If two have the same date prioritise the shortest one. Continue until all activities are rescheduled

23. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 23 The Critical Path – And Crashing The CRITICAL PATH is the suite of dependent tasks which dictate the earliest the project can end Generated from the PERT network and often displayed on a GANTT chart – PM Software do this readily The idea is that if you crash the tasks on the critical path you can shorten the project The danger is that you may rob budget from other tasks and other critical paths may suddenly emerge e.g. Wiring the seats on the A380 was not meant to be on the critical path!!

24. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 24 CRASHING RULES Only speed up critical path activities If there are two critical paths both must be speeded up simultaneously. If there is a choice about what to crash, choose the cheapest. Only crash where Savings>Costs

25. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 25 Critical Path, Milestones & Baselines

26. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 26 Operational Tools Every task or issue should have one owner – critical to success!! Good PM’s manage by exception – deviations from plan are the trigger for corrective action PM delegates wherever possible to empower team - PM as arbiter/advocate Effective progress and issue reporting is vital across the project Risk register should be maintained – and clear flags raised –traffic lights are used often used - clarity and simplicity are the keys CRITICALALERTOK

27. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 27 Real Projects No project has ever run to plan! Change is imposed by a variety of sources –Unanticipated technical issues –Mistakes –Revisions to requirements –New technology –Re-organisations –Budget revisions –Etc……………… The plan should always contain –Slack in the timescale –Utilisation below 100% –Contingency budget

28. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 28 Responses to Deviations from Plan Containment – can the deviation be recovered by re-planning? Mitigation – can the impact be minimised by, say, shifting functionality to other elements Negotiation – explore the solution envelope and explore options with stakeholders

29. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 29 Impact Analysis If traceability of the WBS and system models to the system requirements have been maintained then:- –Coverage is assured –Each requirement is mapped to one or more work packages The impact of any proposed requirement changes can then be examined to assess the impact on the programme as a whole. This provides an objective basis for assessing alternate courses of action which extend outside the work package boundary Openness between the project team and the stakeholders is crucial to maintaining confidence and facilitating decision-making

30. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 30 Communication is King Failure to communicate effectively is the major impediment to effective decision-making The project team should endeavour to maintain shared knowledge of the detailed issues within the team Shared knowledge with the stakeholders as it relates to their interests and requirements is also vital to maintain develop their understanding of the issues If this is maintained through the “good times” then there is a basis for confidence and trust to deal with the difficult issues that arise in any project. A secondment policy and embedding are logical and effective responses to this need

31. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 31 What about the really tricky stuff? If: –the requirements are uncertain –the technology unproven –the environment subject to unpredictable change Then different approaches are required Think about an iterative programme to develop the technology or the requirements – the BOEHM spiral model can be used to incrementally reduce the uncertainties Phased delivery can reduce the length of the development to delivery cycle – for this re-examination of the partitioning of the system may be required

32. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 32 Boehm Spiral Model for Risk Reduction (often used for software developments)

33. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 33 Key points in SE projects A systems approach invests a lot of effort and cost in the definition/concept phase to reduce downstream problems It maintains traceability to accommodate downstream re- formulation of the system/stakeholder accord to accommodate the INEVITABLE deviation from the original plan Risks should be explicitly managed within any project team and impacts risks mapped to trigger contingency planning They will not work effectively without considering that humans are responsible for delivering the plan and explicit mechanisms to facilitate communication need to be considered. Empowerment of the project teams and slack, spare capacity and contingency budget are vital to effective project management

34. © University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management 34 References KERZNER, H., 2005. Project Management: A Systems Approach to Planning. Wiley, London (available electronically via Athens) IEEE Standard 1490-2003, IEEE Guide Adoption of PMI Standard A Guide to the Project Management Body of Knowledge (available electronically via Athens)