© university of the west of england, bristol 2004 cpda module – foundations of systems...
TRANSCRIPT
1© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
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
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
INCOSE 2007 – Special ReportIntegrating 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
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
Recognise this?
6© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
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
User RequirementsDefinition
System RequirementsDefinition
System Design
Sub-SystemDesign
Sub-SystemManufacture
System Assembly
System Test
Sub-System Test
System CompleteValidate it Meets the User Requirements
Verify it does what it was designed to do
Validating the Design (or any
other stage) Is Also Possible
User RequirementsDefinition
System RequirementsDefinition
System Design
Sub-SystemDesign
Sub-SystemManufacture
System Assembly
System Test
Sub-System Test
System CompleteValidate it Meets the User Requirements
Verify it does what it was designed to do
Validating the Design (or any
other stage) Is Also Possible
7© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
Typical Project Profile
Time
CostsBenefit
Derived from Changes
Concept Development Engineering Commissioning
8© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
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
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
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
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
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
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
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
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
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
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
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
WBSFacilitatesThe PM Toolkit
20© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
Cost Accounting – Key Management Tool
TASK 1 TASK 3TASK 2
Work Packages
Tasks
21© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
Linear Responsibility Chart
22© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
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
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
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
Critical Path, Milestones & Baselines
26© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
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
CRITICAL ALERT OK
27© University of the West of England, Bristol 2004 CPDA Module – Foundations of Systems Engineering – Jun/Jul ’05 – Project Management
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
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
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
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
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
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
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
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)