1 / 25

Project Management in the Brave New World of the Knowledge Revolution

Project Management in the Brave New World of the Knowledge Revolution. The future ain’t what it used to be. --Yogi Berra. What you will learn today. What does the new flexibility of building knowledge products mean for the evolution of project management?.

belden
Download Presentation

Project Management in the Brave New World of the Knowledge Revolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Project Management in the Brave New World of the Knowledge Revolution The future ain’t what it used to be. --Yogi Berra

  2. What you will learn today • What does the new flexibility of building knowledge products mean for the evolution of project management? • What strategies have emerged in conjunction with the knowledge revolution? • How can you begin using these concepts in your organization?

  3. Building physical products inthe industrial revolution focused on the constraints of replication and reconfiguration, but these constraints are not nearly as limiting when building knowledge products today.

  4. Industrial revolution focused on physical products • Replication (mass production) of physical products • Eli Whitney – • interchangeable parts • Henry Ford – • assembly line • Frederick Winslow Taylor – • optimized production, separated thinking from doing • Tyson Foods example today • Reconfiguration (change) of physical products • Physical product examples – fixing defects: • … in middle of a production run • … after product is in the distribution pipeline • … after products are sold to consumers

  5. Why the sequential waterfall method? • Standard • Sequential Waterfall • Constraints • Pressure

  6. In traditional project management, change is the exception, not the rule • Employs a big-design-up-front (BDUF) approach • Uses sequential phases • Freezes requirements early to prevent scope creep • Does nothing to lower the cost of changes that arrive after phase is completed • Prematurely estimates, budgets and commits to costs for the whole project as if they are accurate

  7. Evidence supports the opposite: Change is the rule, not the exception • Fallacy of frozen requirements • Change is a fact of life in project work…at any point in the project and for many reasons

  8. Luckily, in the knowledge revolution, embracing change is not as difficult • Knowledge products are easy to replicate. • Knowledge product reconfiguration is not inherently expensive. • Because embracing change became possible, the seed was planted, and ideas were tried. • Today, agile approaches have at their disposal a number of practices that support embracing change. • By designing the ability to make frequent changes as part of the process’s natural rhythm, change becomes less expensive and less disruptive to the project’s velocity.

  9. Pros and cons of embracing change • By using small iterations instead of BDUF. • By not being a slave to requirements freezes. • Final product can better reflect the customer’s needs when the product is delivered. • Change still has a cost, even if it is lower than before.

  10. How an agile approach like Scrum uses iterations to embrace change • Changes discovered during one iteration are added to the Product Backlog and may only be included in a future iteration, not the current one. • Think of each iteration as a complete mini-project, even if just two weeks long.

  11. Why agile? What does agile really mean? • A word about agile… • “Ready ability to move with quick easy grace” • Agile does not mean • Delivering faster • Fewer defects or higher quality • Higher productivity • Agile does mean agile, the ability to change • Faster than your competition • Faster than you ever could before • Perhaps getfaster delivery and higher quality, but • Raison d'être of agile is…it’s agility

  12. What does the new flexibility of building knowledge products mean for the evolution of project management? • Changes – the kind we expect and the kind we do not expect – are finally acknowledged. • Uncertainty – lack of information or unpredictability – is at least partially addressed. • The fundamentaldifferencebetween industrial projects and knowledge projects is recognized. • The command-and-control management style is replaced with a collaborative management style where • Team leaders view information as the catalyst for invention and adaptation • Team members are treated as competent contributors and are given decision responsibility in return for more accountability • These are profound changes for the teams and leaders and, ultimately, organizations.

  13. Organizational agility cannot be achieved by a project team in isolation • Agility, once adopted by a project team, will over time cause a ripple effect into all parts of the organization that the project team touches. • Just as general team support requires organizations to change, so does agile team support, only more. • This becomes a system challenge for organizational redesign making use of • Thinking tools (including systems thinking, lean, queueing theory, information theory, more) • Organizational tools and policy changes (possibly feature teams, real teams, large-scale Scrum, a new organizational model)

  14. That is, while there is value in the items on the right, we value the items on the left more. The Agile Manifesto: four values If you see a fork in the road, take it. -Yogi Berra

  15. Example: Scrum’s Five Values • Courage • Respect • Openness • Focus • Commitment

  16. The Twelve Agile Principles

  17. Agile management principles

  18. Declaration of interdependence for agile and adaptive management • Weincrease return on investment by making continuous flow of value our focus. • Wedeliver reliable results by engaging customers in frequent interactions and shared ownership. • Weexpect uncertainty and manage it through iterations, anticipation, and adaptation. • Weunleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. • Weboost performance through group accountability for results and shared responsibility for team effectiveness. • Weimprove effectiveness and reliability through situation-specific strategies, processes, and practices.

  19. Agile leadership practices • Use organic teams • Provide a guiding vision • Establish simple rules • Provide open information • Control with a light touch • Practice adaptive leadership

  20. Lean strategies • Lean has two well articulated pillars of management commitment: • Respect for People: to continuously invest in its people • Continuous Improvement: to promote a culture of continuous improvement. • Lean is a complete system & all parts must be working for success • Many attempts to duplicate have not been as successful • Lean is famous for its surprisingly broad definition of waste: anything that is NVA, not value added, that is, anything that does not directly increase immediate value to the customer, a long list. • Lean principles apply to production as we would expect, but also to development. These are the two main processes at Toyota. • Development – out-learn the competition • Production – out-improve the competition • Continuous improvement, mentoring, lateral information sharing, cadence, and retrospectives are lean concepts that have corresponding concepts in agile.

  21. Queueing theory strategies • Relevant key performance indicators (KPIs) • Throughput cycle times – baton not the runner • Work in progress (WIP) queues tend to be invisible in product development • Problem because they increase average cycle time • Better to eliminate a queue than to manage it • For queues that must be managed • Reduce batch size • Make each batch equally sized • Limit queue size • Provide visibility into queue if hidden

  22. Artful making strategies • Artful making is new product development where the product to be made is not pre-specified • Applies equally to software development, strategic planning, and producing a play • Emphasizes emergence of the product during design/build • Requires creativity, innovation, collaboration, and repeating iterations to get the desired outcome • Industrial making is building from a set of plans with the product fully pre-specified • Applies equally to manufacturing cars or building a house from plans • Emphasizes planning; design of the product previously done • Uses sequential phases and replication to get outcome

  23. Artful reconceiving vs. industrial replicating

  24. A sampling: • Iterations vs. phases • Embracing change vs. requirements freeze • Customer collaboration and provide open information vs. limited access • Self-organizing teams and use organic teams vs. command-and-control • Value-driven vs. compliance-driven • Making use of talent vs. rigidly defined roles • Test-driven development vs. test late development • Continuous improvement and practice adaptive leadership • Eliminate waste vs. waste-blind processes • Respect for people (lean, agile) vs. traditional approach • Casting vs. traditional staffing • Control with a light touch • Provide a guiding vision (commander’s intent) • Establish simple rules • Reduce cycle time • Eliminate queues • Learn to see into invisible queues • Limit queue size • Reduce batch size • Reduce variability in batch size • What strategies have emerged in conjunction with the knowledge revolution?

  25. I want you all to become systems thinkers. Gerry Weinberg is an excellent systems thinker. • The hardest errors to overcome have become buried in our assumptions underlying our de facto operational mental models. • Weinberg-Brooks Law: • More software projects have gone awry from management’s taking action • based on incorrect system models than for all other causes combined. • Causation Fallacy: • Every effect has a cause…and we can tell which is which. • The Japanese warn us against using false dichotomies. • In short, be a life-long detective for what is really going on so that you can make the best decisions possible. • How can you begin using these concepts in your organization? Thanks for coming out!

More Related