• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile project management in heavy engineering design (John Underhill, Babcock)
 

Agile project management in heavy engineering design (John Underhill, Babcock)

on

  • 523 views

Assurance of agile projects conference, 27th November 2013

Assurance of agile projects conference, 27th November 2013

Statistics

Views

Total Views
523
Views on SlideShare
213
Embed Views
310

Actions

Likes
0
Downloads
6
Comments
0

1 Embed 310

http://www.apm.org.uk 310

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Context – Who and what does Babcock do, what I mean by Heavy engineering <br /> What – What design work are we talking about <br /> Why – Learning from previous contracts and the desire to do it better <br /> When – a brief description of where we are with ou <br /> Who – the stakeholders in this new approach <br /> How – some of the techniques we have applied to implement our agile approach <br /> What are we learning – a summary of the things we have discovered to date <br />
  • Approximate length of the stowage – 10 metres, 3 metres wide per stowage <br />
  • So taking the “why” we boiled this down into some specific aims. <br /> Point 1 – self explanatory <br /> Point 2 – It was perceived that there where lots of emergent issues that needed to be dealt with <br /> Point 3 – Previous experience had shown that some form of tighter control was required in the System Design and Design Definition Phases <br /> Point 4 – It was felt form the Project Mgmt community that the engineers had been distracted from delivering the benefits of the projects, often by hearsay or potential changes <br /> Point 5 – The previous point leads into the next. The critically review part of this headline is very about the Project Mgmt community reviewing any changes before it reaches the engineering teams at the coalface. This prevents that perceived distraction. But for those changes that are to be realised, they must be properly recorded, planned and monitored <br />
  • First point out that I am not a Agile expert or Scrum master. Our approach is based on the reading around the subject and applying some of those techniques, not necessarily in the “text book” manner. <br /> Sprint period of 1 month – decided in agreement with the engineering teams <br /> Records of the sprint reviews are kept <br /> Identification and risk category applied by the engineering teams themselves so they are bought into the decision. It is the project mgmt teams role to bring the understanding of the overall delivery plan and schedule to “keep the engineering teams honest” <br /> By setting the sprints at 1 month intervals, there are only a finite number of sprint phases we can go through before DDR. It therefore gives the project management team the understanding of how progress is being made relative to the time remaining. <br /> The amount of risk exposure remains indeterminate – however, as the DDR deadline approaches we can clearly identify those outstanding issues that can be dealt with. Not all issues have to be dealt with; with the agreement of the Chief Engineers agreement some issues can be dealt with during normal business as part of the Production definition phase. This is fundamental to the control of scope gong into the DDR – it also means that there are no technical surprises for the technical council during the design review. <br />
  • So how did we implement the vision and what tools did we use… <br /> These are the headline topics and the following slides will show the practical examples. <br />
  • This is a list of all tasks across all sub systems. The tasks are not sorted into any kind of order at this point, this is the data gathering point. <br /> So we have the Tasks title…named by the engineering teams. <br />
  • Things to note – <br /> The prioritisation table shown is for one team. There are 5 teams within our direct sphere of influence. But there are also priority lists for the other stakeholders. That can include our customers (Project Teams), Analysis teams, Test teams etc. <br />

Agile project management in heavy engineering design (John Underhill, Babcock) Agile project management in heavy engineering design (John Underhill, Babcock) Presentation Transcript