The future of project management - changing the change function
•Download as PPTX, PDF•
4 likes•2,738 views
The document discusses how the future of project management is agile due to changing requirements in projects. It provides three key points: 1) You can deliver fixed requirement projects using agile techniques but cannot deliver variable requirement projects using traditional techniques. 2) Agile provides tools, structure, culture and discipline to embrace changing requirements, which is increasingly important due to business changes and evolving understanding. 3) Core agile practices like breaking requirements into small pieces, prioritizing based on business need, and delivering working functionality frequently allow projects to better adapt to changing needs.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to The future of project management - changing the change function
Similar to The future of project management - changing the change function (20)
More from Association for Project Management
More from Association for Project Management (20)
Recently uploaded
Recently uploaded (20)
The future of project management - changing the change function
- 1. The Future of Project Management Changing the change function
- 3. 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
- 4. Changing requirements Business changes People’s understanding changes “I’ll know it when I see it” Ever increasing pace of change
- 5. 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
- 6. 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”
- 7. 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
- 8. Reducing Generic Project Risk Changing requirements Estimation Testing / Acceptance Integration / Go-Live Key Person
- 9. So what’s getting in the way?
- 10. No single methodology is enough Scru m XPDSDM EngineeringGovernance / Mgt
- 11. 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
- 12. Scru m XPDSDM EngineeringGovernance / Mgt So…. what value does Scrum represent?
- 13. 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
- 14. 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
- 15. 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”
- 17. 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
- 19. This presentation was delivered at an APM event To find out more about upcoming events please visit our website www.apm.org.uk/events
Editor's Notes
- 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. 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. 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 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.
- Top two requirements management Bottom 3 about improving feedback cycles
- Estimation Risk At the beginning estimates are just educated guesses Delivery every 2-6 weeks lets us know how accurate our guesses were Plans improve; expectations on delivery managed better Changing Req Risk The business environment does not stand still while the project is in progress Breaking down requirements into small pieces and prioritising them means that change can be easily accepted Delivery every 2-6 weeks allows users “IKIWISI”; spot what they’ve missed 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 Integration Risk There are always wrinkles in moving into “Business as Usual” Earlier we find these out the easier it is to manage expectations Testing Risk A big test phase at the end of a project will always be squeezed by deadlines Testing and acceptance every 2-6 weeks means problems are spotted early Testing small pieces of functionality at a time reduces complexity and increases focus Key Person Risk Good people want to be part of and stay in good agile projects. Why? Because they are valued; their opinions sought and listened to Because the project delivers regularly; seen to deliver value Because they interact with the real users of the solution Appropriate level of bureaucracy
- 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
- Most widely adopted Agile method Simplest way to get started with Agile Scrum primary focus is on culture “The geeks will inherit the earth!!”
- How many organizations are talking about these? But how are they actually going to do it
- Underlying culture Retrospective Prime Directive
- Iterative Typically start with engineering…. ….Governance gets in the way & needs aligning … root cause - Cultural mis-alignment