The future of project management - changing the change function
Upcoming SlideShare
Loading in...5
×
 

The future of project management - changing the change function

on

  • 439 views

...



There has been a lot of interest about Agile in recent years, mainly due to the success in the IT industry; however there is a lot of interest in applying the Agile methods to other types of environment, not just IT.
This conference uncovered some of the myths around Agile, discussed how Agile can be scaled to large complex projects, looked at case studies, talked about Lean Agile and fed back what governments think about Agile.
The presentations sparked some interesting debates, even between the speakers, but soon some common themes started to emerge from each of the presentation.

Agile is not a methodology – it is a way of thinking. There are Agile methods, ranging from project management methods to software development methods but the agile manifesto, which was mentioned almost be every speaker, does not actual prescribe anything.

Being agile is not an excuse to avoid doing things, like planning and risk management. Being agile has a lot of parallels to Lean – you do what needs to be done, no more and no less.

Agile is not new, Julius Caesar used agile, he just did not call it agile. There are a number of companies and projects who are agile, but did not realise it and jumped on the band wagon when a name was given to their behaviour.

Agile is about giving your customer what they want, regardless of what it says in the contract - they have the right to change their minds. Agile is about people and collaboration, not the processes or tools although these do help to be more agile.

After lunch, we had a presentation from Project Place and learnt about their latest collaboration tools, including KANBAN boards. The idea is not new, Toyota have been using them for decades, but they have been given a new digital face lift.

Finally, thank you to our sponsors Project Place, DSDM and APMG, to the speakers for giving up the valuable time for free, and to Anna and Nigel for their support in pulling the event together.

Statistics

Views

Total Views
439
Views on SlideShare
247
Embed Views
192

Actions

Likes
1
Downloads
14
Comments
0

1 Embed 192

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

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
  • In many project management texts, the authors will talk about the time / cost / quality triangle of variables that a project manages. In reality there is an implicit assumption that the features are fixed. This is because it is a valid assumption in most construction projects and this is where the project management discipline emerged from. However this is not a valid assumption of “stranger” projects. In fact the whole point of software is that it is relatively easy to change. This is also true of business change projects, part of the issue is defining how far the scope of them will run. <br /> <br /> So if you want to deliver on-time and to budget (and let’s assume that quality is actual a facet of requirements), then all you can do is vary the features or put a significant amount of contingency into the project, which effectively put up the costs / wastage. <br /> <br /> At a conceptual level this seems relatively simple, but it does mean a 180 degree shift in thinking about how to deliver projects. Take one example, have you ever tried to fix an endpoint in a task or project in MS Project; it is almost impossible to do <br /> <br /> To answer the “Why Agile?” question it is as simple as “If you want to deliver business benefit inside 6 months then you are fixing time”.You probably want to fix cost and quality as well in any well managed organisation. This is the Agile approach; because you can’t fix all aspects of a project without massive contingency (effectively putting the costs / wastage up) you have to vary the features. Many studies have highlighted that most of the features in an IT system are not used so focus on just the ones the deliver most business benefit. <br />
  • Top two requirements management <br /> <br /> Bottom 3 about improving feedback cycles
  • Estimation Risk <br /> At the beginning estimates are just educated guesses <br /> Delivery every 2-6 weeks lets us know how accurate our guesses were <br /> Plans improve; expectations on delivery managed better <br /> Changing Req Risk <br /> The business environment does not stand still while the project is in progress <br /> Breaking down requirements into small pieces and prioritising them means that change can be easily accepted <br /> Delivery every 2-6 weeks allows users “IKIWISI”; spot what they’ve missed <br /> Delivery every 2-6 weeks means that the project can be stopped at any point and the value up to that point is not wasted <br /> Integration Risk <br /> There are always wrinkles in moving into “Business as Usual” <br /> Earlier we find these out the easier it is to manage expectations <br /> Testing Risk <br /> A big test phase at the end of a project will always be squeezed by deadlines <br /> Testing and acceptance every 2-6 weeks means problems are spotted early <br /> Testing small pieces of functionality at a time reduces complexity and increases focus <br /> Key Person Risk <br /> Good people want to be part of and stay in good agile projects. Why? <br /> Because they are valued; their opinions sought and listened to <br /> Because the project delivers regularly; seen to deliver value <br /> Because they interact with the real users of the solution <br /> Appropriate level of bureaucracy <br /> <br /> <br /> <br /> <br />
  • For those not familiar with Agile / these terms don’t worry about it too much
  • Stuff that the methodologies don’t really provide too much guidance <br />
  • Most widely adopted Agile method <br /> Simplest way to get started with Agile <br /> <br /> Scrum primary focus is on culture <br /> <br /> <br /> “The geeks will inherit the earth!!”
  • How many organizations are talking about these? But how are they actually going to do it
  • Underlying culture <br /> <br /> Retrospective Prime Directive <br />
  • Iterative <br /> <br /> Typically start with engineering…. <br /> ….Governance gets in the way & needs aligning <br /> … root cause - Cultural mis-alignment <br />

The future of project management - changing the change function The future of project management - changing the change function Presentation Transcript

  • The Future of Project Management Changing the change function
  • A Provocation…. You can deliver a fixed requirement project using Agile techniques You can’t deliver a variable requirement project using traditional techniques Therefore the future of project management is Agile
  • Changing requirements Business changes People’s understanding changes “I’ll know it when I see it” Ever increasing pace of change
  • Change Controls Requirements Time Cost Requirements Time CostFixed Variable Construction / Infrastructure Business Change / Software Agile provides tools, structure, culture and discipline to embrace change in requirements
  • Core Agile Practices Break requirements into small pieces Prioritise these requirements according to the business need Deliver “go-live-able” functionality every 2-6 weeks Collaborative team Combining business and technical resource Regular and frequent feedback within the team and from “business as usual”
  • Why Agile? • Requirements can and should change • “I’ll know it when I see it” IKIWISI • Better return on investment • Deliver business benefit quickly • Hit deadlines • Project can be seen to be delivering / on track • De-risks implementation Agile RoI Waterfall RoI
  • Reducing Generic Project Risk Changing requirements Estimation Testing / Acceptance Integration / Go-Live Key Person
  • So what’s getting in the way?
  • No single methodology is enough Scru m XPDSDM EngineeringGovernance / Mgt
  • Where do I start….? Collaboration Requirements into User Stories Defining and automating tests Deployment Scaling to Programmes and Portfolios Operating in a traditional environment Procurement and contracts
  • Scru m XPDSDM EngineeringGovernance / Mgt So…. what value does Scrum represent?
  • Scrum focuses on culture… Simplicity Collaboration Self-organising teams Breaking down hierarchy A single voice to represent end-users Minimising documentation A belief that traditional project management practices stifle creativity, delivery and good software engineering A desire that the opinions of software engineers are listened to …a little narrowly
  • Culture changes Eliminate false certainty Embrace transparency Collaboration Bring IT and Business together Appropriate delegation & empowerment Minimise bureaucracy Encourage team & organisational learning Personal mastery & discipline Agile is part of and supports the broader change needed for high performing organisations
  • Core Assumption “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”
  • Embedding Agile Culture
  • Where do I start….? Culture change Meta-methodology Collaboration Requirements into User Stories Defining and automating tests Deployment Scaling to Programmes and Portfolios The Future of Project Management
  • Questions and Answers
  • This presentation was delivered at an APM event To find out more about upcoming events please visit our website www.apm.org.uk/events