The future of project management - changing the change function


Published on

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.

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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
  • The future of project management - changing the change function

    1. 1. The Future of Project Management Changing the change function
    2. 2. 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
    3. 3. Changing requirements Business changes People’s understanding changes “I’ll know it when I see it” Ever increasing pace of change
    4. 4. 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
    5. 5. 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”
    6. 6. 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
    7. 7. Reducing Generic Project Risk Changing requirements Estimation Testing / Acceptance Integration / Go-Live Key Person
    8. 8. So what’s getting in the way?
    9. 9. No single methodology is enough Scru m XPDSDM EngineeringGovernance / Mgt
    10. 10. 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
    11. 11. Scru m XPDSDM EngineeringGovernance / Mgt So…. what value does Scrum represent?
    12. 12. 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
    13. 13. 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
    14. 14. 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”
    15. 15. Embedding Agile Culture
    16. 16. 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
    17. 17. Questions and Answers
    18. 18. This presentation was delivered at an APM event To find out more about upcoming events please visit our website