Technical Project Management in Living and Geometric Order

Third Edition

Jeffrey Russell, Wayne Pferdehirt, and John Nelson

Brian Price

University of Wisconsin-Madison

Madison, WI

Technical Project Management in Living and Geometric Order by Board of Regents of the University of Wisconsin System is licensed under a Creative Commons Attribution 4.0 International License, except where otherwise noted.

This book was produced with Pressbooks.

1

Dedication

Whatever may be the limitations which trammel inquiry elsewhere, we believe that the great state University of Wisconsin should ever encourage that continual and fearless sifting and winnowing by which alone the truth can be found.

—The “Wisconsin Magna Carta,” posted outside Bascom Hall at the University of Wisconsin-Madison

We dedicate this book to the citizens of Wisconsin for their vision of providing access to world-class education, and for their continued support of the University of Wisconsin-Madison; without them, this text would not exist. We also dedicate this book to our students who teach and challenge us—and then go forward to make the world a better place. Finally, with warm-hearted encouragement, we dedicate this book to the perplexed project manager who seeks to differentiate symptoms from issues in search of the true root cause.

Contents

- Dedication

- Acknowledgements

- About the Authors

- Foreword

- Introduction

- Please Share Your Thoughts on this Open Educational Resource

- 1. Project Management Foundations: Principles and Practices

- 1.1 Technical Project Management in the Modern World

- 1.2 Be a Hedgehog and a Fox

- 1.3 Two Types of Order: Living and Geometric

- 1.4 A Project’s Life Cycle and Living Order

- 1.5 Four Roles of a Project Manager

- 1.6 Lean: Eliminating Waste in Living Order

- 1.7 Agile: Fast Feedback in Living Order

- ~Practical Tips

- ~Summary

- ~Glossary

- ~Additional Resources

- ~References

- 2. Strategy, Project Selection, and Portfolio Management

- 2.1 Do the Right Thing

- 2.2 The Essence of Strategy

- 2.3 Operational Effectiveness is not Strategy

- 2.4 Lean and Strategy

- 2.5 Why is Executing a Strategy So Hard?

- 2.6 Aligning Projects with Strategy Through Portfolio Management

- 2.7 Knowing When to Say No

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 3. Project Initiation, Scope, and Structure

- 3.1 Initiation and the Project Life Cycle

- 3.2 The Work of Initiation

- 3.3 Defining Success

- 3.4 Creating the Project Charter

- 3.5 Managing Project Scope

- 3.6 From the Trenches: Michael Mucha on Sustainability and Adaptive Challenges

- 3.7 Project Context

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 4. Procurement

- 4.1 Procurement’s Role in Supply Chain Management

- 4.2 Procurement from the Enterprise to the Project

- 4.3 Maintaining Procurement Relationships

- 4.4 Reducing Procurement Waste

- 4.5 Value over Price

- 4.6 From RFP to Contract

- 4.7 Different Domains, Different Approaches to Procurement

- 4.8 Sustainable Procurement

- 4.9 Agile Procurement

- 4.10 Communication 101

- 4.11 Lean Procurement: Even the Best Sometimes Get It Wrong

- ~Practical Tips

- ~Glossary

- ~References

- 5. Team Formation, Team Management, and Project Leadership

- 5.1 Teams in a Changing World

- 5.2 Behaviors that Build Trust

- 5.3 Team Motivators and Demotivators

- 5.4 Managing Transitions

- 5.5 Self-Organizing Agile Teams

- 5.6 The Power of Diversity

- 5.7 Virtual Teams: A Special Challenge

- 5.8 Core Considerations of Leadership

- ~Practical Tips

- ~Summary

- ~Glossary

- References

- 6. Project Planning

- 6.1 A New Way to Think About Planning

- 6.2 The Geometric Order Approach: Push

- 6.3 The Living Order Approach: Pull Planning

- 6.4 Distinguishing Between Push and Pull

- 6.5 Pull and Agile

- 6.6 Sustainability: Planning for Continuous Improvement

- 6.7 A Word on Contingency Plans

- ~Practical Tips

- ~Summary

- ~Glossary

- Additional Resources

- References

- 7. Project Scheduling

- 7.1 Crossing the Bridge from Planning to Scheduling

- 7.2 Choosing Your Words

- 7.3 Geometric and Living: Two Ways to Schedule

- 7.4 Push: The Critical Path Method (CPM)

- 7.5 Pull: Post-Its, Last Planner, and Agile

- 7.6 The Critical Path in Living Order

- 7.7 Focus on Milestones

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 8. Managing Project Risks

- 8.1 Identifying Risks

- 8.2 Threats, Issues, and Risks

- 8.3 Risk Management and Project Success

- 8.4 Reporting on Risks

- 8.5 The Big Picture is Bigger than You Think

- 8.6 Contingency Planning and Probabilistic Risk Modeling

- 8.7 Ethics and Risk Management

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 9. Managing Project Value, Budgets, and Costs

- 9.1 Talking the Talk

- 9.2 Keeping an Eye on Scope

- 9.3 Understanding Budgets

- 9.4 Understanding Cost

- 9.5 Target-Value Design

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 10. Allocating and Managing Constrained Resources

- 10.1 Managing Resources in Living Order

- 10.2 Geometric Resource-Optimization Techniques

- 10.3 Estimating Resource Capacity in Agile

- 10.4 Resources and the Triple Bottom Line

- 10.5 From the Trenches: John Nelson on Resources at the Portfolio Level

- 10.6 Externalities and Looking to the Future

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 11. Project Monitoring, Analytics, and Control

- 11.1 Monitoring for Active Control

- 11.2 What to Monitor and When to Do It

- 11.3 Avoiding Information Overload

- 11.4 A Note About Dashboards

- 11.5 Informed Intuition

- 11.6 The Illusion of Linearity

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 12. Critical Project Management Skill: Negotiation

- 12.1 Negotiation 101

- 12.2 Focus on Interests Instead of Positions

- 12.3 Information-Based Bargaining

- 12.4 Embrace the Power of Emotion

- 12.5 When Worlds Collide

- 12.6 Ethics and Negotiation

- 12.7 Resolving Disputes

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 13. Project Closure and Audits

- 13.1 Getting the Fundamentals Right

- 13.2 Auditing: The Good, the Bad, the Ugly

- 13.3 Correcting Course or Shutting a Project Down

- 13.4 Closing Out a Project

- 13.5 From the Trenches: Brian Price

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- 14. Personal and Organizational Project Management Growth

- 14.1 Developing Yourself and Your Organization

- 14.2 The ABCs of Learning

- 14.3 Project Management Maturity

- 14.4 Knowledge Management and Organizational Learning

- 14.5 Sustainability: Thick or Thin?

- 14.6 Personal Project Management Maturity

- 14.7 Practical Tips for Organizational Development

- ~Summary

- ~Glossary

- ~References

- 15. Putting It All Together

- 15.1 Reassess and Plan for the Future

- 15.2 Technical Project Manager as Plumber and Poet

- 15.3 Event-Driven and Intention-Driven Project Management

- 15.4 Creating a Professional Development Plan

- 15.5 The Future of Technical Project Management

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- Appendix A - Risk and a Changing Climate

- A.1 The Need to Adapt

- A.2 Non-Stationarity and Living Order

- A.3 Managing Risk in Living Order

- A.4 Adaptive Management

- ~Glossary

- ~References

- Appendix B - Quality Management

- B.1 Quality in Project Management

- B.2 Quality Planning

- B.3 Managing Quality

- B.4 Quality Standards and Systems

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- Appendix C - Project Recovery

- C.1 Identifying a Troubled Project

- C.2 Understanding the Problem

- C.3 Assessing Options and Developing a Plan

- C.4 Finalizing the Recovery Plan

- C.5 Implementing the Plan

- C.6 Avoiding Problems on the Next Project

- ~Practical Tips

- ~Summary

- ~Glossary

- ~References

- Appendix D - Learning from Our Students

- What part of the Technical Project Management course was most helpful?

- What have you continued to learn more about since completing the class?

- Do you have any new insights related to what you learned in the class?

- Can you give one specific example of a situation in which something you learned in the class affected your project management skills on the job?

- Do you have any advice to offer new technical project managers based on your on-the-job experience?

- Glossary

2

Acknowledgements

First of all, we would like to pay tribute to Wayne Pferdehirt, our dear friend and colleague, who was the one of the driving forces behind this publication, and whose ideas and practical experience shaped every lesson. Since his unexpected passing in 2019, we have worked to carry on his legacy as a deeply admired teacher and engineer, a proponent of excellence in all undertakings and, above all else, a kind and compassionate man. He is deeply missed.

We also owe a debt to Alexander Laufer for introducing us to the concepts of living and geometric order in his book Mastering the Leadership Role in Project Management: Practices That Deliver Remarkable Results. His thoughts greatly shaped our work on this book, and we regularly turned to his writings for insights on technical project management. This book was also influenced by  Susan Ottmann, and David Pagenkopf, who shared project management wisdom drawn from many years of experience. A very special thank you to Brian Price and Robert Merrill, who reviewed many drafts and offered numerous contributions that greatly expanded the practical advice included in this book on several topics. We also owe a  warm-hearted thank you to Larry Roth, who generously shared his thoughts on risk and other essential topics  throughout the book generally, and in Appendix A specifically, where he shares his philosophy on risk management in the face of climate change. Many thanks to Gary Whited, whose contributions are drawn from his decades of engineering experience. Matthew Potter contributed his thoughts on the value of reliable promising, and Michael Mucha graciously discussed numerous project management topics in a wide-ranging interview.

The authors would also like to thank our students for making project management come alive with their participation and sharing of their experiences in fields ranging from capital projects to consumer products to software. Each application area has its own unique context, challenges, and opportunities, and allowed us to explore how theory and practice interact and complement one another.

Finally we acknowledge the exceptional work by Ann Shaffer in developing this text. Ann worked with Jeff, Wayne, John, and all the contributors and reviewers to develop, refine, review, and finalize each of the lessons in this text. Her fresh insights and big-picture perspectives, which extended far beyond engineering, contributed valuably to the breadth, language, and format of the finished text. We greatly appreciate the talent, passion, commitment, and collegial attitude that Ann brought to this project.

Jeffrey Russell

John Nelson

3

About the Authors

Jeffrey S. Russell is Vice Provost for Lifelong Learning, Dean of Continuing Studies, Professor of Civil and Environmental Engineering, and Executive Director of the Consortium for Project Management at the University of Wisconsin-Madison. In his role as vice provost and dean, he is responsible for leading the university’s programs and services for lifelong learners and nontraditional students. He has published widely in the areas of contractor failure, prequalification, surety bonds, constructability, automation, maintainability, warranties, and quality control/quality assurance. He has served as editor-in-chief of the Journal of Management in Engineering and served as founding editor-in-chief of Leadership and Management in Engineering. At the University of Wisconsin-Madison, he co-teaches the course “Technical Project Management” within the Engineering Management program.

John S. Nelson is the Chief Technical Officer for Global Infrastructure Asset Management LLC, an asset management firm specializing in sustainable infrastructure investments, and Chairman of MEP Associates LLC, a US Consulting Engineering Firm. He teaches at the University of Wisconsin-Madison as an Adjunct Professor of Civil and Environmental Engineering, in the Construction Engineering Management program. He co-teaches the course “Technical Project Management” within the Engineering Management program. Previously, John was CEO of Affiliated Engineers as the firm became nationally recognized for designing dynamic building systems and infrastructure for large and complicated projects. His technical background includes design and application of, and research on, dynamic energy and water systems. His management background includes company management and consulting for the investment, design, and construction industries.

Wayne P. Pferdehirt (1952-2019) was the director of the University of Wisconsin-Madison’s Master of Engineering Management and Master of Engineering Data Analytics programs. He taught the courses “Technical Project Management” and “Foundations of Engineering Leadership” within the Engineering Management program. Prior to joining UW-Madison, Wayne directed Midwest solid waste consulting services for an international environmental consulting firm, led energy conservation research projects for Argonne National Laboratory, and led water resources projects for the Army Corps of Engineers. He held a bachelor’s degree in engineering from Carnegie-Mellon University and a master’s degree in civil engineering with an emphasis in regional planning from Northwestern University. Wayne was a frequent speaker and author on continuing education for engineers and project management and was a member of the College of Engineering’s Education Innovation Committee.

Contributing Editor

Brian Price is an academic based at Aston University in the UK, teaching engineering and product design. Active research areas include ultra low carbon vehicles, charging/fueling networks and engine/transmission design. With over 25 years experience in industry, working worldwide on engine design consultancy, he brings a pragmatic approach to new product development. Previously chief engineer or technical director at a number of leading automotive companies, including Lotus Engineering, Cosworth Technology, Mercury Marine, Harley-Davidson and Ricardo Consulting. He presents regularly at international conferences and is a visiting professor at Loughborough University, UK, University of Wisconsin-Madison, USA and Hanyang University, South Korea.

4

Foreword

Brian Price

The Airbus A380 is the flagship airliner of the European EADs group, and the world’s largest commercial passenger airplane. It entered service in October 2007, two years late and $6 billion over its original $12 billion budget. In large part, the delays and cost overruns were caused by a failure of project management in coordinating engineering activities across 16 sites in four different countries. Unfortunately, this is an all-too-common story of major project performance.

A report by the Standish group estimates that 43% of projects fail, with 71% going significantly over budget or late. The cost to the U.S. economy alone is estimated at $55 billion each year. Is it therefore any surprise that in survey after survey of what employers are looking for in graduates, project management skills tops the list, with an ability to work effectively in teams? In a Forbes article describing the “The 10 Skills Employers Most Want in 2015 Graduates,” eight of the ten most desired skills are related to project management. The author states, “Employers also want new hires to have technical knowledge related to the job, but that’s not nearly as important as good teamwork, decision-making and communication skills, and the ability to plan and prioritize work.”[1]

It has been my pleasure and honor to have been taught by and to have worked with Jeff Russell, Wayne Pferdehirt, and John Nelson through the Engineering Professional Development faculty of the University of Wisconsin- Madison. Their deep knowledge of project management theory is tempered with the pragmatic expertise that they bring to the subject through their own professional engineering practice. You could not wish for better guides on the journey to improving your project management skills through study and practice.

It sometimes feels as though the world is awash with books on project management, all with similar things to say on the skills required and the techniques to use. The demand is there, but it would appear that the current provision of project management texts is wanting. It is therefore a welcome development that Jeff, Wayne, and John have written a guide that provides a philosophy for project management, as much as an academic text on the methods, techniques, and skills required to be a successful project manager.

By recognizing the dynamic nature of projects and applying the living order approach, this publication gives both the novice and expert project manager a fresh perspective on dealing with the complex challenges that emerge over the life of a project. This philosophy will help you plan effective projects, and will serve as a pilot through the choppy seas of real-world projects. Combining a thorough review of the latest methods in project planning and execution, the authors have created a complete guide to the skills required to be successful in your engineering projects.

Read this book. Study its contents. Practice its methods. You will not only be a more capable project manager, but a wiser one as well.

Brian Price
Lecturer in Engineering and Applied Science, Aston University
Adjunct Professor, Engineering Professional Development, University of Wisconsin-Madison

1. You can read the complete article here: http://www.forbes.com/sites/susanadams/2014/11/12/the-10-skills-employers-most-want-in-2015-graduates/#21b980e019f6.te content here. ↵

5

Introduction

This book is the result of a collaboration among the instructors responsible for Technical Project Management, one of the ten required classes in the Master of Engineering Management (MEM) program at the University of Wisconsin-Madison. The Master of Engineering Management is a world-class online program, consistently ranked in the Top 10 by U.S. News & World Report. Unlike many self-paced, online degree programs, the Engineering Management program provides a collaborative learning opportunity in which students work together to complete actual projects from their workplaces, discuss weekly topics, and participate in weekly web conferences. All of the students in the MEM program are experienced engineers, working full-time as they complete their graduate studies. The course and this text are targeted to the interests and needs of such mid-career professionals, who value practical principles and guidance.

The Technical Project Management class is designed to help students build on their past experiences and develop effective strategies for managing complex technical projects, with an emphasis on applying project management concepts to real-world problems. In the weekly web conferences, the class comes together in community to discuss the lesson topics, considering the practical applications of the concepts in each subject area.

Course Learning Objectives

The course learning objectives are the following:

- Acquire basic knowledge about projects and project management.

- Develop an understanding of knowledge, skills, tools, and practices used in project management.

- Apply project management knowledge, skills, tools, and practices in real-life situations.

- Explore how contemporary issues and examples connect to fundamental project management topics.

- Emphasize the critical role that culture plays in effective project management.

The main textbook for this class, Project Management: The Managerial Process, by Erik W. Larson and Clifford F. Gray, provides a wealth of details on project management theories, practices, and procedures. However, in our many years of teaching the class, we have seen students struggle to balance prescriptive theories about how projects should unfold, with the realities of how they actually do unfold in the modern world. For that reason, we wrote this book as a supplement that would explore the uncertain realities of technical project management in the ever-changing environment of today’s business world.

The fifteen lessons of this book are organized around the Technical Project Management course, while the appendices cover additional key topics. “Appendix A – Risk and a Changing Climate” provides detail on how our changing climate will increase risk and uncertainty in the performance of civil infrastructure in ways that are difficult to predict. With the third edition, we have included two additional appendices. In “Appendix B – Quality Management,” we explain the need to build in quality from the ground up, with a focus on the role of quality in the project management triangle and the importance of well-defined requirements in delivering quality on a project. In “Appendix C – Project Recovery,” we discuss the challenges involved in identifying and resolving problems on a project impacted by a multitude of variables, and we present tools and techniques for assessing options and developing a recovery plan.

In each lesson, we highlight the connections between the various stages and practices of technical project management. After all, in practice, a project manager must continually draw on a wide base of knowledge, connecting, for instance, effective negotiating techniques with best practices for scheduling and resource allocation. No phase of a project unfolds in complete isolation from other phases of the project. Everything is connected. Our goal in this book is to create doors and windows in the normally self-contained silos of activities involved in technical project management, drawing connections between planning and risk management, between risk management and ethics, between ethics and supply chain management, just to name a few of the many connections you will read about in this book.

We’ve chosen to publish this book as an open educational resource, making it available to anyone with an interest in technical project management. We were inspired to do this by the Wisconsin Idea, a philosophy embraced by the University of Wisconsin that encourages sharing new ideas and practical information far beyond the borders of the university itself. From its earliest days, the University of Wisconsin has been a pioneer in delivering course materials by any means necessary, starting with inexpensive pamphlets and correspondence courses, and expanding to include radio and television broadcasts, and now online courses of all kind. We hope this open educational resource will serve as another example of Wisconsin’s proud tradition of promoting learning throughout the wider community. You can contribute to this effort by emailing comments about ways to improve this book to the following address: jeffrey.russell@wisc.edu. We will respond to every comment, and whenever possible, revise the book to reflect our readers’ own personal experiences in the world of technical project management.

Throughout this book, we emphasize that project management is something you can really only learn by doing. It is not simply a matter of mastering a set of tools. In the real world, projects unfold in complex contexts. To succeed as a project manager, you need to be reflective and attentive, ready and able to learn about your project and adapt when necessary, from the earliest days of research and evaluation on through to project completion. In other words, you need to think of each project as a knowledge acquisition process. Successful project managers never cease in their efforts to gain experience in all aspects of project management.

We hope our students will find this book helpful as they continue their learning journey through the world of technical project management. We release this third edition in the midst of the COVID-induced disruption. While the magnitude and specifics of the current circumstances could not have been predicted, the reality of disruption was a primary motivation for writing this book. The real-time events we’re all in the midst of have reminded us that while preservation of geometric order can be appropriate, coincident, rapid adaptation to living order realties is unavoidable. Striking that balance provides opportunity and enervation for the thoughtful project leader. Much will be different—accelerated by COVID—but change is constant and disruption is inevitable.

6

Please Share Your Thoughts on this Open Educational Resource

You can contribute to this open educational resource by emailing suggestions for improvements to jeffrey.russell@wisc.edu. The authors will respond to every comment and, whenever possible, revise the book to reflect readers’ personal experiences in the world of technical project management.

1

Project Management Foundations: Principles and Practices

Nothing endures but change.
Heraclitus, 535 – 475 BC

Objectives

After reading this lesson, you will be able to

- Define terms related to project management

- Explain how culture can affect a project’s context and outcome

- Discuss two essential qualities of effective project managers

- Explain the difference between geometric and living order

- Define “project outcome,” “project success,” and “sustainability” in the context of a project’s full life cycle

- Identify four roles of a project manager

- Provide a basic introduction to Lean, including the six principles of Lean

- Explain fundamentals of Agile software development, including sprints and user stories

The Big Ideas in this Lesson

- Living order thinking recognizes that a system of things is always in the process of remaking itself, and that a system is always—at some level—in a state of uncertainty. In project management, this suggests that projects happen in dynamic environments, and that unexpected events should be considered part of the project’s life cycle. It is fundamentally adaptive.

- Project managers have traditionally idealized the more predictive geometric order, in which one stage necessarily leads to the next stage in a plan-driven project. This approach, sometimes referred to as waterfall development, is an essential component of project management, but when relied on exclusively, geometric order thinking can lead to inefficient and ineffective results.

- Lean thinking focuses on eliminating waste. In project management, Lean thinking provides a way to focus on the customer’s definition of value, which is the only definition that matters.

1.1 Technical Project Management in the Modern World

For a complete summary of the latest statistics on project management, see the Project Management Institute’s annual Pulse of the Profession report. You can read the 2020 version of the report here: PMI Pulse of the Profession 2020.

Projects are by definition ephemeral—they come and go, depending on an organization’s needs, and eventually come to a close. According to the Cambridge English Dictionary, a project is “a piece of planned work or activity that is completed over a period of time and intended to achieve a particular aim ” (2018). The fleeting nature of projects means that organizations with less than optimal project management proficiency often fail to develop systematic processes for managing them. Once a project is completed, everyone moves on, gearing up for the next, with barely a backward glance at what did and didn’t work in the old project. In other words, these organizations lack a coherent approach to project management—“the application of processes, methods, knowledge, skills, and experience to achieve the project objectives” (Association for Project Management n.d.). This lack of a systematic approach is especially problematic in technical fields, leading to an extremely high rate of failure for technical projects across many industries.

A quick web search on the success rate for technical projects offers some eye-opening facts and figures. Depending on which study you read, projects fail at rates between 20 and 80 percent. And throwing more money at the problem doesn’t help. Indeed, the higher a project’s budget, the more likely it is to fail (Mieritz 2012). One study found that IT projects with budgets over $15 million are project management fiascos: “On average, large IT projects run 45 percent over budget and 7 percent over time” (Bloch, Blumberg and Laartz 2012). The verdict is even more sobering for industrial megaprojects—that is for industrial projects costing over $1 billion. According to Edward W. Merrow, “The oil and gas production sector fares the worst; 78 percent of megaprojects in this industrial sector are classified as failures” (2011, 49).

The Value of Professional Project Management

How can organizations find their way out of this morass? By creating a culture of systematic, professional project management that values the skills discussed throughout this book. Research consistently shows that organizations that implement technical project management techniques and processes reap a rich reward in project successes. This book focuses on developing an approach to technical project management that is flexible, adaptable, and open to new learning. It provides many practical suggestions but does not go into specific methods in detail. For guidance on the nuts and bolts of project management see Project Management: The Managerial Process, by Erik W. Larson and Clifford Gray.

The Impact of Culture

Every project unfolds in unique and changing contexts impacted by internal and external forces. One such force, culture, can have a profound effect on a project’s context and its outcome. You are likely familiar with the concept of culture, which is the set of norms, beliefs, and customs of a particular society, group, place, or time. Culture functions on many levels in human society—in geographical regions, ethnic groups, religions, families, organizations, and even projects.

Projects that use the same tools, contracts, and structures may have starkly different outcomes depending on the culture of the organization and the project team. Organizational culture comprises the set of behaviors, values, artifacts, reward systems, and rituals that make up an organization. The culture of an organization may manifest itself in an expected set of behaviors (e.g., how do people work with customers and each other, how early or late do people work), the structure of the organization’s reward system (e.g., are employees rewarded for cost-cutting, customer satisfaction, innovation, or other factors), its approach to risk, and its overall mission and strategy (Bersin 2015). Project culture, or the set of beliefs, attitudes, and behaviors that exist independently of the individuals working on the project, can be a powerful force, with the result that people joining a project often adapt to the existing culture rather than changing it. At every level, culture is driven by leadership (2015).

The notion of a cultural iceberg serves as a reminder that many aspects of culture are not apparent to outsiders. In an organization or project team, the surface culture—made up of articulated norms, acceptable practices, and strategies—often represents a small fraction of the overall culture. Many more aspects of culture lie beneath the surface, often exerting a much stronger influence on how team members work together. These deep culture elements include communication styles and rules, notions of leadership, concepts of self and time, attitudes toward authority and collaboration, and approaches to decision-making and problem-solving, among others.

Cues to deep elements of organizational and project culture can often be found in unexpected places. Procurement practices, for instance, divulge a lot about culture. If the approach to procurement is price driven, it’s likely that the organizational and project culture is transactional, and possibly adversarial. If, on the other hand, procurement is value driven, the culture is more likely to be relational.

Project leaders should reflect on all facets of organizational and project culture, including the ways in which surface elements are not in alignment with substantive elements of the deep culture. Vera Martinovich, an engineering manager at Boeing, also emphasizes the importance of recognizing when culture—either at the project or organization level—is becoming an obstacle to successfully delivering a quality project outcome. According to Martinovich, that might mean helping the project team successfully work within the existing organizational culture rather than fighting it (pers. comm., June 20, 2020).

Additional challenges related to culture can arise on project teams comprising people from multiple organizations—a common occurrence in many industries. Examples of such teams include a product development team that utilizes supplier designs, a construction project team that includes independent designers and contractors, and a software project team working with an outside consultant to implement purchased products. With such teams, no common organizational culture is guaranteed. In these cases, the project leader has the opportunity to set the tone for the unique project culture, which should align with that of the ultimate customer.

No matter the makeup of the team or the impact of outside forces, the role of the project leader is to build a project culture that encourages team members and other stakeholders to work toward a shared goal. Accomplishing that requires the project leader to recognize their own influence, including ways in which they may be negatively impacting the project culture. For instance, a project leader who passively befriends everyone at the expense of making hard decisions and holding the team accountable may prove to be a team’s biggest obstacle. Likewise, autocratic project managers who act on behalf of the team without soliciting input or those that deliberately withhold information as a source of power can corrupt the project culture and dramatically lower the probability of successful outcomes.

A culture of trust and flexibility on a project team can mean the difference between success and failure. By fostering a collaborative culture, the project leader strengthens the team’s ability to deliver quality and to fix problems when they occur.

Mastering, influencing, and changing a project’s culture takes time and patience. While you are discerning the culture you are working in, be open-minded—listen, adapt, and be patient. Gauge carefully when deciding what aspects of the culture you try to shape. Start with an awareness of a project’s culture, assimilating and adjusting your way of doing things when you can.

1.2 Be a Hedgehog and a Fox

Living Order, Some History

Although the French Philosopher Henri Bergson was the first thinker to use the term “living order,” the idea that life is a continual process of unpredictable change has ancient roots. The fragments that remain of the work of the pre-Socratic Greek philosopher, Heraclitus, provide profound insights into this idea. He famously reduced the ever-changing nature of the universe to this simple saying: “No man ever steps in the same river twice.” According to Heraclitus, nature is in a constant state of change. Indeed, change is the only constant a human can rely on. Religious thinkers have long recognized that change in our lives is inevitable and unavoidable. For instance, the idea of impermanence is a key component of Buddhism. The Bible, in Ecclesiastes 9:11 points out the futility of striving against the inevitable:

Again I saw that under the sun the race is not to the swift, nor the battle to the strong, nor bread to the wise, nor riches to the intelligent, nor favor to those with knowledge, but time and chance overtake them all.

As the scientific revolution took hold in Western thought, this understanding of living order went underground, only to reemerge in the work of early twentieth-century thinkers and artists like Bergson, in reaction to World War I and widespread industrialism.

In his book Mastering the Leadership Role in Project  Management: Practices that Deliver Remarkable Results, Alexander Laufer explains two essential qualities of a project manager, drawing on the hedgehog and the fox metaphor made famous by the philosopher Isaiah Berlin:

The fox is a cunning and creative creature, able to devise a myriad of complex strategies for sneak attacks upon the hedgehog. The hedgehog is a painfully slow creature with a very simple daily agenda: searching for food and maintaining his home. Every day the fox waits for the hedgehog while planning to attack him. When the hedgehog senses the danger, he reacts in the same simple, but powerful, way every day: he rolls up into a perfect little ball with a sphere of sharp spikes pointing outward in all directions. Then the fox retreats while starting to plan his new line of attack for the next day. (Laufer 2012, 220)

The advantage of the fox is that his complex understanding of the world allows him to try out many possibilities, adapting strategies and tactics in response to the current situation. Hedgehogs have one grand strategy that allows them to simplify all experience into “a single overall concept that unifies and guides everything they do.” As you will see in Lesson 2, where we discuss organizational strategy, the hedgehog approach is preferable when it comes to making long-term decisions about an organization’s future. But when it comes to project management, both strategies are powerful, and both can be effective, depending on your situation. Laufer argues that successful managers “behave both like hedgehogs and foxes, though they place the hedgehog in the driver’s seat.”

Throughout this course, we will take a foxlike approach to technical project management by keeping an open mind and exploring the many lines of attack available in a particular project. But we will also place a hedgehog-like emphasis on a few basic principles—in particular the basic principles of Lean project management. At the same time, all our discussions will be informed by the distinction between the two fundamental approaches to project management: the traditional, predictive geometric-order approach, and the more adaptable, living-order approach.

1.3 Two Types of Order: Living and Geometric

In his 1907 book Creative Evolution, the French philosopher Henri Bergson investigated the nature of human creativity and its relation to order. According to Bergson, by “order” we generally mean a mechanistic, predetermined, linear relationship between things. Event A leads to Event B; Event B leads to Event C; Event C leads to Event D; and so on, with no possibility of variation or adaptation. We also tend to consider creativity as something that arises only in a state of disorder—that is, when no type of order is evident. The free-thinking artist is a stereotype founded in this way of thinking. But Bergson argued that the disorder we associate with creativity is really just a different type of order (222-224).

Again, we turn to Alexander Laufer, who has drawn some powerful insights on project management from Bergson’s work, which he summarizes as follows:

Bergson claimed that there is no such thing as disorder, but rather two sorts of order: geometric and living order. While in ”geometric order” Bergson related to the traditional concept of order, in ”living order” he referred to phenomena such as the creativity of an individual, a work of art, or the mess in my office. (2012, 214)

Throughout this book we will examine and compare geometric order to living order, with a goal of developing a creative, realistic, functional approach to project management.

Qualities of Living and Geometric Order

In project management, geometric order aligns with traditional managerial thinking. This concept of order is associated with predictable relationships between the stages of development, such as the relationships shown in Figure 1-1, with one stage necessarily leading to the next.

Figure 1-1: Geometric order is predictable, with one stage leading to the next

Project managers have traditionally idealized such an orderly project progression. Indeed, it is the driving force behind the predictive, process-oriented approach to project management that organizations such as the Project Management Institute have tended to focus on. It is an essential component of project management, and inexperienced project managers should start by mastering a geometric approach to their work. However, when relied on exclusively, geometric order thinking can lead to inefficient and ineffective results.

By contrast, living order thinking recognizes that a system of things is always in the process of remaking itself, and that a system is always—at some level—in a state of uncertainty. In project management, this suggests that projects happen in dynamic environments, and that unexpected events should be considered part of a complex project’s life cycle. This is something that experienced project managers learn over time. But even inexperienced project managers can try to incorporate an understanding of living order into their work.

Figure 1-2 illustrates the characteristics of living and geometric order. Keep in mind that a project can have qualities of both.

Figure 1-2: Characteristics of living order and geometric order

You might be called on to use geometric order methods in one situation and living order methods in another. For example, preparing a weather forecast on a typical day in San Diego, where the weather varies little from day to day, is a geometric order task. By contrast, preparing a weather forecast for the coast of Florida with a hurricane expected to hit shore five days in the future is a living order project. Often the planning stage occurs in living order. Then, as you begin to learn more about the project and what to expect, execution proceeds in geometric order. But when something unexpected happens, you could suddenly be plunged back into living order. You have to be prepared to move back and forth among geometric and living order techniques, adapting to the situation as necessary.

Traditional project management processes were founded on the presumption that a project can be planned down to the smallest detail, and that after the planning phase is complete, the project manager’s job is to execute the project according to that plan, without surprises. The reality of the modern world is quite different. In his 1991 book, Managing as a Performing Art: New Ideas for a World of Chaotic Change Permanent, Peter Vaill argued that today’s organizations actually operate in a state of “permanent white water.” Alexander Laufer describes Vaill’s argument as follows:

In using the “permanent white water” metaphor, Vaill calls our attention to the fact that the external environment of contemporary projects is full of surprises, tends to produce novel problems, and is “messy” and ill-structured. (2012, 214)

Throughout this book, we will focus on ways to manage technical projects in a permanent white-water world.

Predicting the Unpredictable

Geometric Order, Some History

Geometric order is a product of the Scientific Revolution. Beginning in the mid-1500s, humans harnessed the power of systematic thought to achieve giant leaps forward in mathematics, physics, biology, and many other areas of study. Thinkers from numerous countries contributed to the advances that made modern science possible, but perhaps the most important was Isaac Newton, who modeled a universe predicated on systematic, unchanging laws whose effects could be accurately predicted by mathematical equations.

The major human achievements of the last five centuries could not have occurred without this type of systematic thought. Modern life as we know it would not exist without it. However, as project managers, whose major concern is planning projects that take place over time, we need to understand the limits of our ability to predict the future in an ever-changing world.

Anything that involves human beings doing anything over a period of time, with limited resources, involves a certain amount of unpredictability. This means that projects are inevitably shaped by living order. You might think that you have a good handle on what to expect from your co-workers and project stakeholders throughout the course of a project, but often the traits you might consider the most predictable turn out to be completely unreliable.

Not long ago, this realization shook up the field of economics, which was founded on the assumption that humans were totally predictable in their tendency to make choices that enhance their financial well-being. In his groundbreaking work in the field of behavioral economics, Richard H. Thaler demonstrated that the supposedly irrefutable idea that people act rationally in their own self-interest is debatable at best, and probably untrue (Knee 2015). And yet many economists consistently refuse to take the unreliability of their basic precept into account. According to Thaler, “Economists discount any factors that would not influence the thinking of a rational person. These things are supposedly irrelevant. But unfortunately for the theory, many supposedly irrelevant factors do matter” (2015).

Thaler goes onto argue that “unless you are Spock,” supposedly irrelevant things, such as how you feel about saving for retirement, can have far more profound effects on your economic behavior than mere self-interest (2015). Successful project managers succeed, in part, because they never ignore the power of supposedly irrelevant things to affect project outcomes. Since we can safely assume that the vast majority of your future teammates will not be Vulcans, you should probably also assume that supposedly irrelevant things will end up having unforeseen effects on the projects you manage. You never know what living order will throw your way as a project unfolds.

That’s not to say that, as a project manager, you can dispense with the expectations of geometric order. Quite the contrary. Because this is a book on technical project management, our thinking will necessarily be concerned with geometric order. After all, technical projects involve technical products and services whose performance is governed by predictable laws. Gravity always works the same way, so engineers have to take that into account. The latest computer processors can only work so fast in today’s environment, and so software developers have to take that into account, too.

However, you need to guard against the tendency to think that because technical products and services are themselves predictable, the projects required to produce them will be equally predictable. That is simply not the case. Because this is a book on management, an endeavor that involves people performing tasks over time, our thinking will be deeply rooted in living order.

1.4 A Project’s Life Cycle and Living Order

When you open your eyes to the ever-changing nature of living order, you can begin to appreciate the potential for change inherent throughout a project’s life cycle. The same is true for the result of a project—whether that’s a building, a new smartphone, or software for farm machinery. The product, or result, of a project is created, maintained, adapted, updated, and demolished/retired by various projects during its life. Each of these projects is subject to living-order uncertainty, magnifying the difficulty of predicting what the result of a project will look like in the future, and whether it will indeed turn out to be suitable for its intended purpose. This, in turn, complicates the planning phase for any project, particularly for things that are ultimately judged by how easily it can be dismantled and disposed of, or recycled and reused.

For example, Figure 1-3 shows the life cycle of a building. The first stage, the making stage, is the domain of the project manager who oversees the building’s construction. Once the building is complete, the project manager moves on to other work, but the building of course has just begun its functional life. During the operating/using/changing stages, the building’s occupants either benefit or suffer from the project manager’s decisions throughout the making stage. Next comes the retirement/reuse stage, in which the building will likely be demolished and something else built in its place. At that point, the entire life cycle starts again. The ease with which these stages unfold depend, at least in part, on choices made by the project manager during the making stage. Only by understanding these later stages can you properly understand the true nature of a project and make decisions that will ensure it produces something of enduring value.

Figure 1-3: The product, or result, of a project is created, maintained, adapted, updated, and demolished/retired by various projects during its life

In software development, the time periods between stages are shorter than in construction. As in construction, the operating stage is by far the costliest part of the life cycle process. However, when a software product continues to be used beyond its designed operational life, the operating costs can rise at accelerating rates. In any industry, thinking about the life cycle of the result of a project changes how you think about project metrics. As shown in Figure 1-4 , what seems like a good choice from within the limited confines of the making stage might seem foolish when viewed from the broader perspective of the full life cycle.

Figure 1-4: Each life cycle stage raises new questions about the success of the initial, making-stage project

Project Outcome and Project Success

In its narrowest sense, the term project outcome refers to a project’s measurable output in terms of scope, cost, schedule, quality, and other issues such as safety. In a broader sense, the term also refers to the impact a project has compared to its larger goals. In this sense, we take the community perspective, taking into account, for instance, a project’s multiple use potential and eventual redevelopment. For example, in the narrowest sense, the desired project outcome of a proposed sports arena might be a multi-use indoor facility built according to the planned scope, cost, schedule, and so on. However, in the broader sense, the desired project outcome might be redevelopment and revitalization of the surrounding area.

For a humorous look at the many ways that project stakeholders can define project success, see “What the Client Wanted” – Arek Fressadi

The term project success refers to the degree to which a project is done well, with stakeholders having varying definitions of success over time, depending on their perspectives. In other words, the evaluation of a project’s success is a subjective judgment; different stakeholders will have different initial ideas about a project’s overall success based on their own expectations and objectives. To make things more complicated, over time, stakeholders will likely revise their ideas on the project’s success to take into account new information about how the project outcome actually functions in the real world. The changing definition of project success is especially important to keep in mind throughout disruptive projects such as home remodels and road reconstructions. For example, commuters might have an extremely low opinion of an interchange construction when they are suffering through the frustrations of traffic backups and detours. Later, when the interchange is complete, and traffic is flowing more quickly than ever before, they are likely to rate the project’s overall success very high. In the consumer products world, customers looking for a new wireless device might base their idea of project success on ease of use and reliability, whereas the company producing the device might rate project success based on number of units sold. Meanwhile, the industry as a whole might only rate the project a success if it sets a new technical standard.

If you limit your perspective to the making stage, it’s easy to think that the terms “project outcome” and “project success” are synonymous. For example, suppose you’re hired to build an energy efficient house according to Leadership in Energy & Environmental Design (LEED) standards. If, at the end of the making stage, you see that your team completed the structure on time and on budget, with all the specified LEED features, then you would probably consider that outcome a success. But as the house enters the Operating/Using/Changing stage, information about the home’s energy use might change your ideas about the success or failure of the project. If in fact the LEED features do not function as expected, then you would probably rate the project’s overall success rather low. Perhaps more importantly, the home’s owner would be unlikely to consider the home a success. And depending on the longevity estimates and ever-changing external factors, the lifespan of the house might also be significantly different than originally projected.

Put simply, project success is defined by doing the project well and meeting defined objectives. Project outcome also encompasses whether you and your team did the right thing. It’s important to consider both at multiple levels—for individual tasks, for the overall project, and for the impact of the project over its life. In every case, we need to think broadly about the factors contributing to a project’s success or failure. We risk losing enduring value if we draw too tight a fence around the boundaries we consider when planning and assessing project success.

Sustainability and Living Order

The ideal project manager has empathy for the people who will be using and modifying the completed project in the future, even the people who will ultimately demolish or recycle it. Ideally, this means incorporating materials that can ultimately be recycled. Indeed, in the European Union, automobile manufacturers are required by law to reduce the non-recyclable waste generated by an end-of-life vehicle (ELV) to 5%. This way of thinking necessitates a more complicated view of a product’s life cycle, as shown in Figure 1-5 (Kanari, Pineau and Shallari 2003).

Figure 1-5: Product life cycle can ultimately include recycling portions of the product (Source: “End-of-Life Vehicle Recycling in the European Union,” N. Kanari, J.-L. Pineau, and S. Shallari, The Member Journal of the Minerals, Metals & Materials Society http://www.tms.org/pubs/journals/jom/0308/kanari-0308.html. Copyright 2003 by The Minerals, Metals & Materials Society. Used with permission.)

Sustainability efforts inspired by a recognition of the realities of living order are well underway in the construction industry. As Lance Hosey, a Washington architect, has argued, sustainable construction means, among other things, creating buildings that can be easily disassembled, minimizing the disruption and contamination inherent in the demolition process (2005). Software developers, too, can develop sustainable software by, for example, writing code that runs even on outdated hardware, thereby minimizing the amount of computer equipment that ends up in landfills (Green Wiki 2015).

In addition to being sustainably designed, software also has the potential to promote other sustainability efforts, as discussed in the report Software Accelerates Sustainable Development, published by the nonprofit organization Business for Social Responsibility (2008). David Pagenkopf, director of Application Development and Integration at UW-Madison, has this to say about sustainability and software design:

The use of virtualization techniques has largely eliminated hardware as a material factor in software design. The most important issue in software sustainability is selecting the software languages, tools, and design architecture that ensure that software is maintainable for as many years as possible. One of the best examples is writing software that works entirely in a web browser, which can then work across multiple platforms. Even better is writing software using responsive design that automatically adjusts to the user’s end device (e.g. mobile phone, tablet, or laptop/desktop) to present the best possible interface to the user. (pers. comm., August 25, 2015)

Consumer products are subject to an ever-increasing array of sustainability expectations. As Bryan Burrough wrote in the New York Times, Wal-Mart reduced “packaging size across its producing lines, saving the company an estimated $3.4 billion a year…while reducing trash“ (Burrough 2011). Over a decade of effort has resulted in sustainability initiatives that “are having a real impact today. The company has strategically used its scale to its advantage to enact change within as well as outside the organization” (Atamian 2017).

1.5 Four Roles of a Project Manager

So what does all this talk about change and unpredictability mean, practically speaking, for a real-life project manager? Throughout this book, we will be investigating ways to accommodate the realities of living order in the daily tasks associated with technical project management. For example, in Lesson 6, we’ll talk about pull planning, an adaptive, recursive form of planning that prioritizes regular updating to reflect current conditions. But for now, let’s talk about some general principles for successful project management in a living order world.

In an article for MIT Sloan Management Review, Alexander Laufer, Edward Hoffman, Jeffrey Russell, and Scott Cameron show how successful project managers combine traditional management methods with newer, more flexible approaches to achieve better outcomes (2015). Their research shows that successful project managers adopt these four vital roles:

1. Develop collaboration among project participants: “Most projects are characterized by an inherent incompatibility: the various parties to the project are loosely coupled, whereas the tasks themselves are tightly coupled. When unexpected events affect one task, many other interdependent tasks are quickly affected. Yet the direct responsibility for these tasks is distributed among various loosely coupled parties, who are unable to coordinate their actions and provide a timely response. Project success, therefore, requires both interdependence and trust among the various parties” (Laufer et al. 2015, 46).

2. Integrate planning with learning: “Project managers faced with unexpected events employ a ‘rolling wave’ approach to planning. Recognizing that firm commitments cannot be made on the basis of volatile information, they develop plans in waves as the project unfolds and information becomes more reliable. With their teams, they develop detailed short-term plans with firm commitments while also preparing tentative long-term plans with fewer details” (Laufer et al. 2015, 46).

3. Prevent major disruptions: Successful project managers “never stop expecting surprises, even though they may effect major remedial changes only a few times during a project. They’re constantly anticipating disruptions and maintaining the flexibility to respond proactively…. When change is unavoidable, a successful project manager acts as early as possible, since it is easier to tackle a threat before it reaches a full-blown state” (Laufer et al. 2015, 47).

4. Maintain forward momentum: “When unexpected events affect one task, many other interdependent tasks may also be quickly impacted. Thus, solving problems as soon as they emerge is vital for maintaining work progress” (Laufer et al. 2015, 48).

Adopting these four roles will set you on the road toward delivering more value in your projects, with less waste, which is also the goal of both Lean project management and Agile project management.

1.6 Lean: Eliminating Waste in Living Order

Predictive, geometric order project management is often inefficient, leading to wasted time, money, resources, and labor. By contrast, Lean is a business model and project management philosophy that offers a means to streamline projects while allowing for the flexibility required to deal with unexpected events. Based on ideas and practices developed at Toyota after World War II, it emphasizes creating value for the customer while eliminating waste through the efficient flow of work from one phase of a project to another.

More than anything, Lean is a way of thinking. In their essential book on the topic, James P. Womack and Daniel T. Jones describe Lean thinking as follows:

It provides a way to specify value, line up value-creating actions in the best sequence, conduct these activities without interruption whenever someone requests them, and perform them more and more effectively. In short, Lean thinking is Lean because it provides a way to do more and more with less and less—less human effort, less equipment, less time, and less space—while coming closer and closer to providing customers with exactly what they want. (2003, 15)

We’ll be discussing Lean extensively throughout this book. To get started here, we’ll focus on two fundamental Lean ideas: value and waste.

Value

In ordinary conversation, “value” is a generic term that refers to the overall worth or usefulness of something. But in Lean, value is only meaningful “when expressed in terms of a specific product (a good or a service, and often both at once) which meets the customer’s needs at a specific price at a specific time” (Womack and Jones, 16). In other words, value is defined by the customer, not by the manufacturer, the contractor, or the service provider—and definitely not by the engineer responsible for designing the product.

Integrated Project Delivery

In reading about project management and Lean, you might come across the term integrated project delivery (IPD). Inspired by Lean thinking, IPD is a means of contractually aligning stakeholders in a construction project in a way that emphasizes close collaboration, with the goal of delivering value as defined by the customer. One feature of IPD is a type of contract known as a multi-party agreement, which explains each participant’s role in the project.

A related methodology, integrated product delivery, was developed as a reaction against the silo-ed approach to product development, in which the design team designed a product, and then “threw it over the wall” to the manufacturing team, which had to figure how to build the product with no input into its design. Integrated product development’s more collaborative approach improves time-to-market, while fostering innovation.

This sounds simple, but it can be a difficult concept for engineers, with all their technical expertise, to embrace. In their book, Womack and Jones include a chapter on Porsche, which suffered a sales collapse in the mid 1980’s largely because its world-class engineers had blinded themselves to their customers’ definition of value:

Designs with more complexity produced with ever more complex machinery were asserted to be just what the customer wanted and just what the production process needed…. It often became apparent that the strong technical functions and highly trained technical experts leading German firms obtained their sense of worth—their conviction that they were doing a first-rate job—by pushing ahead with refinements and complexities that were of little interest to anyone but the experts themselves…. Doubts about proposed products were often countered with claims that “the customer will want it once we explain it,” while recent product failures were often explained away as instances where “the customers weren’t sophisticated enough to grasp the merits of the product.” (2003, 17)

This is only one example of the kinds of preconceptions that can distort a company’s understanding of the value it is supposedly producing for the benefit of the customer. Womack and Jones provide in-depth case studies detailing the forces that can prevent a company from understanding what its customers actually want:

The definition of value is skewed everywhere by the power of preexisting organizations, technologies, and undepreciated assets, along with outdated thinking about economies of scale. Managers around the world tend to say, “This product is what we know how to produce using assets we’ve already bought, so if customers don’t respond we’ll adjust the price or add bells and whistles.” What they should be doing instead is fundamentally rethinking value from the perspective of the customer. (2003, 17-18)

To make the leap into Lean thinking, you need to fully grasp the nature of value, which is why we will return to this idea throughout this book. You also need to understand its opposite—waste. The whole goal of Lean is to maximize value and eliminate waste.

Waste

According to the Lean Lexicon, waste[1] is “Any activity that consumes resources but creates no value for the customer” (Lean Enterprise Institute 2014). Identifying waste can be as difficult for new Lean thinkers as identifying value.

Taiichi Ohno, the Toyota executive who pioneered the focus on waste and value that we now call Lean, identified seven forms of waste. You can find countless explanations of the seven wastes in books and articles. The following is adapted from “7 Wastes”- Lean Manufacturing Tools:

- Transportation: Moving people, machinery, or materials farther than is really necessary. A huge amount of transportation waste is necessitated by poor factory layouts, large batch sizes, and distant storage locations, just to name a few causes.

- Inventory: A build-up of stock due to, for example, poor planning, or the time required to change over machinery from one process to another.

- Motion: Any movement of humans or equipment that does not increase the value of a product or service. Examples include bending and reaching necessitated by a poorly designed work station, or by badly organized storage areas.

- Waiting: Humans or machines standing idle. Can be caused by long changeovers, poorly coordinated processes, or the need to rework flawed parts, among other things.

- Overproduction: Creating more than can be used or sold in a reasonable time. This is considered the worst form of waste, because “it obscures all of the other problems within your processes”(Lean Manufacturing Tools n.d.). Later in this book, we’ll talk about how to avoid this form of waste through Lean techniques such as pull planning.

- Over-processing: Doing more than is useful or necessary from the point of view of the customer. The over-engineering at Porsche, described by Womack and Jones, is a clear example of over-processing. A more mundane example might be a restaurant that uses expensive imported cheese on pizzas, when customers would actually prefer domestic mozzarella.

- Defects: Time and effort required to correct defective parts or poorly rendered services. This is what most people think of when asked to identify waste. But it can be hard to accurately gauge the costs associated with defects, which can include “costs associated with problem solving, materials, rework, rescheduling materials, setups, transport, paperwork, increased lead times, delivery failures, and potentially lost customers”(Lean Manufacturing Tools).

Another way to think about waste is to focus on how easily it can be eliminated. When looked at that way, it falls into two types:

- Type one waste: Creates “no value but is unavoidable with current technologies and production assets” (Lean Enterprise Institute 2014). This kind of waste is necessary but might be eliminated in the future. An example of type one waste might be routine inspections required to ensure that a particular part meets government safety standards. While necessary, such inspections don’t actually provide value from the customer’s point of view, and might conceivably be eliminated if the part itself was eliminated from the device, or if it was redesigned.

- Type two waste: Creates no value and can be eliminated immediately. For example, the time and effort required to transport a newly made microwave oven to the packaging machine is waste that could be eliminated by moving the packaging machine.

This blog provides some real-life examples of the seven forms of waste in a variety of industries: “Real Examples of the 7 Wastes of Lean” – KaiNexus

In project management, an example of type one waste might be an audit necessary to measure the performance of contracted work or a promised product against an agreed-upon set of requirements. From the customer’s perspective, such an audit adds no value, but it is necessary to ensure the successful completion of the project. A type two waste often seen in project management is constant requests for status updates. New project managers who haven’t yet built trust with their team sometimes succumb to this form of waste as they try to micro-manage all tasks. Regularly scheduled updates and escalation expectations for unexpected challenges helps to eliminate this type two waste in project management.

Six Lean Principles

The six principles at the heart of Lean thinking are: specify value, identify the value stream, flow, pull, perfection, and respect for people. You’ll learn more about these ideas, and how they relate to technical project management, throughout this book. We’ll explain them briefly here, to give you a foundation to work from. Most of the examples in this lesson are drawn from manufacturing, where Lean got its start. But keep in mind that Lean thinking has been widely adopted in industries as diverse as construction and healthcare.

1. Identify value: As explained earlier, value can only be defined by the customer. As a project manager, you have to start by learning what that definition is—ideally by talking directly to the customer. However, you may find that customers “only know how to ask for some variant of what they are already getting”(Womack and Jones 2003, 31). This means that identifying value often entails asking probing questions designed to elicit a definition of value from customers who may not have had the opportunity to think it through themselves. Often, the best questions to start with are: What problem do you want to solve? What does success look like?

2. Map the value stream: The value stream is “all of the actions, both value-creating and nonvalue-creating, required to bring a product from concept” to delivery(Lean Enterprise Institute 2014). In any industry, the vast majority of activities in the value stream create no value and are therefore waste. Firms that attempt to analyze the value stream for a particular product typically have to look far beyond their own premises, taking into account everything involved in bringing a product to market. For example, the value stream for a new type of bread might begin with groundwater used to irrigate wheat farms in Nebraska. When looking at value streams from a project management perspective, the goal is to understand all aspects of the project, including initiation, planning, executing, monitoring & control, and closeout.

Batch and Queue: The Opposite of Continuous Flow

Suppose you set up a batch and queue system for baking, frosting, decorating, and boxing a hundred birthday cakes at a bakery. As you bake the cakes, you need to come up with a good storage solution, so they stay fresh until you are ready to frost them. After all the cakes are frosted and you move onto the decorating step, you might find that the decorations don’t stick to the frosting. If you had just bake, frosted, and decorated one cake, you would have discovered and solved this problem before it became a defect affecting all the cakes. But since you have already baked and frosted all the cakes, you’re now in the position of having to buy new decorations that will stick to the frosting already on the cake. A similar problem could arise with the boxes. You might have a hundred cakes frosted and decorated, ready to be boxed, and then discover they don’t fit in the boxes you ordered. Meanwhile, the cakes are getting stale, and might soon become unsellable.

3. Continuous flow: According to Womack and Jones, most people tend to think the most efficient way to complete any multi-step project is to divide it into batches—performing the first step on all available materials and setting the results aside until all the materials have been processed. After the entire batch has been completed, you then move onto the next step, processing the entire batch, and so on, through all the steps. This approach, known as batch and queue, can be useful in many situations, but it’s often wildly inefficient and can lead to defects that aren’t detected until many steps into the process (Womack and Jones 2003, 22). To avoid the problems associated with batch and queue production, Lean emphasizes continuous flow from one step to the next, with small batches that can be immediately processed by workers at the next step. True continuous flow, which dramatically reduces production time, is only possible after you have eliminated the waste of non-value creating steps, and then rearranged the remaining steps so that they unfold one after the other. It is not a realistic goal in all industries, but you can often achieve some benefits of flow by moving machinery and relocating personnel. In project management, flow can become an issue during scheduling. For example, a project team might make the mistake of laboring over an unnecessarily detailed schedule with overly discrete time blocks, planning tasks for a multi-year project in hours. Then, after wasting all this time on an unrealistic schedule, the team might fail to review and update actual progress as the project progresses. This lack of flow can present real risks to the project’s overall success. By contrast, Lean-thinking project managers understand that a schedule is a living document, and that, throughout a project, they’ll need to address living order changes (both positive and negative), allowing for true flow throughout the life of the project.

4. Pull: To understand the meaning of pull, you first have to understand the meaning of push. Traditional production systems are considered push systems, with work dictated by production schedules which are sometimes tied to accurate forecasts of customer demand, but often are not. A push system easily results in the waste of over-production. Mark Graban offers some examples:

- A fast food restaurant making food and storing it under heat lamps (some of it gets thrown away).

- An automaker building an excess number of cars or trucks and forcing the dealers to take them.

- The U.S. Mint producing dollar coins that far exceed customer demand.

- Computer makers building product and shipping it to retailers to sit on the shelves. (2014)

By contrast, a pull system builds products and uses up materials based on actual customer demand, the way a sandwich shop might make your favorite turkey and guacamole sandwich after you order it. In reality, most systems use a combination of pull and push production. For example, making up your sandwich on the spot is a pull activity, but the store would probably have practiced push production by previously ordering turkey and guacamole according to forecasts of customer demand.

These examples greatly simplify the Lean concept of pull. In practice, especially in giant factories or on construction sites, it is far more complex. But the basic, waste-reducing principle is always the same: “no one upstream should produce a good or service until the customer downstream asks for it” (Womack and Jones 2003, 67).

This excellent blog post uses a concession stand example to illustrate the way a pull system avoids the wastes of inventory and over-production by keeping only small quantities of materials on-hand, replacing items as they are used:
Lean Blitz Consulting – “Toyota Way Principle #3: “Pull” Systems”

Translating the concept of pull to project management can be difficult but yields powerful results. The team starts with the end-point—the ultimate goal of the project—and pulls activities forward, describing what must be done each step of the way. This differs greatly from standard project management, which starts from the beginning, building a schedule that assumes previous tasks are completely finished before the team starts on the next tasks. By contrast, in a Lean schedule, more tasks overlap. Kanban is an adaptive project management methodology based on Lean concepts, including pull. We’ll discuss Kanban in more detail later in this lesson.

In a presentation on project planning for a transmission line design, Kristine Engel explains that, in a pull schedule, “the ‘later tasks’ may start before ‘earlier’ tasks end,” and that some “design refinement tasks may overlap with the labor bid process or even construction, which reflects the reality of utility projects.” Despite this fluidity, the team is able to track progress by comparing billed hours to the budget. The whole system is built on “regular communication with the client to revise short-term goals in relation to the full project timeline” (Engel 2017).

5. Perfection: Experienced practitioners of Lean testify that, as you get better at identifying the customer’s definition of value, you become more precise in identifying every step in the value stream. As a result, you reduce the waste of non-value adding activity, thereby improving flow. As you gain experience, you’ll start to see opportunities for Lean improvements everywhere. It’s like lifting weights—the more you lift, the more you can lift. The more waste you eliminate, the more waste you can eliminate. According to Jones and Womack, this happens because the four initial principles interact with each other in a virtuous circle. Getting value to flow faster always exposes hidden muda [waste] in the value stream. And the harder you pull, the more the impediments to flow are revealed so they can be removed. Dedicated product teams in direct dialogue with customers always find ways to specify value more accurately and often learn of ways to enhance flow and pull as well. (2003, 25)

6. Respect for People: Above all else, Lean requires constant communication among all stakeholders. Implementing the first five principles of Lean is only possible when all team members respect and listen to each other, share ideas, accept suggestions, and collaborate to solve problems and eliminate waste. Respect for people is not about being nice—it’s about understanding that you can’t solve problems on your own, and that instead you need to engage sincerely and honestly with co-workers. Sometimes that means challenging them and offering criticism. It always means being willing to admit when you’re wrong.

Push and Pull

This two-minute video explains the difference between push and pull production:

A YouTube element has been excluded from this version of the text. You can view it online here: https://wisc.pb.unizin.org/technicalpm/?p=5

1.7 Agile: Fast Feedback in Living Order

Lean was originally developed in the world of manufacturing but has been adopted in many industries. In the world of software development, a related approach, Agile, has become increasingly popular. Agile software development projects typically involve small, self-organizing teams who work collaboratively in short iterative cycles to produce working product increments. When you hear people talking about Agile, they may be referring generally to a set of values and principles intended to guide project teams in “achieving agility” by continuously adapting and improving the way they work. However, people often use the term Agile to refer to one of the many specific software development frameworks based on those values and principles, including the following.

The many flavors of Agile include:

- Scrum: Designed for completing complex projects using small, cross-functional, self-organizing teams (as described on ScrumGuides), Scrum is the most widely used form of Agile. When people refer to “Agile software development,” they are usually talking about Scrum practices, and we often do the same in this ebook.

- Kanban: Based on Lean principles, Kanban focuses on incremental change and continuous process improvement. Central to this simple framework is the Kanban board, which is a visual display of all the project work in progress, the work waiting to be started, and the work already completed. You can read more about the Kanban framework in this article: “Kanban”

- Extreme Programming (XP): Emphasizing short development cycles with frequent releases of software for evaluation, XP is based on a set of software development best practices. You can read more about extreme programming at “Extreme Programming: A Gentle Introduction“

- Crystal, Dynamic Systems Development Method (DSDM), and Feature-Driven Development (FDD): These are some of the other more popular Agile frameworks. You can read more about them and the other Agile frameworks in this list at “Project Management Frameworks”

Hackathons: Fostering an Agile Culture

Hackathons, another type of Agile experience, are typically multiday events in which software developers work on a solution to a specific problem with the goal of generating a number of innovative ideas and/or prototypes. Hackathons are similar to Agile sprints, but typically involve more intensive collaboration, with participants gathering in one place and dividing up into teams. Originating as a way for anyone to get involved in creating open-source software, hackathons are now common on college campuses and in the corporate world. For a glimpse into how Mastercard uses hackathons to generate new product ideas and foster an Agile culture within its organization, watch this short video: Hackathon Stories: Mastercard.

Most Agile approaches emphasize an iterative approach to product development, with the project specifications evolving along with the customer’s notion of the software requirements. According to project manager Steve Caseley, in a Microsoft Growth Center article, projects using these iterative development approaches “plan, develop, and implement project functionality in small chunks (or iterations). The key to successful iterative delivery is that each small chunk effectively operates as a smaller mini-project under the umbrella of the total project” (Caseley 2019).

A Scrum project starts with a conversation between the development team and the product owner about what the customer wants the software to do. In Scrum terminology, the customer is the product owner, and the features that the product owner wants included in the software are known as user stories, which may be expressed in simple, nontechnical language from the perspective of the person who wants that feature—for example, “As a car owner, I want to schedule my service appointment online so that I don’t have to spend time on the phone calling my mechanic.” Often, the person is a fictional persona representing a type of user or stakeholder.

The product owner prioritizes the user stories, which are collectively referred to as the product backlog, and in each development cycle, the team creates pieces of software that address one or more user stories. After a one- to two-week cycle of development (known in Scrum as a sprint) the team presents the new software to the product owner in a sprint review meeting so she can try it out and make suggestions for improvement. The team then begins another sprint, incorporating those suggestions into a new iteration and beginning work on new user stories, depending on their capacity. After every sprint, the product owner has the chance to redirect the team to new user stories, or to revise the team’s understanding of an existing user story. Through these repeated interactions, which provide fast, focused feedback, the team and the product owner zero in on a software application that does what the product owner needs it to do. If time and money are tight, as they often are, the product owner has regular opportunities to make choices about which user stories are the most important, and which can be dispensed with if necessary.

Agile development is essentially a learning process through which the development team and the product owner create a shared understanding of how many features they can create, given the allotted time and money. It’s very much a living order approach to project management, in that the early stages involve some ambiguity and many unknowns. According to Robert Merrill, a Senior Business Analyst at the University of Wisconsin-Madison, and an Agile coach, “Agile is a way to manage projects in the face of unpredictability and constraints—often very rigid time and budget constraints. The fast feedback allows the team to create the best possible software within the given constraints” (2017).

Although Agile had its roots in software development, companies have also expanded its use into a variety of project types, including manufacturing, product development, capital projects, and service projects. For one perspective on how an iterative, Agile approach can help manufacturing companies take advantage of new technologies, read this blog post from Fujitsu engineer Walter Graf: “How an Agile Approach Will Enable Manufacturers to Make Industry 4.0 Work for Them”

Some companies use a combination of Agile frameworks (often called hybrid Agile) or a combination of some predictive, plan-driven processes with elements of an Agile framework (also called a hybrid development approach). A hybrid Agile project might include classic Scrum elements such as a product owner and development sprints as well as a Kanban board that is used to pull work based on capacity. A hybrid development approach could involve predictive project planning along with more flexible Agile development cycles. Decisions  about which approach to use—whether it is a strictly Agile approach, such as Scrum, or a hybrid approach—should be based on the needs of the project as well as the organizational environment in which the project will unfold.

Paul Dandurdan, CEO of PieMatrix, a company whose products include a visual project management software platform, argues that there is value in both Agile and predictive, or waterfall, approaches. He propose a hybrid Agile/waterfall manifesto in a blog post that also highlights what he sees as the limitations of the original Agile Manifesto: “Hybrid Agile Manifesto and Spider Man.”

Like Lean, Agile will be a recurring topic throughout this book. To get started learning about Agile on your own, see the following:

- In 2001 a group of software developers published the Agile Manifesto in which they outlined the 12 principles of Agile software development. You can read the entire manifesto here: “Principles Behind the Agile Manifesto.”

- A Gentle Introduction to Agile, a blog post by Eric Bruno.

- “What is Agile Methodology?”, a five-minute video.

- “Agile Product Ownership in a Nutshell,” a 15:51-minute video about software development.

Agile: A New Kind of Engineering

In his fascinating lecture “Real Software Engineering,” Glenn Vanderburg presents the history of software engineering (2011). He explains how early software developers tended to think of software engineering in terms that were familiar to them from structural engineering, because that’s what they thought the term engineering meant. Vanderburg advocates a new, simple definition of engineering: whatever works.

History tells us that what used to be called software engineering actually had little to do with engineering, because so-called “software engineering projects” were riddled with waste, rework, and failure. In other words, it didn’t work. According Vanderburg, Agile is the only real form of software engineering. It is fundamentally different from structural engineering, in part because it allows for instantaneous, essentially-free testing—something that is impossible when building planes or bridges. Also, whereas other types of engineering typically involve modeling something over a long period of weeks or months, and then getting feedback, also over weeks or months, Agile developers receive feedback over different time scales. For individual blocks of code, developers can get important feedback in minutes or hours by simply sharing it with another developer or with the customer. For larger parts of the project, such as acceptance testing or a release of new features, getting feedback is more expensive and takes place over weeks or months.

The main reason feedback and testing in Agile software development differs so much from other types of engineering is that the source code is itself the model. By writing code, Agile developers create both the testable model and the final product at the same time. In Vanderburg’s words: “Agile processes are economical, cost-tuned feedback engines.”

~Practical Tips

- Take the time to identify the unique and changing context of a project: A project’s context—the day-to-day environment and the larger organizational background in which a project unfolds—is rarely the same from one project to the next, and can change throughout the course of the project. By identifying the unique context of each project, and the many ways it could change, you’ll reduce your chances of making assumptions that could turn out to be wrong. Those same considerations can help you determine which project management approach to use on a given project. Before introducing an Agile project management methodology, assess the extent to which your organizational culture lines up with Agile values and principles. Implementing Agile or hybrid Agile approaches within a more traditional organization can require patience and advocacy for the benefits that working in living order offers.

- If you are joining an existing project, learn all you can about the team culture, and set your immediate expectations accordingly: Start with an awareness of a project’s culture, assimilating and adjusting your way of doing things when you can. Use your indirect influence to shape project culture by building relationships.

- Be prepared to use both geometric and living order techniques: Projects are often conceived and planned in geometric order, with the naïve assumption of events unfolding predictably. Then reality hits, and they are executed amidst the uncertainties of living order. However, eventually, as projects unfold, and you begin to learn what to expect, they can become more geometric. Be prepared to move back and forth among geometric and living order techniques, adapting to the situation as necessary.

- When working in geometric order, focus on the following:

- Define project success.

- Establish a project timeline.

- Ensure the project delivers the specified results.

- Constantly check your progress against the project schedule.

- Regularly check costs against the project budget.

- Periodically pause to make sure the project really is unfolding in geometric order and hasn’t shifted to living order.

- When working in living order, follow good geometric practices when appropriate, but also focus on the following:

- Ensure that all stakeholders understand the project’s shared value and are committed to achieving it.

- Incorporate every useful form of communication to make sure project stakeholders understand what’s going on at every stage of the project.

- Focus on activities that create value and eliminate wasteful activities.

- Be prepared to respond to changing events, staying Agile and adaptable.

~Summary

- Projects unfold in unique and changing contexts that call for a flexible, adaptable approach.

- Projects are impacted by a myriad of internal and external forces. One such force, culture, can have a profound effect on a project’s context and its outcome. Projects that use the same tools, contracts, and structures may have starkly different outcomes depending on the culture of the project team and the organization.

- Organizations often conceive projects in the unpredictable upheaval of living order and then attempt to execute them in the more systematic geometric order, planning every step down to the last detail. Successful project managers never lose sight of the unpredictable, permanent whitewater world in which projects actually unfold.

- Understanding that a project’s life cycle involves more than just the making stage will expand your understanding of “project success.”

- Lean project management focuses on maximizing value and eliminating waste.

- Project management frameworks based on Agile values and principles encourage the flexibility required in living order. Hybrid Agile approaches and hybrid development approaches combine features of one or more Agile frameworks—sometimes in combination with elements of more traditional waterfall approaches.

~Glossary

- Agile—A set of values and principles intended to guide project teams in “achieving agility” by continuously adapting and improving the way they work. Also sometimes used to refer to one of the software development frameworks and methodologies that are based on those values and principles; Agile approaches emphasize an iterative approach to product development, with the project specifications evolving along with the customer’s notion of the software requirements. Popular Agile frameworks and methodologies include Scrum, Kanban, and Extreme Programming (XP).

- behavioral economics—According to OxfordDictionaries.com, “a method of economic analysis that applies psychological insights into human behavior to explain economic decision-making.”

- geometric order—A type of order identified by the French philosopher Henri Bergson that is characterized by linear development, clear cause and effect, and predictable events.

- hybrid Agile— A combination of Agile frameworks—such as Scrum sprints and a product owner used along with a Kanban board.

- integrated project delivery (IPD)—A means of contractually aligning stakeholders in a construction project in a way that emphasizes close collaboration, with the goal of delivering value as defined by the customer. IPD is inspired by Lean and relies on a type of contract known as a multi-party agreement, which explains each participant’s role in the project.

- Lean—A business model and project management philosophy that offers a means to streamline projects while allowing for the flexibility required to deal with unexpected events. It emphasizes the elimination of waste through the efficient flow of work from one phase of a project to another.

- living order—A type of order identified by the French philosopher Henri Bergson that is characterized by rapid change and unpredictable events.

- organizational culture–The set of behaviors, values, artifacts, reward systems, and rituals that make up an organization.

- project—A “piece of planned work or activity that is completed over a period of time and intended to achieve a particular aim”(Cambridge English Dictionary 2018).

- project culture—A set of beliefs, attitudes and behaviors that exist independently of the individuals working on the project.
project outcome—In its narrowest sense, a project’s measurable output—whether that’s a building, a software application, or a part for a fighter jet. In a broader sense, the impact a project has compared to its larger goals.

- project success—The degree to which a project is done well. Stakeholders’ evaluation of project success is a subjective judgement, varying depending on their perspective, and typically changes over time.

- project management—The “application of processes, methods, knowledge, skills, and experience to achieve the project objectives” (Association for Project Management 2018).

- sprint—In Scrum, short cycle of software development (often one or two weeks).

- user story—A feature that the product owner wants included in the software being developed. It may be expressed in simple, nontechnical language from the perspective of the person who wants that feature—for example, “As a car owner, I want to schedule my service appointment online so that I don’t have to spend time on the phone calling my mechanic.”

- value—In ordinary conversation, a generic term that refers to the overall worth or usefulness of something. But in Lean, value is only meaningful “when expressed in terms of a specific product (a good or a service, and often both at once) which meets the customer’s needs at a specific price at a specific time” (Womack and Jones 2003, 16). In other words, value is defined by the customer.

~Additional Resources

- The Guide to Lean Enablers for Managing Engineering Programs, published by the Joint MIT PMI INCOSE Community of Practice on Lean in Program Management (2012).

- Managing as a Performing Art: New Ideas for a World of Chaotic Change, by Peter B. Vaill (1989). In this book Vaill introduces the term “permanent whitewater.”

- Richard Thaler’s memoir of his life and work in the field of behavioral economics: Misbehaving: The Making of Behavioral Economics (2015).

- The classic introduction to Lean: The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, by Jeffrey Liker(2004).

~References

Association for Project Management. n.d. “What is project management?” apm.org. Accessed June 15, 2018. https://www.apm.org.uk/resources/what-is-project-management/.

Atamian, Luna. 2017. “Why is Walmart a sustainability leader?” Huffington Post, December 14. https://www.huffingtonpost.com/entry/why-is-walmart-a-sustainability-leader_us_5a329da5e4b00caf3d59eae8.

Bergson, Henri. 1911. “Creative Evolution.” Project Gutenberg. Accessed June 15, 2018. http://www.gutenberg.org/files/26163/26163-h/26163-h.htm.

Bersin, Josh. 2015. “Culture: Why It’s the Hottest Topic in Business Today.” Forbes. March 13. https://www.forbes.com/sites/joshbersin/2015/03/13/culture-why-its-the-hottest-topic-in-business-today/#27b6f20f627f.

Bloch, Michael, Sven Blumberg, and Jürgen Laartz. 2012. “Delivering Large-Scale IT Projects on Time, on Budget and on Value.” McKinsey&Company. October. Accessed August 4, 2016. http://www.mckinsey.com/business-functions/business-technology/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value.

Burrough, Bryan. 2011. “Behind the Greening of Wal-Mart.” New York Times, May 14. http://www.nytimes.com/2011/05/15/business/15shelf.html?_r=0.

Business for Social Responsibility. 2008. “Software Accellerates Sustainable Development.” bsr.org. http://www.bsr.org/reports/BSR_Software_Accelerates_Sustainable_Development.pdf.

Cambridge English Dictionary. 2018. “project.” Cambridge Dictionary. Accessed May 12, 2018. https://dictionary.cambridge.org/us/dictionary/english/project.

Caseley, Steve. 2019. “Project Management: Traditional, Iterative, or Hybrid?” Microsoft: The Growth Center. June 20. https://www.microsoft.com/en-us/microsoft-365/growth-center/resources/adopting-the-best-project-management-process-for-your-business.

Engel, Kristine. 2017. “Project Planning for Transmission Line Design.” PowerPoint presentation for class in Technical Project Management, University of Wisconsin-Madison, October 12.

Graban, Mark. 2014. “#Lean: Clarifying Push, Pull, and Flow in a Hospital; the Patient “Pulls”.” Mark Graban’s Lean Blog. February 24. https://www.leanblog.org/2014/02/flow-push-and-pull-in-a-hospital/.

Green Wiki. 2015. “Sustainable Code Development.” Green Wiki. June 9. http://green.wikia.com/wiki/Sustainable_code_development.

Hosey, Lance. 2005. “More Constructive Ways to Build a City.” The Washington Post, January 9. http://www.washingtonpost.com/wp-dyn/articles/A57855-2005Jan7.html.

Kanari, N., J.L. Pineau, and S. Shallari. 2003. “End-of-Life Vehicle Recycling in the European Union.” Journal of the Minerals, Metals & Materials Society, August. Accessed June 9, 2015. http://www.tms.org/pubs/journals/jom/0308/kanari-0308.html.

Knee, Jonathan A. 2015. “In ‘Misbehaving,’ an Economics Professor Isn’t Afraid to Attack His Own.” New York Times, May 5. http://www.nytimes.com/2015/05/06/business/dealbook/book-review-misbehaving-by-richard-thaler.html?_r=1.

Larson, Erik W., and Clifford F. Gray. 2011. Project Management: The Managerial Process, Sixth Edition. New York: McGraw-Hill Education.Laufer, Alexander. 2012. Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results. Upper Saddle River: FT Press.

Laufer, Alexander, Edward J. Hoffman, Jeffrey S. Russell, and Scott W. Cameron. 2015. “What Successful Project Managers Do.” MIT Sloan Management Review, Spring: 43-51. http://sloanreview.mit.edu/article/what-successful-project-managers-do/.

Lean Enterprise Institute. 2014. Lean Lexicon, Fifth Edition. Edited by Chet Marchwinski. Cambridge, MA: Lean Enterprise Institute.

Lean Manufacturing Tools. n.d. “Waste of Defects; causes, symptoms, examples and solutions.” Lean Manufacturing Tools. Accessed November 11, 2017. http://leanmanufacturingtools.org/129/waste-of-defects-causes-symptoms-examples-and-solutions/.

—. n.d. “Waste of Overproduction; causes, symptoms, examples and solutions.” Lean Manufacturing Tools. Accessed November 11, 2017. http://leanmanufacturingtools.org/114/waste-of-overproduction-causes-symptoms-examples-and-solutions/.

Merrill, Robert, interview by Ann Shaffer. 2017. Senior Business Analyst, University of Wisconsin-Madison (October 2).

Merrow, Edward W. 2011. Industrial Megaprojects: Concepts, Strategies, and Practices for Success. Hoboken, New Jersey: John Wiley & Sons, Inc.

Mieritz, Lars. 2012. “Gartner Survey Shows Why Projects Fail.” This Is What Good Looks Like. June 10. https://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/.

ORC International: Expert Advisory Services. n.d. Rapid Product Development Experts. Accessed September 9, 2016. http://www.orcexperts.com/experts.asp?strSearchType=all&strQuery=rapid+product+development.

Pagenkopf, David. 2018. “Email on sustainability and software design.”

Thaler, Richard H. 2015. “Unless You Are Spock, Irrelevant things Matter in Economic Behavior.” New York Times, May 8. http://www.nytimes.com/2015/05/10/upshot/unless-you-are-spock-irrelevant-things-matter-in-economic-behavior.html?abt=0002&abg=0.

Vanderburg, Glenn. 2011. “Lone Star Ruby Conference 2010 Real Software Engineering by Glenn Vanderburg.” Published October 24, 2011. YouTube video, 51:56. https://www.youtube.com/watch?v=NP9AIUT9nos&feature=youtu.be

Womack, James P., and Daniel T. Jones. 2003. Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated. New York: Free Press.

1. In a nod to the origins of Lean, the Japanese word for waste, muda is often used in publications about Lean. ↵

2

Strategy, Project Selection, and Portfolio Management

Strategy is making trade-offs in competing.
The essence of strategy is choosing what not to do.
— Michael E. Porter, “What is Strategy?” (1996)

Objectives

After reading this lesson, you will be able to

- Define terms related to strategy and portfolios

- Discuss basic concepts related to strategy

- Distinguish between strategy and operational effectiveness

- Explain what makes executing a strategy difficult

- Discuss issues related to aligning projects with strategy

- Explain why killing projects can be hard, and suggest ways to identify a poorly conceived project

The Big Ideas in this Lesson

- Strategy is a plan to provide something customers can’t get from competitors. Strategy means focusing on what the organization does best. It should be motivated by customer pull, rather than organizational push.

- An organization’s strategy should govern everything it does, guiding project selection and execution, and, when necessary, project termination.

- Strategy is different from operational effectiveness—cutting costs and increasing efficiency. Operational effectiveness is an important tool. But founding an organization’s strategy entirely on operational effectiveness is a losing game because the competition will always catch up eventually.

2.1 Do the Right Thing

Effective project management and execution start with choosing the right projects. While you might not have control over which projects your organization pursues, you do need to understand why your organization chooses to invest in particular projects so that you can effectively manage your projects and contribute to decisions about how to develop and, if necessary, terminate a project. Your study of technical project management will primarily focus on doing things the right way. In this lesson, we’ll concentrate on doing the right thing from the very beginning.

As always, it’s helpful to start with some basic definitions:

- project: The “temporary initiatives that companies put into place alongside their ongoing operations to achieve specific goals. They are clearly defined packages of work, bound by deadlines and endowed with resources including budgets, people, and facilities” (Morgan, Levitt and Malek 2007, 3). Note that this is a more expansive definition than the Cambridge English Dictionary definition introduced in Lesson 1—“a piece of planned work or activity that is completed over a period of time and intended to achieve a particular aim”—because in this lesson we focus on the tradeoffs necessitated by deadlines and limited resources.

- program: “A cluster of interconnected projects” (Morgan, Levitt and Malek 2007, 9).

- portfolio: The “array of investments in projects and programs a company chooses to pursue” (Morgan, Levitt and Malek 2007, 3).

- strategy: According to Merriam-Webster, “a careful plan or method for achieving a particular goal usually over a long period of time.”

As shown in Figure 2-1, a portfolio is made up of programs and projects. An organization’s strategy is the game plan for ensuring that the organization’s portfolios, programs, and projects are all directed toward a common goal.

Figure 2-1: Relationship between a portfolio, programs, and projects

2.2 The Essence of Strategy

Many books and articles attempt to explain what the term “strategy” really means. But in the end, as Mark Morgan, Raymond E. Levitt, and William Malek explain in Executing Your Strategy: How to Break it Down & Get it Done, an organization’s strategy is defined by what the organization invests in—that is, what the organization does: “the best indicator of strategic direction and future outcomes is an enterprise-wide look at what the company is doing rather than what it is saying—what the strategy makers are empowering people at the execution level to accomplish” (2007, 3).

An organization without a clearly defined strategy can never expect to navigate the permanent whitewater of living order. This is especially if the strategy is motivated by the organization attempting to push its vision onto customers, rather than pulling the customer’s definition of value into its daily operations . An organization’s strategy is an expression of its mission and overall culture. In a well-run company, every decision about a project, program, or portfolio supports the organization’s strategy. The strategy, in turn, defines the company’s portfolio and day-to-day operations. Projects and their budgets flow out of the organizational strategy. Morgan et al. emphasize the importance of aligning a company’s portfolio with its strategy:

Without clear leadership that aligns each activity and every project investment to the espoused strategy, individuals will use other decision rules in choosing what to work on: first in, first out; last in, first out; loudest demand; squeakiest wheel; boss’s whim; least risk; easiest; best guess as to what the organization needs; most likely to lead to raises and promotion; most politically correct; wild guess—or whatever they feel like at the time. Portfolio management still takes place, but it is not necessarily aligned with strategy, and it occurs at the wrong level of the organization. (2007, 5)

As a project manager, you should be able to refer to your organization’s strategy for guidance on how to proceed. You should also be able to use your organization’s strategy as a means of crossing possibilities off your list. Michael E. Porter, author of the hugely influential book Competitive Strategy, explains that strategy is largely a matter of deciding what your organization won’t do. In an interview with Fast Company magazine, he puts it like this:

The essence of strategy is that you must set limits on what you’re trying to accomplish. The company without a strategy is willing to try anything. If all you’re trying to do is essentially the same thing as your rivals, then it’s unlikely that you’ll be very successful. It’s incredibly arrogant for a company to believe that it can deliver the same sort of product that its rivals do and actually do better for very long. That’s especially true today, when the flow of information and capital is incredibly fast. (Hammonds 2001)

Ultimately, strategy comes down to making trade-offs. It’s about “aligning every activity to create an offering that cannot easily be emulated by competitors” (Porter 2001). Southwest Airlines, which has thrived while most airlines struggle, is often hailed as an example of a company with a laser-like focus on a well-defined strategy. Excluding options from the long list of possibilities available to an airline allows Southwest to focus on doing a few things extremely well—specifically providing reliable, low-cost flights between mid-sized cities. As a writer for Bloomberg View puts it:

By keeping the important things simple and implementing them consistently, Southwest manages to succeed in an industry better known for losses and bankruptcies than sustained profitability. Yet none of this seems to have gone to the company’s head, even after 40 years. As such, the airline serves as a vivid—and rare—reminder that size and success need not contaminate a company’s mission and mind-set, nor erode the addictive enthusiasm of management and staff. (El-Erian 2014)

2.3 Operational Effectiveness is not Strategy

In his writings on strategy, Michael Porter takes pains to distinguish between strategy and operational effectiveness—getting things done faster and more cheaply than competitors. Managers tend to confuse these two very different things. A well-defined strategy focuses on what sets an organization apart from the competition—what it can do uniquely well. Operational effectiveness—working faster and cutting costs and then cutting them again—is a game anyone can play. But it’s not viable over the long term because competitors will always catch up:

It’s extremely dangerous to bet on the incompetence of your competitors—and that’s what you’re doing when you’re competing on operational effectiveness.

What’s worse, a focus on operational effectiveness alone tends to create a mutually destructive form of competition. If everyone’s trying to get to the same place, then, almost inevitably, that causes customers to choose on price. (Hammonds 2001)

Michael Porter’s influential article “What is Strategy?” explains the difference between operational effectiveness and strategy, using the success of Southwest Airlines as a real-life example (1996). Subscribers to the Harvard Business Review can read the complete article here: “What is Strategy?“

Porter published Competitive Strategy in 1980. Since then the business world has changed considerably, becoming faster paced, with more projects unfolding in living order. Some suggest that, in an environment of constant change, picking one strategy and sticking to it is a recipe for disaster. Porter argues that the opposite is true. The secret is to focus on “high-level continuity” that coordinates the assimilation of change:

The thing is, continuity of strategic direction and continuous improvement in how you do things are absolutely consistent with each other. In fact, they’re mutually reinforcing. The ability to change constantly and effectively is made easier by high-level continuity. If you’ve spent 10 years being the best at something, you’re better able to assimilate new technologies. The more explicit you are about setting strategy, about wrestling with trade-offs, the better you can identify new opportunities that support your value proposition. Otherwise, sorting out what’s important among a bewildering array of technologies is very difficult. Some managers think, “The world is changing, things are going faster—so I’ve got to move faster. Having a strategy seems to slow me down.” I argue no, no, no—having a strategy actually speeds you up. (Hammonds 2001)

2.4 Lean and Strategy

As you learned in Lesson 1, the Lean approach to project management focuses on eliminating waste and maximizing customer value. It is primarily a means of streamlining operational effectiveness, but it also offers major strategic benefits. In a truly Lean organization, managers have the time and autonomy to focus on high-level issues. The emphasis on flexibility makes it easier for a Lean organization to pivot to new opportunities that align with the organization’s strategy. In an article for Planet Lean, Michael Ballé explains:

Lean is often reduced to a manufacturing tactic because it doesn’t fit the frame of traditional strategy. Lean can’t tell you which niche to pursue, it can’t help you build a roadmap, and it won’t tell you what reasonable objectives are or how to incentivize people to get them.

Lean, however, is the key to creating dynamic strategies built on more mindful care of customers, more dynamic objectives (reduce the waste by half every year), faster learning, greater involvement of all people all the time for stronger morale, more determined focus on higher-level goals and quicker exploitation of unexpected opportunities. (2016)

According to Ballé, a Lean strategy might look like this:

1. Know your customers and follow their changing expectations;

2. Choose the improvement dimensions to put dynamic pressure on the market (by driving the pressure on your own operations);

3. Learn operational performance faster than your competitors;

4. Develop managers’ autonomy and keep the focus on the bigger issues;

5. Follow through quickly on unexpected gains. (2016)

Because implementing Lean effectively requires a buy-in from an entire organization, with everyone from the top down learning to think Lean, succeeding with Lean is difficult. That means the organizations that do succeed have something rare to offer their customers, setting them apart from the competition. In other words, converting an organization to Lean methodologies can be a strategy in and of itself. Truly Lean organizations are first and foremost learning organizations, with a focus on learning everything possible about the market and their customers’ needs. This makes them vastly superior at supplying the value customers want.

In their book The Lean Strategy, Ballé, Jones, Chaize, and Fiume make the case for Lean as something more than a means toward operational effectiveness. They see it as a true strategy:

Lean strategy represents a fundamentally different approach: seeing the right problems to solve, framing the improvement directions such that every person understands how he or she can contribute, and supporting learning through change after change at the value-adding level in order to avoid wasteful decisions. Sustaining an improvement direction toward a North Star and supporting daily improvement to solve global challenges make up a strategy, and a winning one. (2017, x)

2.5 Why is Executing a Strategy So Hard?

Despite the clear advantages of creating and sticking with a strategy, organizations and individual managers have difficulty doing so:

Corporations spend about $100 billion a year on management consulting and training, most of it aimed at creating brilliant strategy. Business schools unleash throngs of aspiring strategists and big-picture thinkers into the corporate world every year. Yet studies have found that less than 10 percent of effectively formulated strategies carry through to successful implementation. So something like 90 percent of companies consistently fail to execute strategies successfully. (Morgan, Levitt and Malek 2007, 1)

Why is executing a strategy so difficult? According to Porter, one problem is that managers often mistakenly think that making tradeoffs is a sign of weakness:

Trade-offs are frightening, and making no choice is sometimes preferred to risking blame for a bad choice…. The failure to choose sometimes comes down to the reluctance to disappoint valued managers or employees. (Porter 1996)

Project Failure Close to Home

One example of a failed IT project is the UW-Madison’s attempt to implement a new payroll and benefits system. The University finally halted the project in July 2006 after spending $26 million. System Executive Senior Vice President Don Mash said “We just found it very, very difficult. We probably underestimated the complexity of it when we started way back when” (Foley 2006).

You can read more about the project here: “$26 Million Software Scrapped by UW System: Officials Regret the Loss But Believe A Different Vendor Will Prove Better In the Long Run.”

As the Nobel Prize winning economist Herbert Simon demonstrated, in many situations, it is not realistic or even possible to collect all the information necessary to determine the optimal solution. He uses the word satisfice (a combination of satisfy and suffice) to describe a more realistic form of decision-making, in which people accept “the ‘good-enough’ solution rather than searching indefinitely for the best solution” (Little 2011). In order to stay true to its strategy, a successful organization will often choose to satisfice, instead of optimize.

Organizations are also very susceptible to the sunk cost fallacy, which is the tendency “to continue investing in a losing proposition because of what it’s already cost…” (Warrell 2015). Managers will often shy away from making alterations to the organization’s strategy if such alterations necessitate cutting projects that have already received significant investment—even if the projects themselves are widely considered to be failures. At the same time, corporations have to consider how killing a project will affect its earnings. As a result, project managers, fearing they’ll be pinned with responsibility for driving down their company’s stock price, refuse to kill projects they know have no chance of succeeding.

As an example, let’s consider how killing a project might play out in the IT world, as explained by David Pagenkopf:

Most of the work to implement an IT project for internal use must be capitalized, with the cost amortized over the expected life of the software (typically, five years). However, if an IT project is terminated, then the entire cost of the project must be expensed that year. That won’t affect the organization’s cash-flow, but it could materially affect the income statement for that year. For large, multi-year projects, a major write-off can drive net income to a loss and devastate the stock price. In short order, the project manager and the sponsor will likely be looking for a new job. So it’s no surprise people tend to “kick the can” down the road, which of course only magnifies the eventual problem.

I once had this problem in a portfolio of projects I inherited when starting a new job. After firing both the internal project manager and the contractor project manager, I had to find a way to put lipstick on a pig and get some value from the project to avoid a write-down. (Note: It is never good when the CFO of a Fortune 500 company has direct interest in an IT project.) My point is that people sometimes continue to make poor investment decisions not because they don’t know better, but rather to buy time, or to escape, sometimes by shifting the blame to someone else.[1]

2.6 Aligning Projects with Strategy Through Portfolio Management

Projects are the way organizations operationalize strategy. In the end, executing a strategy effectively means pursuing the right projects. In other words, it’s a matter of aligning projects and initiatives with the company’s overall goals. And keep in mind that taking a big-picture, long-term approach to executing a new organizational strategy requires a living order commitment to a certain amount of uncertainty in the short term. It can take a while for everyone to get on board with the new plan, and in the meantime operations may not proceed as expected. But by keeping your eye on the North Star of your organization’s strategy, you can help your team navigate the choppy waters of change.

Project selection proceeds on two levels: the portfolio level and the project level. On the portfolio level, management works to ensure that all the projects in a portfolio support the organization’s larger strategy. In other words, management focuses on optimizing its portfolio of projects. According to Morgan et al., portfolio optimization is “the difficult and iterative process of choosing and constantly monitoring what the organization commits to do” (2007, 167).

Morgan et al. see portfolio management as the heart and soul of pursuing a strategy effectively:

Strategic execution results from executing the right set of strategic projects in the right way. It lies at the crossroads of corporate leadership and project portfolio management—the place where an organization’s purpose, vision, and culture translate into performance and results. There is simply no path to executing strategy other than the one that runs through project portfolio management. (2007, pp. 4-5)

To manage portfolios effectively, large organizations often use scenario-planning techniques that involve sophisticated quantitative analysis. One such technique is based on the knapsack problem, a classic optimization problem. Various items, each with a weight and a value are available to be placed in a knapsack. As shown in Figure 2-2, the challenge is to choose the types and numbers of items that can be fit into the knapsack without exceeding the weight limit of the knapsack. Portfolio managers are faced with a similar challenge: choosing the number and types of projects, each with a given cost and value, to optimize the collective value without exceeding resource availability.

Figure 2-2: Large organizations often use scenario-planning techniques like the knapsack problem

On the project level, teams focus on selecting, refining, and then advancing or, if necessary, terminating individual projects. Some compliance-related projects have to be completed no matter what. But companies typically generate far more ideas for new projects than they can reasonably carry out. So to optimize its portfolio, every organization needs an efficient process for capturing, sorting, and screening ideas for new projects, and then for approving and prioritizing projects that are ultimately green-lighted. We’ll look at some project-selection methods shortly. But first, let’s look at some things that influence project selection.

Factors that Affect Project Selection

In any organization, project selection is influenced by the available resources. When money is short, organizations often terminate existing projects and postpone investing in new ones. For example, in 2015, the worldwide drop in oil prices forced oil companies to postpone $380 billion in projects, such as new deep-water drilling operations (Scheck 2016).

An organization’s project selection process is also influenced by the nature of the organization. At a huge aerospace technology corporation, for example, the impetus for a project nearly always comes from the market, and is loaded with government regulations. Such projects are decades-long undertakings, which necessarily require significant financial analysis. At a consumer products company, the idea for a project often originates inside the company as a way to respond to a perceived consumer demand. In that case, with less time and fewer resources at stake, the project selection process typically proceeds more quickly.

Size is a major influence on an organization’s project selection process. At a large, well-established corporation, the entrenched bureaucracy can impede quick decision-making. By contrast, a twenty-person start-up can make decisions quickly and with great agility.

Value and Risk

Keep in mind that along with the customer’s definition of value comes the customer’s definition of the amount of risk he or she is willing to accept. As a project manager, it’s your job to help the customer understand the nature of possible risks inherent in a project, as well as the options for and costs of reducing that risk. It’s the rare customer who is actually willing or able to pay for zero risk in any undertaking. In some situations, the difference between a little risk and zero risk can be enormous. This is true, for instance, in the world of computer networking, where a network that is available 99.99% of the time (with 53 minutes and 35 seconds of down time a year) costs much less than a network that is 99.999% available (with only 5 minutes and 15 seconds of down time a year) (Dean 2013, 645). If you’re installing a network for a small chain of restaurants, shooting for 99.99% availability is a waste of time and money. By contrast, on a military or healthcare network, 99.999% availability might not be good enough.

Identifying the magnitude and impact of risks, as well as potential mitigation strategies, are key elements of the initial feasibility analysis of a project. Decision-makers will need that information to assess whether the potential value of the project outweighs the costs and risks. Risk analysis will be addressed further in Lesson 8. For some easy-to-digest summaries of the basics of risk management, check out the many YouTube videos by David Hillson, who is known in the project management world as the Risk Doctor. Start with his video named “Risk management basics: What exactly is it?”

Effects of Poor Portfolio Management

Organizations that lack an effective project selection process typically struggle with four major portfolio-related issues. In an article for Research Technology Management, Robert G. Cooper, Scott J. Edgett, and Elko J. Kleinschmidt describe these issues as follows:

1. Resource balancing: Resource demands usually exceed supply, as management has difficulty balancing the resource needs of projects with resource availability.

2. Prioritizing projects against each other: Many projects look good, especially in their early days, and thus too many projects “pass the hurdles” and are added to the active list. Management seems to have difficulty discriminating between the Go, Kill, and Hold projects.

3. Making Go/Kill decisions in the absence of solid information: Up-front evaluations of viability are substandard in projects, the result being that management is required to make significant investment decisions, often using very unreliable data. No wonder so many of their decisions are questionable!

4. Too many minor projects in the portfolio: There is an absence of major revenue generators and the kinds of projects that will yield significant technical, market, and financial breakthroughs. (2000)

These problems can lead to a host of related issues. One common issue is related to capacity, which is defined as follows:

Capacity is the maximum level of output that a company can sustain to make a product or provide a service. Planning for capacity requires management to accept limitations on the production process. No system can operate at full capacity for a prolonged period; inefficiencies and delays make it impossible to reach a theoretical level of output over the long run. (Investopedia n.d.)

While it might sound desirable for an organization to be running at full capacity, using every available resource, in fact such a situation usually leads to log jams, making it impossible for projects to proceed according to schedule. It’s essential to leave some capacity free—typically 20% to 30% is considered desirable–for managing resources and dealing with the inevitable unexpected events that arise in living order. Attempting to execute too many projects, and therefore using up too much capacity, can generate the following problems:

Fuzzy Front End

The earliest stage of product development is sometimes referred to as the Fuzzy Front End (FFE), or sometimes stage 0 or the ideation stage. This stage precedes the official New Product Development stage. According to a blog post for SmartSheet, FFE is “considered one of the best opportunities for driving innovation in a company. FFE is not frequently mapped in any formal way, since this is the phase where you pitch all of your great ideas for solutions to your customer’s problems. FFE is called fuzzy because it occurs before any formal development starts, in the vague period where little structure or defined direction exists. Very few products that are originally pitched in FFE come out of it; however, this stage of pre-development is critical. Successful completion of pre-development can take you seamlessly into development” (n.d.). You can read the complete blog post here: “What Is New Product Development?”

1. Time  to market starts to suffer, as projects end up in a queue, waiting for people and resources to become available….

2. People are spread very thinly across projects. With so many “balls in the air,” people start to cut corners and execute in haste. Key activities may be left out in the interest of being expedient and saving time. And quality of execution starts to suffer. The end result is higher failure rates and an inability to achieve the full potential of would-be winners….

3. Quality of information on projects is also deficient. When the project team lacks the time to do a decent market study or a solid technical assessment, often management is forced to make continued investment decisions in the absence of solid information. And so projects are approved that should be killed. The portfolio suffers.

4. Finally, with people spread so thinly across projects, and in addition, trying to cope with their “real jobs” too, stress levels go up and morale suffers. And the team concept starts to break down. (Cooper, Edgett and Kleinschmidt 2000)

The Project Selection Process

No matter the speed at which its project selection process plays out, successful organizations typically build in a period of what Scott Anthony calls “staged learning,” in which the project stakeholders expand their knowledge of potential projects. In an interesting article in the Harvard Business Review, Anthony compares this process to the way major leagues use the minor leagues to learn more about the players they want to invest in. In the same way, consumer product companies use staged learning to expose their products to progressively higher levels of scrutiny, before making the final, big investment required to release the product to market (Anthony 2009).

You can think of the project selection process as a series of screens that reduce a plethora of ideas, opportunities, and needs to a few approved projects. From all available ideas, opportunities, and needs, the organization selects a subset that warrant consideration given their alignment with the organization’s strategy. As projects progress, they are subjected to a series of filters based on a variety of business and technical feasibility considerations. As shown in Figure 2-3, projects that pass all screens are refined, focused, and proceed to execution.

Figure 2-3: A project selection process can be seen as a series of screens

This same concept is applied in Stage-Gate™ or phase-gate models, in which a project is screened and developed as it passes through a series of stages/phases and corresponding gates. During each stage/phase, the project is refined, and at each gate a decision is required as to whether the project warrants the additional investment needed to advance to the next stage/phase of development. “The typical Stage-Gate new product process has five stages, each stage preceded by a gate. Stages define best-practice activities and deliverables, while gates rely on visible criteria for Go/Kill decisions” (Cooper, Edgett and Kleinschmidt 2000).

The approach to project selection that emphasizes killing unviable projects early is neatly expressed by the Silicon Valley mantra “Fail early, fail often.” As Dominic Basulto argues in a blog post for the Washinton Post:

The future of innovation is in learning how to fail.

That may sound counter-intuitive, but if you look at several of the recent trends in innovation — everything from rapid prototyping to the common Internet practice of releasing products early in beta — they are all about making rapid, iterative adjustments that uncover tiny failures and then correcting them more quickly than one’s competitors…

Companies must find new ways to move failure to the beginning, rather than the end, of the innovation cycle. Put another way: Would you rather fail when your product hits the market after years of hard work and millions of dollars in sunk costs, or fail earlier when you have less to lose? (Basulto 2012)

This approach is designed to help an organization make decisions about projects about which very limited knowledge is available at the outset. The initial commitment of resources is devoted to figuring out if the project is viable. After that, you can decide if you are ready to proceed with detailed planning, and then, whether to implement the project. This process creates a discipline of vetting each successive investment of resources and allows safe places to kill the project if necessary.

Another approach to project selection, set-based concurrent engineering,avoids filtering projects too quickly, instead focusing on developing multiple solutions through to final selection just before launch. This approach is expensive and resource-hungry, but its proponents argue that the costs associated with narrowing to a single solution too soon—a solution that subsequently turns out to be sub-optimal—are greater than the resources expended on developing multiple projects in parallel. Narrowing down rapidly to a single solution is typical of many companies in the United States and in other western countries. Japanese manufacturers, by contrast, emphasize developing multiple options (even to the point of production tooling). For more on set-based project selection, see this article in MIT Sloan Management Review: “Toyota’s Principles of Set-Based Concurrent Engineering.”

In an article for the International Project Management Association, Joni Seeber discusses some general project selection criteria. Like Michael Porter, she argues that first and foremost, you should choose projects that align with your organization’s overall strategy. She suggests a helpful test for determining whether a project meaningfully contributes to your organization’s strategy:

A quick and dirty trick to determining the meaningfulness of a project is answering the question “So what?” about intended project outcomes. The more the project aligns with the strategic direction of the organization, the more meaningful. The higher the likelihood of success, the more meaningful.

To illustrate, developing a vaccine for HIV is meaningful; developing a vaccine for HIV that HIV populations cannot afford is not. Size matters as well since the size of a project and the amount of resources required are usually positively correlated. Building the pyramids of Egypt may be meaningful, but the size of the project makes it a high stakes endeavor only suitable to pharaohs and Vegas king pins. (2011)

Seeber also suggests focusing on projects that draw on your organization’s core competencies:

The term sunk cost fallacy  refers to the tendency “to continue investing in a losing proposition because of what it’s already cost…” (Warrell 2015). See this article for a quick introduction to this essential human weakness, which can cause managers to extend failing projects long after they are no longer viable: “Sunk-Cost Bias: Is it Time to Call it Quits?“

Core competencies are offerings organizations claim to do best. An example of a core competency for Red Cross, for example, would be international emergency disaster response. Projects based on core competencies usually achieve outcomes with the best value propositions an organization can offer and, therefore, worthwhile for an organization to map its core competencies and select projects that build on strength. (2011)

For more ideas on project selection criteria, see this video, recommended by Seeber in her article: “Project Selection Criteria.” This article summarizes the problems that arise when organizations attempt to respond to every customer request by launching new projects willy nilly, thereby exceeding its overall capacity: “Saying ‘No’ to Customers.”

Beware of Cognitive Biases

A cognitive bias is an error in thinking that arises from the use of mental shortcuts known as heuristics. As Amos Tversky and Daniel Kahneman demonstrated in their ground-breaking study of decision-making, we all use heuristics to quickly size up a situation (1974). For example, we might use the availability heuristic to refer to the first similar situation that comes to mind, and then, using that situation as a reference, make judgements about the current situation. While that can be effective, it can also lead to misconceptions and illusions known as cognitive biases. Just because something readily comes to mind does not mean it is relevant to your current situation.

When making an important decision, watch out for these common cognitive biases:

- Confirmation bias: Paying attention only to information that confirms your preconceptions.

- Groupthink: Adopting a belief because a significant number of people already hold that belief.

- Conservatism: Weighting evidence you are already familiar with more heavily than new evidence.

- Stereotyping: Assuming an individual will match the qualities supposedly associated with the group to which the individual belongs.

Take some time to read up on the topic, starting with this overview of well-documented cognitive biases:  “20 Cognitive Biases That Screw Up Your Decisions.”

2.7 Knowing When to Say No

The more screens or gates a project passes through, the more you learn. Eventually, what you learn about the project might lead you to conclude the project is not viable. By this point, however, people have become invested in the project. They naturally want it to succeed and are therefore unable to perceive the downsides clearly. In other words, they suffer from a cognitive bias known as groupthink, which causes people to adopt a belief because a significant number of people already hold that belief.

This problem can be exacerbated if an especially forceful or charismatic person has taken on the role of the project’s chief advocate, or project champion, in the early stages of evaluation. If the project champion then transitions into becoming the project manager, killing the project can be even harder, once the project manager becomes absorbed in the technical details and loses track of the larger organizational issues (Kerzner and Kerzner, 24).

At this point, it is often wise to appoint an exit champion, or a manager who is charged with advocating the end of a project if he or she thinks that is in the best interests of the organization, regardless of the desires of the project team members. Even if your organization doesn’t allow for an officially designated exit champion, it probably has some sort of project selection process that includes points at which a project can be killed. As a project manager, you need to understand that process, follow it carefully, and make sure everyone involved feels free to say the words “We need to kill this project.”

When deciding whether to kill a project, pay attention to the following red flags, which, according to Joni Seeber, often signal a poorly conceived project:

1. Lack of strategic fit with mission

2. Lack of stakeholder support

3. Unclear responsibility for project risks

4. Risks outweigh potential benefits

5. Unclear time component

6. Unrealistic time frame, budget, & scope

7. Unclear project requirements

8. Unattainable project requirements or insuperable constraints

9. Unclear responsibility for project outcomes (2011)

In Lesson 13, we’ll focus on auditing, the systematic evaluation of a project designed to help a team decide whether to proceed or call it quits.

~Practical Tips

- Tie every project to your organization’s strategy: Make a conscious effort to connect your organization’s strategy to every project you manage, with the goal of helping all stakeholders understand their larger purpose. For example, your organization might settle on a strategy of pursuing government contracts. This would involve learning everything about the very geometric-order world of government contracts, which requires careful adherence to the details of an RFP, and then pursuing government contracts systematically. An organization taking this approach would have a far greater chance of success than one that occasionally pursued government contracts, without making any serious attempt to learn the in’s and out’s of such work.

- Identify the decision-makers in your organization: An effective project manager understands which people in an organization actually have the influence to make a project happen and addresses the interests and concerns of those decision-makers.

- Understand your organization’s project selection process: It’s important to understand how your organization decides which projects to take on, because that’s critical to how you go about seeking approval for your project and how you present it to decision makers.

- Learn all you can about your organization’s project selection criteria: In many organizations, the criteria for project selection are not always clear and quantitative. Seek opportunities to engage with colleagues and managers who can help you better understand how and by whom decisions about project selection and continuation are made.

- Be ready to adapt to a change in strategy: Implementing an organizational strategy requires discipline and tradeoffs. Ideally, upper management monitors the effectiveness of the strategy, just as a project manager monitors a project, and makes changes when necessary. If externalities force your organization to change its strategy, you have to be ready to adapt.

- Accept that a green-lighted project could be cancelled at a later stage: A project might get a green light during the project selection process, only to be terminated later by another decision maker, who might be an officially designated exit champion, or might be someone who simply isn’t interested in the project. In either case, as always in living order, you need to be flexible and adapt.

- Be mindful of how your project ties in to related projects: The interdependence of projects can affect an organization’s portfolio strategy. One project may not have value except in relation to one or more others. Keep in mind that it may be necessary to execute all or none of a cluster of related projects.

- Be mindful of the importance of having key personnel available: Often, the biggest constraint on projects is getting key personnel assigned and working.

- Keep in mind the relationship between strategy and scope: When discussing altering the scope of a project, take some time to determine if the altered scope conflicts with your organization’s strategy. If it does, then it’s probably not a good idea.

~Summary

- Effective project management starts with selecting the right projects, managing them within a program of connected projects, and within a portfolio of all the organization’s projects and programs.

- An organization’s strategy is an expression of its unique mission in the market, setting it apart from competing organizations. Every decision about a project, program, or portfolio should support the organization’s strategy. The strategy, in turn, should define the company’s portfolio and day-to-day operations. Management must be willing to make trade-offs, pursuing some projects and declining or killing others in order to stay true to its strategy.

- According to Michael Porter, operational effectiveness—working faster, and cutting costs—is not the same as strategy. Competing on operational effectiveness alone is not viable over the long term, because competitors will always catch up (Hammonds 2001).

- Experts on strategy point out several reasons why executing a strategy is so difficult. One problem is that managers tend to think trade-offs to be signs of weakness. Organizations are also susceptible to the sunk cost fallacy, refusing to kill projects that don’t align with company strategy just because they’ve already spent money on them.

- Aligning an organization’s portfolio of projects to its overall strategy involves difficult choices about trade-offs and project selection. Organizations that lack an effective project selection process typically struggle with four major portfolio-related issues: resource balancing, prioritizing projects, making decisions about which projects to execute and which to kill, and having too many minor projects in a portfolio.

- Many models have been proposed to describe the most common project selection process, in which many ideas are evaluated, with only a few actually proceeding to project execution. Whatever project selection process your organization employs, it should focus on selecting projects that align with the organization’s strategy.

- To stay true to its strategy, an organization must be prepared to kill projects. This can be difficult, especially if the project’s chief advocate, the project champion, is forceful or has transitioned into becoming the project manager, and so is absorbed in the day-to-day details of the project.

~Glossary

- capacity—The “maximum level of output that a company can sustain to make a product or provide a service. Planning for capacity requires management to accept limitations on the production process. No system can operate at full capacity for a prolonged period; inefficiencies and delays make it impossible to reach a theoretical level of output over the long run” (Investopedia n.d.).

- exit champion—A manager who is charged with advocating the end of a project if he or she thinks that is in the best interests of the organization, regardless of the desires of the project team members.

- groupthink—A type of cognitive bias that causes people to adopt a belief because a significant number of people already hold that belief.

- operational effectiveness— Any kind of practice which allows a business or other organization to maximize the use of their inputs by developing products at a faster pace than competitors or reducing defects, for example (BusinessDictionary.com).

- portfolio optimization—The “difficult and iterative process of choosing and constantly monitoring what the organization commits to do” (Morgan, Levitt, & Malek, 2007, p. 167).

- portfolio—The “array of investments in projects and programs a company chooses to pursue” (Morgan, Levitt and Malek 2007, 3).

- program—“A cluster of interconnected projects” (Morgan, Levitt and Malek 2007, 9).

- project—The “temporary initiatives that companies put into place alongside their ongoing operations to achieve specific goals. They are clearly defined packages of work, bound by deadlines and endowed with resources including budgets, people, and facilities” (Morgan, Levitt and Malek 2007, 3).

- project champion—A project team member who serves as the project’s chief advocate, especially during the early days of planning. The project champion often becomes the project manager, but not always.

- satisfice—A term devised by Nobel Prize winning economist Herbert Simon (by combining “satisfy” and “suffice”) to describe a realistic form of decision-making, in which people accept “the ‘good-enough’ solution rather than searching indefinitely for the best solution” (Little 2011).

- set-based concurrent engineering—An approach to project selection that relies on not filtering projects too quickly, but rather developing multiple solutions through to final selection just before launch. This approach is expensive and resource-hungry, but it is argued that the costs of delay by narrowing to a single solution too soon—which subsequently turns out not to be viable (or sub-optimal)—is greater than the resources expended on multiple, parallel developments.

- strategy—According to Merriam-Webster, “a careful plan or method for achieving a particular goal usually over a long period of time.”

- sunk cost fallacy—The tendency “to continue investing in a losing proposition because of what it’s already cost” (Warrell 2015).

~References

Anthony, Scott. 2009. “Major League Innovation.” Harvard Business Review, October. https://hbr.org/2009/10/major-league-innovation.

Ballé, Michael. 2016. “Can lean support strategy as much as it does operations?” Planet Lean, February. http://planet-lean.com/can-lean-support-strategy-as-much-as-it-does-operations.

Ballé, Michael, Daniel Jones, Jacque Chaize, Orest Fiume. 2017. The Lean Strategy: Using Lean to Create Competitive Advantage, Unleash Innovation, and Deliver Sustainable Growth. New York: McGraw-Hill Education.

BusinessDictionary.com. n.d. “Operational effectiveness.” BusinessDictionary. Accessed July 29, 2018. http://www.businessdictionary.com/definition/operational-effectiveness.html

Cooper, Dr. Robert G., Dr. Scott J. Edgett, and Dr. Elko J. Kleinschmidt. 2000. “New Problems, New Solutions: Making Portfolio Management More Effective.” Research Technology Management, 43 (2).  http://www.stage-gate.net/downloads/working_papers/wp_09.pdf

Dean, Tamara. 2013. Network+ Guide to Networks, Sixth Edition. Boston: Course Technology.

El-Erian, Mohamed A. 2014. “The Secret to Southwest’s Success.” Bloomberg View, June 13. http://www.bloombergview.com/articles/2014-06-13/the-secret-to-southwest-s-success.

Foley, Ryan J. 2006. “$26 Million Software Scrapped by UW System: Officials Regret the Loss But Believe A Different Vendor Will Prove Better In the Long Run.” Wisconsin State Journal, July 6. http://host.madison.com/news/local/million-software-scrapped-by-uw-system-officials-regret-the-loss/article_d719f8a3-a718-59c6-8159-b3c27e23bf65.html.

Hammonds, Keith H. 2001. “Michael Porter’s Big Ideas.” Fast Company, February 28. https://www.fastcompany.com/42485/michael-porters-big-ideas.

Investopedia. (n.d.). Investopedia. Retrieved August 12, 2016, from http://www.investopedia.com

Kerzner, Harold, and Harold R. Kerzner. 2013. Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Hoboken: John Wiley & Sons.

Little, Daniel. 2011. “Herbert Simon’s Satisficing Life.” Understanding Society. January 30. http://understandingsociety.blogspot.com/2011/01/herbert-simons-satisficing-life.html.

Morgan, Mark, Raymond E. Levitt, and William A. Malek. 2007. Executing Your Strategy: How to Break It Down and Get It Done. Boston: Harvard Business School Publishing.

Porter, Michael E. 1996. “What is Strategy?” Harvard Business Review, November-December. https://hbr.org/1996/11/what-is-strategy.

—. 2001. “Manager’s Journal: How to Profit From a Downturn.” Wall Street Journal, Eastern edition, November 12.

Scheck, Justin. 2016. “Oil Route Forces Companies to Delay Decisions on $380 Billion in Projects.” Wall Street Journal, January 14. http://www.wsj.com/articles/oil-rout-forces-companies-to-delay-decisions-on-380-billion-in-projects-1452775590.

Seeber, Joni. 2011. “Project Selection Criteria: How to Play it Right.” International Project Management Association. http://www.ipma-usa.org/articles/SelectionCriteria.pdf.

SmartSheet. n.d. “What Is New Product Development?” SmartSheet. Accessed July 25, 2018. https://www.smartsheet.com/all-about-new-product-development-process.

Tversky, Amos, and Daniel Kahneman. 1974. “Judgment under Uncertainty: Heuristics and Biases.” Science 185 (4157): 1124-1131.

Warrell, Margie. 2015. “Sunk-Cost Bias: Is It Time To Call It Quits?” Forbes. http://www.forbes.com/sites/margiewarrell/2015/09/14/sunk-cost-bias-is-it-time-to-move-on/#129648a860ee.

1. Email message to Jeffrey Russell, January 17, 2018. ↵

3

Project Initiation, Scope, and Structure

Planning without action is futile. Action without planning is fatal.  —Anonymous

Objectives

After reading this lesson, you will be able to

- Define basic terms related to project initiation and explain how the initiation phase fits into a project’s overall life cycle

- Discuss the importance of defining “success” for a project

- Describe the elements of a project charter and explain its role in the initiation phase

- Explain issues related to project scope

- Distinguish between adaptive and technical challenges

- Explain the importance of understanding a project’s context, and the potential for that context to change as you begin the initiation process

The Big Ideas in This Lesson

- To successfully initiate a project, you need to look into the future, through the project’s entire life cycle and anticipate the many issues you might have to deal with. Only then can you clearly define what success means for your project. It’s essential to avoid a purely geometric approach to initiation, that presumes you will simply respond to changing events as they occur, rather than attempting to anticipate them.

- Of the three constraints on project management—scope, budget, and schedule—scope is the most difficult to pin down. Describing it clearly and in detail takes a lot of effort. During initiation, you need to define the project’s scope as clearly as possible, and then refine it as the project unfolds and you learn more about the project and the customer’s needs.

- The potential for changing contexts means that no two projects are the same. Even if you think you’ve completed an identical project recently, you’ll almost certainly find that externalities and differences in context will force you to alter your approach in some way or another.

3.1 Initiation and the Project Life Cycle

Physics tells us that light is both particle and wave. Project management has a similarly dual nature; it is both a series of distinct phases with a clear beginning and end, and a continuous, circular process in which each ending leads to a new beginning. Throughout a project, a successful project manager strives to anticipate changing conditions , rather than simply responding to them as they arise.

Let’s start with the more traditional view, which describes project management as a series of sequential phases, with project initiation coming right after project selection. You can think of these phases, shown in Figure 3-1, as the particle nature of project management.

Figure 3-1: Traditional view of project management

But while project initiation marks the official beginning of a project, doing it well also requires looking past the making stage to the entire life cycle of the project’s end result. You can think of this as the wave nature of project management. As illustrated in Figure 3-2,  the making stage, in which a project is initiated and executed, is one part of the larger cycle that includes the operating/using/changing stage, in which the customer makes use of the project; and the demolishing stage, when the project is retired so it can be replaced by something new and better.

Figure 3-2: To successfully initiate a project, you need to envision the entire life cycle of the project’s result (Source: John Nelson)

Taking this holistic, life-cycle view will encourage you to ask better questions about what “success” really means for your project. For example, as sustainability becomes an ever-present engineering concern, project managers often need to factor in long-term environmental effects when judging a project’s success. This entails the use of tools like life cycle assessments (LCA) for evaluating the “potential environmental impacts of a product, material, process, or activity” and for “assessing a range of environmental impacts across the full life cycle of a product system, from materials acquisition to manufacturing, use, and final disposition” (United States Environmental Protection Agency n.d.).

An LCA analysis early in the initiation phase can help to broaden your view of the potential effects of a project and to increase the range of options you consider as you set the project in motion. In the construction industry, LCAs often focus on energy and water use of a building’s life cycle. In product development, LCAs are used to assess the impacts of raw materials processing, production, packaging, and recycling, among other things. For an interesting example of an apparel industry analysis, see the following: “The Life Cycle of a Jean.”

An LCA is just one of many ways to kick-start the knowledge acquisition process that unfolds throughout a project. It’s not unusual to know little to nothing about a project at the start. By the time you finish, you know everything you wished you knew at the beginning, and you have acquired knowledge that you can carry forward to new projects. Anything you learn about a project is important, but the information you compile during initiation sets you up to respond to the living order uncertainty that will inevitably arise as the project unfolds. It can encourage you to look past the initiation phase to the project’s entire life cycle, and then to circle back using your new knowledge to take a more holistic approach to project initiation.

One of the best ways to learn about a project is to talk to everyone involved:

- Engage with the customer to learn all you can about what they want out of the project over the long term. In other words, find out how the customer defines the project’s value. Be prepared to ask lots of questions. In some situations, it might be helpful to watch the customer use a product to get a better idea of unmet needs. Keep in mind that customers don’t always know exactly what they want, and it may not have occurred to them that they can shape their thinking around the project’s life cycle. They might need the help of an informed, experienced, sensitive project manager to formulate their goals.

- Think broadly about who the customer is and include the needs of the end user—the ultimate customer—in your thinking. For example, if you are building a new clinic, don’t confine yourself to the executives of the HMO paying for the building. Take time to talk to the people who will really be using the building—doctors, nurses, technicians, administrative staff, maintenance workers, and patients.

- Talk to stakeholders—the people who will be affected by or who can affect the project—and ask about their concerns and needs. Make sure you understand their basic assumptions.

- As when identifying customers, think broadly about who the stakeholders are. The customer and end users are clearly stakeholders, as is the manager sponsoring the project, and the project team members. But don’t forget about vendors, resource owners, government officials and regulatory bodies, and members of other departments in your organization. (Jordan 2012)

Making these conversations and analyses of needs a priority will give you a broader view of your project’s overall life cycle. Though of course, in the day-to-day running of a project, you can’t spend every minute looking ahead, you do have to pay attention to the traditional phases of project management, focusing on details like schedules and personnel. Even so, as you complete the tasks related to one phase, you often need to be thinking ahead to tasks related to a subsequent phase. Significant overlap between the various phases is common, as shown in Figure 3-3. You will often need to look back at and revise the information you compiled during the initiation phase as you learn more about the project.

Figure 3-3: Even in the traditional view of project management, the phases of a project often overlap

Remember, a project is a learning acquisition activity. In most cases, what you know during project initiation is only a small fraction of what you will know when the project is finished. You have to be prepared to adapt as you learn more about your project.

3.2 The Work of Initiation

During initiation you will typically create the first draft of the following items, which take a high-level view of the project:

- project charter: A “single, consolidated source of information” (Richter 2014) for project initiation and planning. It describes your current knowledge about the project and includes information such as the names of all stakeholders, a statement of your organization’s needs, the history leading up to the project, the project’s purpose, deliverables, and roles and responsibilities. A project charter is also sometimes called a project overview statement. It may be helpful to think of the project charter as a contract between the project team and the project sponsors.

- scope statement: A document that defines the project’s scope. Defining scope, which is really the heart of the initiation phase, is discussed in detail in the next section.

- business case: An “argument, usually documented, that is intended to convince a decision maker to approve some kind of action. As a rule, a business case has to articulate a clear path to an attractive return on investment (ROI). At its simplest, a business case could be a spoken suggestion…. For more complex issues, a business case should be presented in a carefully constructed document. A business case document should examine benefits and risks involved with both taking the action and, conversely, not taking the action. The conclusion should be a compelling argument for implementation” (TechTarget n.d.). A business case addresses these fundamental questions: 1) Why this project? 2) Why this project over another project? and 3) Why this project now?

Both the project charter and the scope statement typically evolve as the project unfolds and you learn more about the project details in the planning phase. This means that as you work through the initiation phase, you should always be thinking ahead to the following elements of the planning phase:

- work breakdown structure (WBS): A description of the tasks associated with project deliverables, often in the form of a tree diagram. A work breakdown structure “displays the relationship of each task to the other tasks, to the whole and the end product (goal or objective). It shows the allocation of responsibility and identifies resources required and time available at each stage for project monitoring and management” (Business Dictionary n.d.). You can download an Excel file with a template for a work breakdown structure here: Work Breakdown Structure (WBS) Template

- organizational breakdown structure (OBS): A description of the project team. It explains “who reports to whom, the details of the hierarchy, and the reporting structure…. Organizational breakdown structures are normally communicated visually through the use of graphs or charts. A project or general manager is listed and underneath the PM several divisions might be created, such as product development, design, materials management and production” (Bradley n.d.). See also responsibility assignment matrix (RAM) below.

- work package: A “group of related tasks within a project. Because they look like projects themselves, they are often thought of as sub-projects within a larger project. Work packages are the smallest unit of work that a project can be broken down to when creating your Work Breakdown Structure (WBS)” (Wrike n.d.).

- responsibility assignment matrix (RAM): A type of organizational breakdown structure in the form of a grid that typically lists project tasks in the first column and stakeholders across the top row, with tasks assigned to the various stakeholders. You can use it to determine if you have enough resources for a project, and to record who is responsible for what. RAMs come in several forms, but one of the most useful is a responsible, accountable, consult, and inform (RACI) chart, which designates each stakeholder’s relationship to each task, using the following categories: responsible (actually does the work), accountable (has final authority over the activity), consulted (available to provide information about the activity), or informed (is informed after the activity is completed, often because his or her own work depends on it) (Doglione 2018). You can download a template for a RACI matrix here: “Responsibility Assignment Matrix.” For a brief introduction to RACI charts, see this web page: “RACI Charts.” (A RACI chart is sometimes also referred to as a linear responsibility chart.)

Avoid the Mediocrity of Idea Averaging

As you embark on the systematic learning that is the hallmark of the initiation phase, you’ll come across many ideas about the best way to achieve success. Some may be truly innovative, while others are slight variations on the same old thing. If innovation is your goal, then take care not to fall prey to idea averaging—taking a little from one idea, and a little from another, and a little from another—without fully committing to any. According to Andrew Hill, in a blog post on the topic, one way to avoid idea averaging “is to create a strong culture of feedback. Giving team members settings where they can point out flaws in current projects will help shift their mind into critical thinking mode. Feedback also gives you a tool to help measure, detect, or predict the failure of a project. In this way, the ideas you choose to act on are never set in stone, they are constantly being re-evaluated and rethought” (Hill 2016). You can read the complete blog post here: “How to Avoid Idea Averaging.”

3.3 Defining Success

Experienced project managers know that you need to start fast by defining what “success” means for your project and determining how to measure it. To accomplish this, you need talk with the individuals and organizations who will determine whether the project is a success. This may include internal or external clients, individuals or groups with approval authority, or groups of potential customers. Many projects flounder when the engineers responsible say, “We met our objective. We followed the plan as written” but the customer says, “You didn’t provide what I wanted.”

Countless products have been released and subsequently discontinued because the specifications did not match the customers’ needs. One example is the 2013 release of Facebook Home, a user interface for the Android phone that turned Facebook into the user’s home screen, removing the features, such as docks and app folders, that Android users love. How could the company make such a huge mistake? According to Business Insider, the Facebook Home development team, composed primarily of iPhone users, “was unfamiliar with the features that a normal Android user might get used to, and might not want to lose when they installed Facebook Home” (Carlson 2013). This failure to learn about the customers’ needs had disastrous results. The price of the HTC First, the phone on which Facebook Home came preinstalled, dropped from $99 to 99 cents within a few weeks (Tate 2013). Ultimately, Time magazine named the HTC First one of the “lamest moments in tech” for 2013 (McCracken 2013).

In the medical device industry, a successfully developed product might eventually be considered a failure if the development team underestimates the hurdles to achieving FDA certification. And we can look to self-driving cars for an example of how success extends beyond the narrower scope of product completion. Self-driving cars exist, but they have to be able to successfully interact with unpredictable human drivers and they need to have governmental approval in order to become a successful project.

In capital projects, the total cost of ownership (the total of direct and indirect costs related to the construction and use of a building) is crucial to determining whether or not a building is a success. For example, if a building designed for use only during the Olympics ends up being used for years afterwards, the building’s maintenance costs will probably grow exponentially, transforming a supposedly successful building into a failure over the long term from the point of view of the host city. The key is realistically projecting the building’s total design life. The cost of maintenance also plays a part in the question of whether construction funded by donors can be considered a success. In such cases, success is often defined as the facility’s “grand opening” when it should really be defined as a fully funded operational infrastructure.

Successful project managers are typically very specific when they define project success. By contrast, new project managers make the mistake of being too general. However, being specific doesn’t necessarily mean being longwinded. By focusing on the end user’s needs rather than on generating an exhaustive catalogue of physical requirements, you will provide a concise, useful definition of “success” for your project. By taking this approach, Lee Evey, the manager of the Pentagon rebuilding project after the 9/11 attack, was able to consolidate thousands of pages of specifications into “16 performance-based requirements. For example, his energy-efficiency requirement was that the building not use more than a specific number of BTUs [British Thermal Units] to heat and cool the building per year. It was then up to the design-build teams to meet the requirement within the budget” (Rife 2005).

Success in Lean and Agile

Traditional project managers tend to define success in terms of completing a project on time and within budget. But Lean presumes a more expansive definition of success—one that prioritizes eliminating waste and maximizing value, and in the process building customer loyalty that will extend to as-yet-unforeseen projects. The relentless focus on eliminating waste in the value stream has the corollary effect of keeping projects on schedule and within budget. It also tends to improve the quality of the final product, adding value that will actually benefit the customer. To learn more, see this thorough explanation of the history and usefulness of Lean in project management: “The Origins of Lean Project Management.”

In Agile development, a team agrees on its definition of intermediate success in the form of a sprint goal at every planning meeting. Success for the entire project is not measured in terms of being on time and on budget. Instead, in the spirit of the Agile manifesto, success means delivering “working software frequently”—software that the customer can actually use (Beedle et al. n.d.). Ultimately, success in Agile means delivering as much working software as the schedule and budget will allow. Agile coach Angela Johnson explains her vision of Agile success in this interesting blog post: “Defining Success Metrics for an Agile Project Methodology.”

3.4 Creating the Project Charter

Developing the project charter is one of the most important parts of project initiation. By including all key stakeholders in the process of creating it, you will help ensure agreement on what constitutes project success, relevant constraints (e.g., time and budget), and the definition of scope.

The exact form of a project charter will vary from one organization to another. At some companies, the project charter is a spreadsheet file; in others, a document file. You’ll find many templates for project charters available on the web. According to Managing Projects Large and Small: The Fundamental Skills for Delivering on Budget and on Time, a typical project charter contains some or all of the following:

- Name of project’s sponsor

- Relationship between the project’s goals and higher organizational goals

- Benefits of the project to the organization

- Expected time frame of the work

- Concise description of project deliverables (objectives)

- Budget, allocations, and resources available to the project team

- Project manager’s authority

- Sponsor’s signature (Harvard Business School Publishing Corporation 2006, 2-3)

Above all else, a project charter should be clear and specific about the project’s goals—that is, about the definition of success. The goals should be measurable, so there is no confusion about whether or not the project is a success:

Ambiguity on the goals can lead to misunderstandings, disappointment, and expensive rework. Consider this example of a broad-brush objective: “Develop a Web site that’s capable of providing fast, accurate, cost-effective product information and fulfillment to our customers.” That is how a sponsor might describe the project’s objective in the charter. But what exactly does it mean? What is “fast”? How should accuracy be defined? Is one error in 1,000 transactions acceptable, or would one error in 10,000 meet the sponsor’s expectations? To what degree must the site be cost effective? Each of those questions should be answered in consultation with the sponsor and key stakeholders. (Harvard Business School Publishing Corporation 2006, 4-5)

But while you want to be specific about the project goals, take care not to dwell on the precise details regarding how you will achieve those goals:

A thoughtful charter indicates the ends but does not specify the means. The means should be left to the project manager, team leader, and members. Doing otherwise—that is, telling the team what it should do and how to do it—would undermine any benefit derived from having recruited a competent team. (Harvard Business School Publishing Corporation 2006, 5)

Scope in Agile

Robert Merrill, a Senior Business Analyst at the University of Wisconsin-Madison, and an Agile coach, advises taking a three-part approach to scope on Agile projects, determining the following:

1. Minimum viable features—If we can’t deliver this much within schedule and budget constraints, the project should be cancelled.

2. Features we can’t think about now—Although these might be features the client wants, they are not something we can create, and so we can’t waste time and mental energy thinking about them.

3. Everything else—This is our unpredictability buffer, which we maintain to protect schedule and budget.

Note that these categories are not frozen; they can be changed during each iteration planning cycle. Scope in an Agile project is variable, but carefully and visibly managed.

3.5 Managing Project Scope

Time, cost, and scope are known as the triple constraints of project management. It’s not possible to change one without changing at least one of the others. If the project takes twice as long as expected to complete, then the cost will almost certainly go up. On the other hand, a decision to cut costs, perhaps by using less experienced labor, could lead to a work slowdown, extending the schedule. Such a decision might also result in a change to the project’s scope, perhaps in the form of a lower quality product.

The initiation phase is too early in the project to nail down precise details about time and cost, but it is a good time to think long and hard about scope, which is “all of the work that needs to be done to provide the product or service your project is delivering” (Martinez n.d.). In this early stage, you and the project stakeholders might do some blue sky thinking about what your project could possibly achieve, without regard to the constraints of time, cost, and scope. But before too long you’ll need to zero in on a definition of the project’s scope, formalizing it as a scope statement, using the information currently available to you.

Except for the simplest projects, any scope definition will almost certainly evolve as you learn more about the project and the customer’s needs. The term scope evolution refers to changes that all stakeholders agree on, and that are accompanied by corresponding changes in budget and schedule. Scope evolution is a natural result of the kind of learning that goes on as a project unfolds—for example, learning that arises from fresh insights into the needs of the end user, new regulations, or upheaval in the marketplace. As long as all stakeholders agree on the scope changes (and the associated changes to the budget and schedule), scope evolution ensures that customers actually get what they want out of the project. The more you talk with the client and learn about their needs, the more you will be able to refine the scope.

Indeed, one of the main jobs of a project manager is managing scope evolution. But different types of projects will involve varying amounts of scope evolution. For example, if you’re working on a project related to satisfying a specific environmental regulation, the initial definition of the project’s scope might be clear, requiring little refinement as the project unfolds, as long as the regulation itself is not altered. But if you are working on a product designed to satisfy a brand-new market demand, you might need to refine the scope continually to ensure that you satisfy your customers’ needs.

Perhaps the most common cause of scope evolution is a change in the context in which a project is planned and executed. Alterations in market forces, changing demographics, new or more vigorous competition, and technological advancements can all change a project’s context, forcing you to rethink its scope. This potential for changing contexts means that no two projects are the same. You might think Project B is nearly identical to Project A, but then a sudden shift in context can change everything.  As shown in Figure 3-4, context is largely defined by the organizational, social, and political structures in which a project occurs.

Figure 3-4: Context is largely defined by the organizational, social, and political structures in which a project occurs

While you need to stay open to the possibility of scope evolution, it’s essential to resist scope creep, an uncontrolled cascade of changes to the scope with no corresponding authorized changes in budget and schedule. The difference between the two is the difference between managed and unmanaged change:

Success ≠ No Changes to Project Scope

In your efforts to prevent scope creep, take care that you don’t make the mistake of equating project success with completing the project exactly as originally specified in the scope statement during the initiation phase. In the ever-changing currents of the living order, scope evolution is often necessary and desirable. As project stakeholders learn new information about the project, they will naturally make suggestions about ways to alter the original plan. But never fear—if they have a clear understanding of the definition of project success, they will be able to distinguish between scope evolution and scope creep. So as the project manager, you want to make sure everyone does in fact understand the meaning of “success.”

- Scope evolution is managed change. It is an approved alteration to the project scope that occurs as the project participants learn more about the project. It results in an official change in the project scope, and therefore to the project budget or schedule, as agreed to by all project participants. This kind of managed change is a natural and rational result of the kind of learning that goes on throughout the course of a project. It is a conscious choice necessitated by new information forcing you to reconsider project essentials in order to achieve the intended project value.

- Scope creep is unmanaged change. It is caused by uncontrolled changes to the project scope. Such changes might add value from the customer’s perspective, but the time, money, and resources consumed by the change of scope lead to additional overruns. Scope creep tends to happen bit by bit because no one is paying close attention to the project’s scope. For example, in a kitchen remodeling project intended to replace countertops and cabinets, deciding at the last minute to replace all appliances might be an example of scope creep.

Creating a Clear Scope Statement

The key to managing scope is a carefully crafted scope statement, which should be clear and precise. The details of how you plan to carry out a project may be vague at first, but want you want to achieve should be perfectly clear. Vagueness can lead to small changes to the project’s scope, which in turn lead to other changes, and so on, until the original project is no longer recognizable.

Writing a scope statement, the document that defines the project’s scope, is a major part of the initiation phase. However, according to Brad Bigelow in an article for the Project Management Institute, it is “usually expressed in qualitative terms that leave room for interpretation and misunderstanding. Consequently, it’s often the biggest source of conflicts in a project” (2012, 1).

To avoid such problems, experienced project managers put a lot of effort into learning what should and shouldn’t be included in the project, and then articulating these boundaries as clearly as possible in the form of a scope statement. According to Bigelow, this work is essential to ensuring a project’s success: “No project’s scope can ever be entirely free of fuzziness—free from subjectivity and imperfect definitions—as long as human beings are involved. On the other hand, it’s also highly improbable that any project will ever survive initiation if its scope is entirely vague, undefined, and subject to unpredictable expectations” (2).

If the scope is poorly defined, then what is or isn’t within the project scope is reduced to a matter of perspective. Not surprisingly, these “different perspectives…can often be the root of conflicts within a project” (2). Bigelow describes a project in which the team and the customer see things very differently:

A project team may, for example, propose to prepare three prototypes to refine the customer’s requirements and reduce production risks. The customer may reject this proposal as out of scope…. Because the prototypes are expendable and will not be considered finished products, the customer may refuse to consider them as deliverables. And if he perceives that prototyping delays final production and consumes resources that could be better used, he may reject the activity as outside the acceptable extent of project work. (2)

When the scope is poorly defined, satisfying the customer can grow increasingly difficult, with the team going off and creating what it thinks the customer wants, only to be told, “No, that’s not it.”

Opinions vary on exactly what a scope statement should include, but at the very least it should contain the following:

- A brief justification of the project’s purpose, including a summary of the business needs the project will address.

- An explanation of the project’s goals.

- Acceptance criteria that specify the conditions the product or service must satisfy before the customer will accept the deliverables.

- Deliverables, which are “the quantifiable goods or services that will be provided upon the completion of a project. Deliverables can be tangible or intangible parts of the development process, and they are often specified functions or characteristics of the project” (Investopedia n.d.).

- An explanation of anything excluded from the project—in other words, an explanation of what is out of scope for the project. This list should be “as detailed as is necessary to define the project boundaries to all stakeholders” (Feldsher 2016).

- Constraints, such as budget and schedule.

- Assumptions, including anything you currently believe to be true about the project. It’s also helpful to include ideas “about how you will address uncertain information as you conceive, plan, and perform your project” (Portny n.d.).

- An explanation of any new or unusual technology you plan to use throughout the project. This is not a typical part of a scope statement, but “it’s likely that stakeholders will appreciate the transparency and feel more comfortable with the project moving forward” (Feldsher 2016).

Some Practical Ideas for Working with Scope

A successful project manager is skilled at guiding customers, who simply may not know what they want until they see it. For truly innovative products, customers may not even be able to define what they want. An adage attributed to Henry Ford sums this up neatly: “If I had asked people what they wanted, they would have said faster horses.” The Sony Walkman was not created to satisfy any identified consumer demand for portable music, but in response to a request from Sony Co-founder Masaru Ibuka for a convenient way to listen to opera. A Sony designer got to work on the special request, and the result was one of Sony’s most successful products of all time (Franzen 2014).

The Agile Perspective on Scope Creep

Agile welcomes changes to product requirements even late in the development process. Indeed, the founders of Agile made an openness to late-breaking changes one of their “Principles behind the Agile Manifesto.” which you can read here: “Principles Behind the Agile Manifesto.”

In this environment of constant iterations and revisions, Agile developers have a different perspective on scope creep. A blog post for OptiSol spells out some ways to identify what is and isn’t scope creep in Agile. Making changes “before the team has started to think about the details” would not be considered scope creep in Agile, nor would replacing one feature with another, as long as the new feature doesn’t add new work for the team. However, swapping a new feature for a feature that is already complete is definitely a form of scope creep, because it creates new work. The same is true of replacing a small feature with something more complex (OptiSol n.d.). You can read the complete blog post here: “What is Scope Creep in Agile Development?”

When developers at Facebook introduced Facebook Home, they thought they were guiding their customers to a new way of using their mobile phones, just as Sony guided their customers to a new way of listening to music. But because the Facebook developers knew so little about the needs of their Android-using customers, they ended up creating a useless product. The moral of the story: before you attempt to guide your customers, make sure you understand their needs.

Here are a few other tips to keep in mind when thinking about scope:

- Engineers tend to focus too much on what they know, with little regard to what they don’t know. Take some time to think about what you know you don’t know. Then try to imagine how you would deal with the possible risks those unknowns might entail.

- Engineers tend to be highly detailed people. This can be a problem during project initiation if it compels you to map out every single detail of the project with no regard for the big picture. Of course, the details are important, but you also need to take a high-level view at the beginning. Not all details are of equal importance and the details that are important may vary over time.

- Engineers tend to focus on doing rather than thinking. They like to jump right in and starting executing a project. But remember that project initiation is your time to do some thinking first. Scope definition, in particular, is a thinking process in which you try to conceptualize what you don’t know.

- Not all project requirements are equal. They can range from “absolutely must have,” to “would like to have.” When discussing requirements with the customer, make sure you understand where each requirement fits on this scale.

- Ask the customer as many different questions as possible about the project. “By probing the customer’s requirements and expectations from as many angles as possible, a project team can significantly reduce the number of uncertain elements of project scope and reduce the potential variability of these elements. It does not guarantee that conflicts over project scope will not occur, but it can help isolate the potential sources of these conflicts” (Bigelow 2012, 4).

- The best project managers understand the importance of learning all they can about their clients’ definition of “value” and “success,” and then suggest ways to achieve those goals that go beyond what their clients might be able to envision. Such project managers focus on performance requirements and options to achieve them, and avoid locking into one approach too quickly.

- As the project progresses past initiation and into planning and execution, remember to review the project’s scope definition regularly to ensure that it is still appropriate. As the project moves forward and stakeholders learn more about it, scope changes are typically inevitable. “Indeed, the failure of a project to accommodate a change in scope can have far more serious consequences for the organization as a whole than if the change had been accepted—even if the change increased the project’s budget and extended its schedule. The ability of a project to adapt to such changes can make a crucial difference in its ultimate value to the organization. After all, the project’s objectives are subordinate to those of the organization—not vice versa. Therefore, it is crucial for the project team to understand at the very start of a project: which is more important? Avoiding change or managing it?” (Bigelow 2012, 6).

- One risk is specifying a product that has all the best features of every competitor on the market—for example, designing an industrial motor with the smallest possible footprint, highest efficiency, lowest cost, highest torque, and every accessory available at launch. Merely attempting to surpass the competition in specs prevents a team from looking for a breakthrough solution.

- Teams that successfully define project scope typically start by spending time watching customers use the relevant products or services.

3.6 From the Trenches: Michael Mucha on Sustainability and Adaptive Challenges

Michael Mucha is Chief Engineer and Director for the Madison Metropolitan Sewerage District, serves as the current Chair for ASCE’s Committee on Sustainability, and also serves on the Sustain Dane Board of Directors in Madison, Wisconsin. He explains that a project’s scope is determined by the kind of problem you’re trying to solve. Is it technical—with a clear-cut solution that engineers are traditionally trained to provide? Or is it adaptive—with no definite consensus on how to proceed, with every solution guaranteed to challenge stakeholders’ values and beliefs? Or is it a mix of both?

Sustainable engineering solutions often involve adaptive challenges. As an example, he describes a recent project:

We needed to upgrade a waste water pumping station between the Madison’s Marshall Park boat ramp and a busy bike path. Building the station itself was a technical problem. If we were working in a total vacuum, we could have built it a certain size and capacity and been done with it. But to build this pumping station in such a busy area, one that people had strong feelings about, we had to take an adaptive approach. This meant focusing on providing social benefits, such as public restrooms, two aquatic invasive species boat wash hydrants, and a bike repair station. But we also worked to educate the public about the larger importance of waste water treatment. For example, one simple way to get someone’s attention is to explain that, when you flush the toilet, the water travels to the Gulf of Mexico in 40 days. Once you know that, you might be inclined to see a pumping station as part of a larger story—a way to help protect the global environment.

In other words, the problem shifted from a technical to an adaptive challenge. Building a pumping station is very straight forward. You could spell out all the steps in a manual. That’s the technical part. But there is no manual for solving an adaptive problem. It involves changing people’s belief and values. In the case of the pumping station, we wanted to change people’s ideas about how they think about waste water, so they would see the work on the station as part of something larger. (Mucha 2017)

The distinction between adaptive and technical problems was first spelled out by Ronald A. Heifetz in his 1998 book Leadership Without Answers. For a hands-on, practical introduction to the topic, Mucha recommends The Practice of Adaptive Leadership (Heifetz, Linsky and Grashow 2009).

3.7 Project Context

The Realities of Externalities

One term closely related to context is externality. It refers to a “consequence of an economic activity that is experienced by unrelated third parties” (Investopedia n.d.). An externality can involve “a loss or gain in the welfare of one party resulting from an activity of another party, without there being any compensation for the losing party” (Business Dictionary n.d.). For example, a sudden rise in oil prices could be a devastating externality in a project that depends on a steady and economical fuel supply. Some externalities are positive—for example, Ireland’s decision to make public college education essentially free for all citizens made an already highly educated workforce even more attractive to pharmaceutical and software companies, which increased their investment in the country (Friedman 2005).

You and your project team have no control over externalities. But your job, as a project manager, is to be on the lookout for them at every turn, and to respond quickly and decisively when they do.

According to Merriam-Webster, the term context refers to “the situation in which something happens: the group of conditions that exist where and when something happens.” All projects occur within multiple contexts—within an organizational context (both yours and the customer’s), a market context, a technical context, and a social context. All of these can change over the life of a project, and in the permanent whitewater of the modern business world, they probably will. Good project managers pay attention to changing context. They realize that, as contexts change, the project will probably need to be adjusted. Completing the project in accordance with the original objectives could end up being a terrible outcome, if it turns out that the original objectives no longer fit the context of the organization.

The potential for changing contexts means that no two projects are the same. Even if you think you’ve completed an identical project recently, you’ll almost certainly find that differences in context will force you to alter your approach in some way or another. For example, the fact that you successfully built a hospital in Detroit can’t completely prepare you for the experience of building a hospital in San Francisco, where the area’s volatile seismic activity means you need to consider a host of issues related to earthquake-resistance. In product development, you might find that the customer did not fully understand their needs at the outset. As you begin to learn what the customer wants, you might see the project in a much broader, more complicated context. Likewise, the introduction of new technology can increase the complexity of a project in ways you couldn’t foresee during initiation. To deal with these changes, you need to be able to rely on a flexible project team that can adapt as the project unfolds.

An article by James Kanter in the New York Times describes the construction of two European nuclear power plants that were supposed to be “clones” of each other, with both built according to rigid standards specifying every aspect of the projects down to “the carpeting and wallpaper.” The similarity of the projects was supposed to lead to clear sailing for both, but a host of unforeseen technical problems resulted in major delays and cost overruns. This is a perfect example of how contexts—one reactor was in Finland, the other in France—can dramatically affect the outcomes of supposedly identical projects. Problems at the Finnish site included a foundation that was too porous and therefore likely to corrode, inexperienced subcontractors drilling holes in the wrong places, and communication problems arising from a workforce composed of people speaking eight different languages. At the supposedly identical French site, a different array of problems included cracks in the concrete base, incorrectly positioned steel reinforcements, and unqualified welders. According to UniStar Nuclear Energy, the company behind the Finnish and French projects, a fleet of similar reactors are in the works around the world. Who knows what risks will arise on those projects. After all, France and Finland are at least stable, geologically speaking. But as Kanter points out, “Earthquake risks in places like China and the United States or even the threat of storm surges means building these reactors will be even trickier elsewhere” (2009).

Context is especially important in product development, where the backdrop for a new product can change overnight. In a paper arguing for a more flexible approach to product development, M. Meißner and L. Blessing discuss the many ways context influences the product development process:

Designers are influenced by the society in which they live, and their decisions depend on political, social, and financial pressures. The technological environment and the accelerating rate of change is a characteristic of modern times. Changing conditions produce new needs and thereby encourage new developments, innovation is rewarded, and new artifacts are created. Some products require design activity on a far larger scale than others.

Huge one-off products such as power plants or oil platforms require an immense and skillfully organized design operation. Less complex products such as hand tools or toys can be designed by a single person…. The designer could be working in a small company, carrying a variety of responsibilities including the marketing, design, and manufacturing of the product. Or he could be working in a larger company where many people work on a single design project with specified areas of activity and a hierarchy of responsibilities. (70)

In changing contexts, flexibility is key. In his studies of successful project managers, Alexander Laufer found that the best project managers

deviate from the common “one best way” approach and adjust their practices to the specific context of their project. Avoiding the “one best way” approach does not imply, however, that there are no “wrong ways,” that “anything goes,” or that you must always “start from scratch.” There is always the need to strike a balance between relying on the accumulated knowledge of the organization, on the one hand, and enhancing the flexibility and creativity within each individual project on the other. (216)

Laufer argues that modern project managers need to employ a modern, more flexible approach than their predecessors:

The classical model of project management, in which standards are developed for virtually all situations, expects the project manager to serve primarily as a controller: to ensure that team members adhere to the established standard. This role entails only a minimal requirement for judgment and no requirement for adaptation. In reality, the project manager must constantly engage in making sense of the ambiguous and changing situation, and he must adjust the common practices to the unique situation. This process requires a great deal of interpretation and judgment based on rich experience. (218)

In Lesson 5, we’ll talk about the value of building diverse teams that bring together people with complementary skills—ideally, people of varying ages and levels of experience. But how can new project managers, who lack that all-important “rich experience,” increase their overall understanding of their projects’ multiple contexts? Start by researching past projects with similar characteristics, consulting with mentors, and, generally, checking as many formal and informal sources regarding lessons learned from previous projects as you can find. It also helps to stay well-informed—about your organization, your customers, your industry, and the world in general. For instance, if you were working on a construction project in the healthcare field in the past decade, you would have experienced a pronounced change in context, away from a doctor-centered system to a patient-centered system that seeks to empower patients to define value on their terms (Porter and Lee 2013). If you were new to managing projects in that field, you would be wise to learn all you could about that shift. In the living order, such seismic changes are the norm, not the exception, in nearly all industries.

~Practical Tips

- Engage all stakeholders: Your goal is to keep people meaningfully engaged in your project. You don’t want stakeholders showing up for ceremonial appearances at project meetings. Instead, you want them seriously focused on the prospects for project success.

- Outcome clarity: Ask your customer to define success right at the beginning. Then, working with the customer and other stakeholders, define how success will be measured.

- Use a common vocabulary: At the beginning of any project, go to your end-customers and learn their vocabulary. Make sure you understand the terms that are important to them and what such terms mean to them. Whenever possible, use your customer’s vocabulary, not yours. Also, strive to speak in plain English whenever you can, and avoid techno speak.

- Create a glossary of terms: On projects with a lot of complex jargon, consider creating a glossary of terms. Then publish it in a way that makes it accessible to all stakeholders, updating it as needed. Here’s an example of one such glossary: “COSO Framework.“

- Identify what you don’t know: When you start a project, there are always things you don’t know. The key is to know that you don’t know them. The more you strive to recognize this, the better you will be at predicting those unknowns and making provisions for them.

- Have key team members sign major project documents: Research shows that the act of signing a document makes people much more committed to delivering on the promises described in the document. Consider asking the entire project team to sign the project charter and scope documents. This simple act can serve as a powerful inducement to completing the project successfully.

- Proactive concurrency: In the early stages, avoid the trap of plotting one thing after another, in a linear fashion. Instead, start fast, doing as many things as you can concurrently, as quickly as you can. This will give you a sense of whether or not the scope, budget, resources, and schedule are all in relatively close alignment at the macro scale. If you find they are not, report that to management right away.

- Permanent urgency: In the living order in which all modern projects unfold, permanent urgency is the new law of nature. In the traditional, geometric order form of project management, you could assume that you would have sufficient time and resources to do things in a linear, step-by-step manner. But in the modern world, that’s rarely the case. Get used to an element of urgency in all projects. Try not to let this paralyze you and your team. Instead, let a sense of urgency spur you on to more agile, alert, and flexible project management techniques.

- Post the project documents prominently: Putting important documents front and center helps a team stay focused, especially if you have everyone sign them first. It also encourages the team to update them when necessary.

- Plan for errors: You and your team will almost certain make mistakes, especially in the early stages of a project. So plan for that. Keep thinking ahead to what might go wrong, and how you could correct course. Make a habit of keeping back-up plans in your back pocket.

- Define sign-off or acceptance criteria: One good way to get success defined is to start by drawing up sign-off criteria, or acceptance criteria as they are sometimes called. These are agreed-on deliverables for each key stage of the project that allows the stage to be considered complete. It’s common to link these criteria to payments. The value of these criteria being defined at the beginning is that they are usually very objective and can continually be referred back to, thus ensuring that all activities are aligned with final deliverables. Major disagreements on whether a project was a success usually come down to a failure to define acceptance criteria. Achieving agreement on this is essential, as it drives everything else (resources, time, budgets, etc.).

- Be prepared for change: Don’t be fooled into thinking that, just because you have created all the documents associated with project initiation, you have everything nailed down. It’s often not possible to foresee the kinds of ongoing changes that arise in the living order.

~Summary

- Project initiation is about laying the groundwork for the entire project. Although initiation marks the official beginning of a project, it involves looking into the future, envisioning the project’s entire life cycle, which includes the making stage, the operating/using/changing stage, and the retirement/reuse stage. Even in the more traditional way of looking at project management, the phases of project management usually overlap and often entail looking back at the documents compiled during the initiation phase.

- These documents created during initiation typically provide a high-level view of the project. They include the project charter, the scope statement, and the business case. As you create these documents, you should be thinking ahead to creating the following items during the planning phase: work breakdown structure (WBS), organizational breakdown structure (OBS), work package, and the responsibility assignment matrix (RAM).

- Experienced project managers know that you need to start fast by defining what “success” means for your project and determining how to measure it. Success means different things in different industries. For example, in capital projects, the total cost of ownership (the total of direct and indirect costs related to the construction and use of a building) is crucial to determining whether or not a building is a success. Be as specific as possible when defining success for your project, without going into needless detail. Traditional project managers tend to define success in terms of completing a project on time and within budget. But Lean presumes a more expansive definition of success—one that prioritizes eliminating waste and maximizing value, and in the process building customer loyalty that will extend to as yet unforeseen projects. In Agile, success means delivering working software after each sprint, and, ultimately, delivering as much working software as the schedule and budget will allow.

- A well-defined project charter defines the project’s goals, which in turn dictate the overall organization, schedule, personnel, and, ultimately, the work that will be accomplished.

- Of the three constraints on project management—scope, budget, and schedule—scope is the most difficult to pin down. Except for the simplest projects, any scope definition will almost certainly evolve as you learn more about the project and the customer’s needs. The term scope evolution refers to changes that all stakeholders agree on, and that are accompanied by corresponding changes in budget and schedule. Ultimately, the definition of scope is based on what the customer wants, but sometimes you’ll need to guide the customer toward a definition of the project’s scope because the customer might not know what is possible. Take the time to articulate the scope carefully in the form of a scope statement. After you create a scope statement, refer to it regularly to avoid the unauthorized changes known as scope creep.

- A project’s scope is determined by the kind of problem you’re trying to solve. Technical problems have clear-cut solutions—the kind engineers are traditionally trained to provide. With adaptive problems, things are less clear, with no definite consensus on how to proceed, and with any solution guaranteed to challenge stakeholders’ values and beliefs. Some problems are a mix of both.

- All projects occur within multiple contexts—within an organizational context (both yours and the customer’s), a market context, a technical context, and a social context. All of these can change over the life of a project, and in the permanent whitewater of the modern business world, they probably will. A project will necessarily evolve as the project’s context changes. Your job as a project manager is to be on the lookout for externalities that can affect a project’s context.

~Glossary

- business case—An “argument, usually documented, that is intended to convince a decision maker to approve some kind of action. The document itself is sometimes referred to as a business case. As a rule, a business case has to articulate a clear path to an attractive return on investment (ROI). At its simplest, a business case could be a spoken suggestion…. For more complex issues, a business case should be presented in a carefully constructed document. A business case document should examine benefits and risks involved with both taking the action and, conversely, not taking the action. The conclusion should be a compelling argument for implementation” (TechTarget n.d.).

- context—According to Merriam-Webster, the “situation in which something happens: the group of conditions that exist where and when something happens.”

- idea averaging—Taking a little from one idea, and a little from another, and a little from another—without fully committing to any.

- linear responsibility chart—See RACI chart.

- organizational breakdown structure (OBS)— A description of the project team. It explains “who reports to whom, the details of the hierarchy, and the reporting structure…. Organizational breakdown structures are normally communicated visually through the use of graphs or charts. A project or general manager is listed and underneath the PM several divisions might be created, such as product development, design, materials management, and production” (Bradley n.d.). See also responsibility assignment matrix (RAM), below.

- planning bias—The tendency to optimistically underestimate the amount of time required to complete a task.

- project charter— A “single, consolidated source of information” (Richter 2014) for project initiation and planning. It describes your current knowledge about the project and includes information such as the names of all stakeholders, a statement of your organization’s needs, the history leading up to the project, the project’s purpose, deliverables, and roles and responsibilities. A project charter is also sometimes called a project overview statement. It’s sometimes helpful to think of the project charter as a contract between the project team and the project sponsors.

- project initiation—The early phase in which you lay the groundwork for the entire project.

- project overview statement—See project charter.

- project scope—All the work “that needs to be done to provide the product or service your project is delivering” (Martinez n.d.).

- responsibility assignment matrix (RAM)—A type of organizational breakdown structure in the form of a grid that typically lists project tasks in the first column, and stakeholders across the top row, with tasks assigned to the various stakeholders. You can use it to determine if you have enough resources for a project, and to record who is responsible for what. See also RACI chart.

- RACI chart—A type of responsibility assignment (RAM) matrix. Also known as a linear responsibility chart. The name “RACI” is an acronym of “responsible, accountable, consult, and inform.”

- stakeholders—The people who will be affected by or who can affect a project.

- scope creep—Uncontrolled changes to a project that occur with no corresponding authorized changes in budget and schedule.

- scope statement—A document that defines the project’s scope (or requirements).

- work breakdown structure (WBS)—A description of the tasks associated with project deliverables, often in the form of a tree diagram. A work breakdown structure “displays the relationship of each task to the other tasks, to the whole and the end product (goal or objective). It shows the allocation of responsibility, and identifies resources required and time available at each stage for project monitoring and management” (Business Dictionary n.d.).

- work package— A “group of related tasks within a project. Because they look like projects themselves, they are often thought of as sub-projects within a larger project. Work packages are the smallest unit of work that a project can be broken down to when creating your Work Breakdown Structure (WBS)” (Wrike n.d.).

~References

Beedle, Mike, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Andrew Hunt, et al. n.d. “Principles behind the Agile Manifesto.” AgileManifesto. Accessed June 16, 2018. http://agilemanifesto.org/principles.html.

Bigelow, Brad. 2012. “Scope–Mastering the Fuzzy Constraint.” Project Management Institute. Accessed June 16, 2018. http://www.pmi.org/~/media/Members/Requirements-Management/Scope%20Mastering%20the%20Fuzzy%20ConstraintBigelow.ashx.

Bradley, Jeremy. n.d. “What Is an Organizational Breakdown Structure (OBS)?” Chron. Accessed June 16, 2018. http://smallbusiness.chron.com/organizational-breakdown-structure-obs-72523.html.

Business Dictionary. n.d. “Externalities.” BusinessDictionary. Accessed June 16, 2018. http://www.businessdictionary.com/definition/externalities.html.

—. n.d. “Work breakdown structure (WBS).” BusinessDictionary. Accessed June 16, 2018. http://www.businessdictionary.com/definition/work-breakdown-structure-WBS.html.

Carlson, Nicholas. 2013. “Facebook’s New Mobile Product Is A Huge Flop Because It Was Built By iPhone Users.” Business Insider, May 13. http://www.businessinsider.com/facebook-made-a-simple-huge-mistake-building-home-which-looks-like-a-bigger-flop-by-the-second-2013-5.

Doglione, Cara. 2018. “Understanding Responsibility Assignment Matrix (RACI Matrix).” PM. January 25. http://project-management.com/understanding-responsibility-assignment-matrix-raci-matrix/.

Feldsher, Roni. 2016. “What to include in a project scope statement.” Clarizen. July 9. https://www.clarizen.com/what-to-include-in-a-project-scope-statement/.

Franzen, Carl. 2014. “The history of the Walkman: 35 years of Iconic Music Players.” The Verge, July 1. http://www.theverge.com/2014/7/1/5861062/sony-walkman-at-35.

Friedman, Thomas L. 2005. The World is Flat: A Brief History of the Twenty-first Century. New York: Farrar, Straus and Giroux. https://books.google.com/books?id=-mv_ryTuvo0C&pg=PA418&lpg=PA418&dq=well+educated+workforce+in+Ireland+results&source=bl&ots=xgXHeV0Ozx&sig=JoHGEs28SPnl9ZgKqUcsZusucbs&hl=en&sa=X&ved=0ahUKEwj9hYvBlL_YAhVJ94MKHdStCE4Q6AEIUjAG#v=onepage&q=well%20educated%2.

Harvard Business School Publishing Corporation. 2006. Managing Projects Large and Small: The Fundamental Skills for Delivering on Budget and on Time. Boston: Harvard Business School Publishing Corporation.

Heifetz, Ronald A., Marty Linsky, and Alexander Grashow. 2009. The Practice of Adaptive Leadership: Tools and Tactics for Changing Your Organization and the World. Boston: Harvard Business Press.

Hill, Andrew. 2016. How to Avoid Idea Averaging: Let only the best ideas through. January 4. http://andrewxhill.com/blog/2016/01/04/idea-averaging/.

Investopedia. n.d. “deliverables.” Investopedia. Accessed June 15, 2018. https://www.investopedia.com/terms/d/deliverables.asp.

—. n.d. “externality.” Investopedia. Accessed June 15, 2018. https://www.investopedia.com/terms/e/externality.asp.

Jordan, Andy. 2012. “The 9 Secrets of Successful Project Initiation.” ProjectManagement.com. March. http://www.projectmanagement.com/pdf/attaskinitiation.pdf.

Kanter, James. 2009. “In Finland, Nuclear Renaissance Runs Into Trouble.” The New York Times, May 28. http://www.nytimes.com/2009/05/29/business/energy-environment/29nuke.html?_r=0.

Martinez, Michael. n.d. Project Management Scope. Accessed June 16, 2018. https://www.project-management-skills.com/project-management-scope.html.

McCracken, Harry. 2013. “This Dumb Year: The 47 Lamest Moments in Tech 2013.” Time, December 31. http://techland.time.com/2013/12/31/this-dumb-year-the-47-lamest-moments-in-tech-2013/.

Meißner, M., and L. Blessing. 2006. “Defining an Adaptive Product Development Methodology.” Proceedings of the DESIGN 2006 International Design Conference. Dubrovnik, Croatia: Design Society. 69-78.

Mucha, Michael, interview by Ann Shaffer. 2017. Technical and Adaptive Problems (December 11).

OptiSol. n.d. “What is Scope Creep in Agile Development?” Optisol Business. Accessed June 17, 2018. https://www.optisolbusiness.com/insight/what-is-scope-creep-in-agile-development.

Porter, Michael E., and Thomas Lee, MD Lee. 2013. “The Strategy That Will Fix Health Care.” Harvard Business Review, October. https://hbr.org/2013/10/the-strategy-that-will-fix-health-care.

Portny, Stanley E. n.d. “What to Include in a Project Scope Statement.” Dummies. Accessed June 15, 2018. http://www.dummies.com/careers/project-management/what-to-include-in-a-project-scope-statement/.

Richter, Linda. 2014. “What Is a Project Charter?” Bright Hub Project Management. October 24. http://www.brighthubpm.com/project-planning/5161-what-is-a-project-charter/.

Rife, Matt. 2005. “Pentagon Rebuild is Modern-Day Study in Design-Build Construction Method.” Austin Business Journal, November 13. http://www.bizjournals.com/austin/stories/2005/11/14/focus3.html.

Tate, Ryan. 2013. “Facebook Home Will be a “Huge Flop” Until It’s Not.” Wired, May 14. http://www.wired.com/2013/05/facebook-home-criticism/.

TechTarget. n.d. “business case.” WhatIs. Accessed June 16, 2018. http://whatis.techtarget.com/definition/business-case.

United States Environmental Protection Agency. n.d. Design for the Environment Life-Cycle Assessments. Accessed June 16, 2018. https://www.epa.gov/saferchoice/design-environment-life-cycle-assessments.

Wrike. n.d. “Project Management Guide/What is a Work Package in Project Management?” Wrike. Accessed June 16, 2018. https://www.wrike.com/project-management-guide/faq/what-is-a-work-package-in-project-management/.

4

Procurement

Risk comes from not knowing what you’re doing.
―Warren Buffett

Objectives

After reading this lesson, you will be able to

- Discuss issues related to supply chain management and procurement throughout an enterprise

- Explain the role of building effective client-supplier relationships in procurement, discuss issues related to procurement waste, and describe the advantages of emphasizing value over price

- Describe different types of contracts and the types of behaviors they encourage

- Give examples of how procurement issues vary from one context/domain to the next

- Discuss issues related to sustainable procurement

- List items you need to clarify when working on a proposal or contract

The Big Ideas in This Lesson

- It’s essential to think strategically about procurement to ensure your project team gets what it needs at the right time, while at the same time building productive, long-term relationships with suppliers.

- Contracts and their terms drive behavior, causing people and organizations to behave in specific ways.

- Procurement is not a one-size-fits-all process. Vital issues related to proposals and contracts vary greatly one industry to the next, with new types of partnerships emerging to suit changing needs.

4.1 Procurement’s Role in Supply Chain Management

Maintaining a healthy supply chain—that is, cultivating a network of “activities, people, entities, information, and resources” that allows a company to acquire what it needs in order to do business—is a major concern for any effective organization (Kenton 2019).  Supply chain management  encompasses

the planning and management of all activities involved in sourcing and procurement, conversion, and all logistics management activities. Importantly, it also includes coordination and collaboration with…suppliers, intermediaries, third party service providers, and customers. In essence, supply chain management integrates supply and demand management within and across companies. (Council of Supply Chain Management Professionals n.d.)

When done well, supply chain management “results in lower costs and a faster production cycle” (Kenton 2019). It is a living-order discipline focused on protecting a supply chain from the evolving threats to which it is vulnerable. For example, here are just a few recent threats to American industries:

- National and global politics: In the first half of 2019, tariffs on Chinese imports forced American companies to choose between raising prices or absorbing increased costs.

- Production shutdown at key supplier: A 2018 fire at a Michigan parts plant cut off supply of parts for Ford F-150 trucks.

- Changing government regulations: New restrictions on hazardous substances imposed by the European Union limited chemicals U.S. companies could import from the EU after 2017.

- Extreme weather events: Flooding in Thailand in 2011 shut down computer parts factories, crippling hard drive suppliers worldwide.

- Shortage of skilled manufacturing labor: Starting in 2018, American electronics suppliers found that a tight labor market meant they couldn’t produce circuit boards on schedule.

As a project manager, you will often have to focus on a core element of the supply chain—procurement. In its simplest usage, the term procurement means acquiring something, usually goods or services.  For example, as a project manager, you might might need to procure any of the following:

- Commodities: Fuel oil, computer hardware

- Services: Legal and financial services, insurance

- Expertise: Special technical know-how needed for marketing and communications, public engagement, project design and reviews, or assisting with project approvals

- Outcomes: A specified amount of thrust hours produced by a jet engine; a net reduction in energy usage generated by improving a heating system; conformance to a government regulation

In the construction field, project managers may spend a good deal of their time managing the entire procurement process, selling goods or services in some situations and purchasing goods or services in others. If that’s your situation, you might have to create proposals for the work you hope to do and then negotiate the contracts that will set the project in motion. On other projects, you might have to review proposals submitted by potential suppliers and then oversee the final contract with the selected supplier. Throughout, you’ll have to navigate the ins and outs of many relationships. By contrast, in manufacturing and product development, project managers often have little to do with procurement. In IT, project management is often closely tied to purchasing and overseeing the implementation of new software products. Whatever your procurement duties are, it’s essential to understand overall expectations and the established processes for procurement throughout your organization.

Supply Chain Management: Some History

Supply chain management is a full-blown profession, with people pursuing degrees and certificates devoted to the topic. However, in the early days of U.S. commerce, the role of purchasing the goods and services a company needed in order to conduct business was not given much thought (Inman 2015). This was true up until the late 1960s and 1970s, when the oil crisis and a worldwide shortage of raw materials forced business to recognize purchasing as a vital competitive issue. An entirely new type of management, supply chain management, was born.

4.2 Procurement from the Enterprise to the Project

Figure 4-1: Within an enterprise, procurement takes place on multiple levels

As shown in Figure 4-1, procurement takes place on multiple levels throughout an organization. At the broadest, enterprise level, the term procurement refers to everything an organization does to acquire what it needs to do business. At the project level, procurement refers to everything a project team does to acquire what it needs to complete a project. Adding to the complexity, portfolio and program managers have their own procurement needs, which sometimes conflict with the needs of other managers with the enterprise. A lack of alignment among these various needs can make success for individual projects impossible. Worse, it can sabotage the larger business goals of the entire enterprise.

Among other things, procurement includes:

- purchase planning

- standards determination

- specifications development

- supplier research and selection

- value analysis

- financing

- price negotiation

- making the purchase

- supply contract administration

- inventory control and stores

- disposals and other related functions (BusinessDictionary.com n.d.)

In an established organization, a project manager’s duties are simplified by the procurement function, which provides the organizational framework, policies, and procedures for acquiring necessary resources. (See Figure 4-2.) In startups and other less mature organizations, establishing procurement strategies to ensure the organization’s long-term well-being may not yet be a high priority. In that case, procurement may be less well defined and more focused on the project-level., with project managers left to manage resource acquisition on their own.

Figure 4-2: The enterprise procurement function provides the organizational framework, policies, and procedures for acquiring necessary resources

Project-level procurement sometimes involves getting what you need to complete the project from the project team itself.  For example, on a construction project, the team might be responsible for building kitchen cabinets. Other goods and services might be acquired from outside the project team; others from outside the organization, or from inside the organization, from other teams or departments . In some situations, procurement within the organization is a major concern for project managers. (See Figure 4-3.)

Figure 4-3: Project-level procurement takes many forms

To make good procurement choices for your projects, you need to understand where your project fits within the portfolio and the program. You also need to look at the big picture, and think strategically about procurement, both on behalf of your organization and on behalf of your project team. That means you might need to acquire a product just to maintain a foothold in a tight supply chain. For example, if you’re 75% certain that you’ll need a piece of computer hardware that is currently in short supply, you might choose to go ahead and procure it because you know that not having it when you need it will bring your project to a full stop.

Keep in mind that you can’t really think strategically about your organization’s procurement needs until you understand the logistics of procurement in your organization. Among other things, you should make sure you understand the following:

- How do you define your requirements to ensure you get what you need?

- What are the established processes?

- Who has authority to initiate, approve, and manage procurement?

- How are changes in scope handled? Who has approval authority?

4.3 Maintaining Procurement Relationships

In an ideal world, the contract resulting from a procurement process is a formal expression of a trusting relationship that already exists between two parties. Even in a less than ideal world, to achieve the best possible results, it can be helpful to think of procurement as a relationship-building process, one that can span many years. It is a form of networking that inexperienced engineers might dismiss as mere schmoozing but is in fact a means of identifying and cultivating the people and organizations who can help you complete your existing projects, develop opportunities for new ones, and advance your career over the long term. A conversation you have with a potential client at a conference might lead to a lunch six months later when you both happen to be in the same airport, which could in turn spark an idea for a new project that might only come to fruition half a decade later.

Of course, you need to balance the positive focus on building effective relationships with the need to avoid inappropriate preferences for business partners, which can lead to the unethical practices associated with nepotism, such as kickbacks, bribes, overpricing of supplies, and other unethical practices. By working to get to know potential business partners over time, you can find out if their organization’s culture and ethics, as well as their goals and needs, are a good fit for yours. As management consultant Ray Makela explains, this kind of knowledge can be vital in determining if a proposal is a good fit for your company:

Culture fit and ethics are difficult to assess in an RFP, but are one of the most important “intangibles” that can make a difference in who the organization engages with initially and who they continue to do business with in the future. Understanding the culture of the organization and demonstrating behavior that indicates ethics, collaboration, and communication can go a long way to cementing a relationship for the long term. (n.d.)

Even if you are not currently responsible for any procurement tasks, you’d be wise to get to know the people in your organization who do manage procurement. In an article for Supply Chain Management Review, Paul Mandell discusses the unexpected cost-cutting benefits of cultivating relationships within your organization: “Once you have a strong rapport with peers throughout the company, it is increasingly likely that you will gain insight into potential economies that were not otherwise obvious to you” (2016). If you lack the people skills for creating and nurturing these types of relationships, you might want to focus on improving your emotional intelligence, as discussed in Lesson 5.

Repairing Damaged Relationships

Despite your best efforts, sometimes a relationship with a trusted business partner can go awry. Economic downturns can be especially hard on customer-supplier relationships. In an article for Supply Chain Quarterly, Justin Brown gives some tips on repairing damaged procurement relationships:

Step 1: Acknowledge past mistakes

The most important part of this first step is to identify and acknowledge the mistakes that were made on both sides….  Once you have determined that the relationship is worth repairing or saving, it is time to pursue open and honest communication….

Step 2: Find the real source of the problem

The most delicate part of this process involves identifying the root cause of the problems. Bringing in a neutral third party to help both sides review the current relationship and past experiences is one way to maintain objectivity during these discussions….

Step 3: Identify and implement corrective actions

…. Observe the impact of these corrective actions on the original symptoms (the “effect”) and ensure that the resulting improvements can be objectively measured and quantified…. It’s wise to avoid subjective measurements, which may invite interpretations that lead to more disagreements and conflicts….

Step 4: Monitor and maintain the relationship

After implementing corrective actions, you’ll need to conduct management reviews in which progress is discussed, milestones are recognized, and changes to planned milestones are decided upon when necessary…. To improve the likelihood of success, ensure that there is leadership support from both customer and supplier. (2010)

The complete article, which you can read here, is filled with helpful ideas about restoring the relationships you need to keep doing business: “4 Steps to Rebuilding Customer-Supplier Relationships.”

4.4 Reducing Procurement Waste

If you’ve ever gone to the trouble of writing a proposal that ended up ignored on a manager’s desk, or negotiating a contract only to find that the relevant project was cancelled at the last minute, you’ve experienced the waste of time and effort that is often associated with procurement.  Indeed, the plague of procurement waste infects all industries. According to Victor Sanvido, former board chairman of the Lean Construction Institute, the potential for procurement waste in the construction industry alone is enormous. In a speech at the National Building Museum, he argued that procurement generates “the single biggest waste in our industry” (Dec. 4, 2013).

Unfortunately, as a report for the Project Management Institute explains, “in many business sectors the contribution of procurement is not fully realized or integrated into the strategic considerations of the business” (MacBeth et al. 2012). Procurement as a management-level profession is still relatively new, without the institutional backing and knowledge found in other management fields. Indeed, a study conducted for the Project Management Institute found that even the Institute’s own flagship publication, PMOBOK® Guide and Standards, pays woefully insufficient attention to procurement as a competitive strategy (MacBeth et al. 2012).

It’s no surprise, then, that the potential for waste in the procurement process often goes unrecognized. What sorts of things should a Lean-minded project manager look for in the procurement process? Patrick Williams, of Capgemini Consulting, discusses some common causes of waste, including:

- Contract Negotiation: How many times is the document exchanged between the supplier, legal counsel, and the contracting/sourcing agent? Are there ways to reduce these exchanges? Are these all necessary?

- Approval Processes: How are your sourcing, contracting, and purchase order approval workflows managed? Are employees routinely waiting for manager approval to process or finish work? Are there technology or policy changes that could streamline these approvals without sacrificing controls?

- Sourcing/Purchasing/Contracting: How many reviews take place on a given contract, sourcing event, or purchase order? Are all required? Can authority be tiered or increased to reduce unnecessary oversight? (2013)

The Costco Approach

Costco is a company that has thrived by cultivating long-term relationships with its suppliers, rather than focusing on extracting every last cent of profit from them. They believe they will get better quality and better service over the long-term with strong supplier relationships. An article in Retail Merchandiser explains the company’s strategy as follows: “By taking care of its vendors, Costco remains top of mind with them when new deals become available. The company values the long-term relationships it deals with as well, and any suggestions to terminate a vendor relationship require in-depth analysis” (Retail Merchandiser Magazine 2012).

As in all aspects of technical project management, success in procurement is directly dependent on a team’s ability to recognize and respond to the ever-changing circumstances of the living order. In the next two sections, we’ll look at two ways to eliminate procurement waste: collaboration and emphasizing value over price.

When companies and their suppliers stake out adversarial positions, with each seeking to claim the best possible deal over the short term, waste is inevitable. Victor Sanvido laments this type of behavior as a prime cause of procurement waste: “The owner will stop the job for three to six months to decide who they want to put on their team. They’ll make you go through a series of exercises that have no outcome on the end of the job.” As a result of these pointless exercises, he says, “90% of what is generated in procurement is thrown away” (Dec. 4, 2013).

It’s far more efficient for companies to collaborate with their potential suppliers early on in the project, soliciting their ideas on design, scheduling, manufacturing processes, logistics, and so on. This two-way conversation between company and supplier should continue long after the contracts are signed, with the goal of creating long-term alliances that benefit all parties. An article in Supply Chain Quarterly argues that establishing these types of reliable procurement alliances is essential to effective supply chain management:

Best-in-class companies work closely with suppliers long after a deal has been signed. In most circles today, this is called “supplier relationship management.” But that implies one-way communication (telling the supplier how to do it). Two-way communication, which requires both buyer and seller to jointly manage the relationship, is more effective. A more appropriate term for this best practice might be “alliance management,” with representatives from both parties working together to enhance the buyer/supplier relationship.

The four primary objectives of an effective alliance management program with key suppliers include

1. Provide a mechanism to ensure that the relationship stays healthy and vibrant

2. Create a platform for problem resolution

3. Develop continuous improvement goals with the objective of achieving value for both parties

4. Ensure that performance measurement objectives are achieved

With a sound alliance management program in place, you will be equipped to use the talents of your supply base to create sustained value while constantly seeking improvement. (Engel 2011)

The 2014 Project Management Institute Project of the Year provides an excellent example of what can be achieved by a collaborative approach to procurement. Rio Tinto Alcan Inc., a global leader in aluminum mining and production, began planning a revolutionary aluminum smelter that promised to generate 40 percent more aluminum at a lower cost and with fewer emissions than any other current technology. According to an article in PM Network, the massive project “included construction of 38 smelting pots, with an aluminum production capacity of 60,000 tons per year, a very large electrical substation, and a gas treatment center” (Jones 2014). Before the company could seriously contemplate construction, extensive research was necessary to prove that the new technology would in fact work. This research had the added benefit of illuminating the project’s potential pitfalls. It was clear that teamwork and open communication were key to avoiding them:

With more than 100 equipment suppliers and 50 installation contractors working on-site at the same time, the project team knew it needed to tackle integration and communication issues up front. Its preliminary studies showed that people had to understand the project’s strategic goals if the team wanted them to identify problems before they wreaked havoc on the schedule and the budget. (Jones 2014)

Project director Michel Charron describes his procurement strategy like this:

Before giving anyone a contract, we would meet them and explain the strategic goal we were pursuing. The hardest part was making sure they had the right attitude and would help build the culture we wanted for this project. (Jones 2014)

To help build an effective team, the project leaders “outlined clear roles and responsibilities and looked for opportunities to improve the flow of information among teams.” Charron summed up his overall philosophy: “Everybody has a little bit of the answer. You need to have the whole team working together to achieve something. So we made sure that they could have a good understanding of what others were doing” (Jones 2014).

4.5 Value over Price

One important source of waste in the procurement process is an inordinate focus on price rather than value. In the traditional, geometric order approach to proposals and contracts, price is paramount. More than anything else, sellers aim for the highest possible price for their services. In the least effective version of geometric procurement, managers look for the lowest possible price for each individual purchase. Buying incrementally at the lowest price generally results in higher overall project costs and may lead to other unintended consequences such as lower-than-expected performance. A better geometric practice is to seek the lowest total cost of ownership (TCO), which includes both direct and indirect costs associated with the product or services. (For a more complete definition of the term, see the following article: “How to Find Total Cost of Ownership (TCO) for Assets and Other Acquisitions.” The effectiveness of a TCO approach is lessened in a competitive bidding situation; ideally, you would combine TCO with an emphasis on building long-term relationships with high-quality, reliable suppliers.

The Lean, living order approach to proposals and contracts emphasizes a more expansive total cost of ownership calculation that emphasizes value over price. The benefits and overall usefulness of a product or service are considered more important than its price in dollars and cents. From the supplier’s point of view, a long-lasting relationship that allows both parties to thrive is often far more valuable than negotiating a high price in one particular situation. However, it is essential to avoid creating dependencies that inhibit healthy competition.

According to Supply Chain Management Quarterly, businesses are finally beginning to grasp the importance of emphasizing value over price:

For significant spend areas, procurement teams at best-in-class companies are abandoning the outmoded practice of receiving multiple bids and selecting a supplier simply on price. Instead, they consider many other factors that affect the total cost of ownership. This makes good sense when you consider that acquisition costs account for only 25 to 40 percent of the total cost for most products and services. The balance (and majority) of the total comprises operating, training, maintenance, warehousing, environmental, quality, and transportation costs as well as the cost to salvage the product’s value later on. (Engel 2011)

Project managers working on government-funded projects face special procurement challenges. When selecting engineering firms, governments will sometimes allow for a two-stage process, in which they first identify best-qualified engineering firms and then, from among those firms, accept the lowest-priced bid. However, government project managers are sometimes required by law or politics to accept the lowest price. If you find yourself in that situation, whether as a supplier or purchaser, consider making the case that the ultimate price of the project depends on broader, life-cycle costs, including operational and disposal costs. For example, the cost of a new parking lot doesn’t just include the initial cost of building the lot. It also includes maintenance and, eventually, demolition when the aging lot is no longer safe and useful, or when the owner finds a more profitable use for the land.

Boeing’s Procurement Nightmare

The Boeing 787 Dreamliner is a lightweight passenger jet that, thanks to its pioneering composite frame, uses 20 percent less fuel than the planes they are designed to replace. It has been “the darling of aviation enthusiasts around the world since the first version debuted in 2011. Its lightweight, fuel-saving super strong carbon fiber materials and other cutting-edge design features were touted as the future of the airline industry” (Patterson 2015). However, it’s been plagued by billions of dollars in cost overruns, production delays, and serious safety problems, including fires tied to the lithium ion batteries that are key to the plane’s vaunted energy efficiency. In 2013, a battery fire led to a worldwide grounding of all Boeing 787 Dreamliners.

Much of what went wrong with the Boeing 787 can be traced to poor procurement practices—in particular outsourcing. To save time and money, and in response to political pressures, the company set out to procure the necessary parts from many companies in many countries. (See Figure 4-4.) “Boeing enthusiastically embraced outsourcing, both locally and internationally, as a way of lowering costs and accelerating development. The approach was intended to ‘reduce the 787′s development time from six to four years and development cost from $10 to $6 billion.’ The end result was the opposite” (Denning 2013). The full story of the Boeing 787 Dreamliner debacle is long and complicated. But it all comes down to two things: a failure to collaborate and a failure to focus on value over price.

Figure 4-4: Lack of alignment among all levels of procurement can be problematic, as happened with the Boeing 787 Dreamliner

4.6 From RFP to Contract

Now let’s zero in on the portion of the procurement process that is a special focus of project managers: proposals and contracts. After an idea makes it through the project selection process and becomes a funded project, an organization typically issues a request for proposal (RFP), which is a “document that describes a project’s needs in a particular area and asks for proposed solutions (along with pricing, timing, and other details) from qualified vendors. When they’re well crafted, RFPs can introduce an organization to high-quality vendor-partners and consultants from outside their established networks and ensure that a project is completed as planned” (Peters 2011). The exact form of an RFP varies from one industry to the next and from one organization to another. But ideally, an RFP will include the items listed in Appendix 2.1 of Project Management: The Managerial Process, by Erik W. Larson and Clifford F. Gray. You can also find many templates for RFPs on the web.

In response to an RFP, other organizations submit proposals describing, in detail, their plan for executing the proposed project, including budget and schedule estimates, and a list of final deliverables. Officially, the term proposal is defined by Merriam-Webster as “something (such as a plan or suggestion) that is presented to a person or group of people to consider.” Depending on the nature of your company, this “something” might consist of little more than a few notes in an email, or it might incorporate months of research and documentation, costing hundreds of thousands of dollars to produce. When creating a proposal, you should seek to clearly understand and address your client’s needs and interests, convincingly demonstrate your ability to meet their needs (quality, schedule, price), and prepare the proposal in a form that meets requirements.

After reviewing all submitted proposals, the organization that issued the RFP accepts one of the proposals, and then proceeds with negotiating a contract with the vendor. The term contract is more narrowly defined as “an agreement with specific terms between two or more persons or entities in which there is a promise to do something in return for a valuable benefit known as consideration” (Farlex n.d.). As with proposals, however, a contract can take many forms, ranging from a submitted invoice (which can serve as a binding agreement) to several hundred pages of legal language.

Contracts and the Behaviors They Encourage

Contracts and their terms drive the behavior of everyone involved. Ideally, a contract is the expression of a trusting relationship between two parties. Such a contract should encourage stakeholders to work together to ensure overall project success and maximize value, rather than spurring stakeholders to optimize their interests. To understand how contracts can affect behavior, it helps to understand the varieties of contracts you might encounter, and the situations in which they can be useful.

The two basic varieties are fixed-price and cost-plus:

- fixed-price: An agreement in which the contractor or seller “agrees to perform all work specified in the contract at a fixed price” (Larson and Gray 2011, 451).

- cost-plus: An agreement in which the contractor or seller “is reimbursed for all direct allowable costs (materials, labor, travel) plus an additional fee to cover overhead and profit. This fee is negotiated in advance and usually involves a percentage of the total costs” (Larson and Gray 2011, 452). A similar arrangement, in which costs with overhead and profit are billed as incurred, is sometimes referred to as time and materials.

As shown in Figure 4-4, fixed price presents the greatest risk for the contractor, whereas cost-plus imposes the greatest risk on the client. However, both can be beneficial to all parties in the right situations. For example, a fixed-price contract can be beneficial to both parties if the scope is clearly defined, and the costs and schedule are predictable. But in more uncertain situations, when estimating costs is difficult, the contractor takes on the risk of agreeing to a lump-sum price that might turn out to be far too low given changing market conditions or other externalities. On the other hand, cost-plus contracts can impose an excessive risk on the client, because “the contract does not indicate what the project is going to cost until the end of the project.” Furthermore, such an arrangement imposes little “formal incentive for the contractors to control costs or finish on time because they get paid regardless of the final cost” (Larson and Gray 2011, 452).

Figure 4-5: The Contractor and client take on varying amounts of risk, depending on the type of contract

Many variations on fixed-price and cost-plus contracts have been devised to modify the risk assumed by both parties. These variations typically involve incentives and penalties that motivate the contractor to work quickly, and keep costs under control, and that allow for increases in labor and materials costs, or other expenses. For a detailed summary of contracts commonly used in project management, see this blog post: “PMP Study: Types of Contracts.”

For some real-world examples of incentives and penalties, see this list of best practices used by the U.S. Environmental Protection Agency for solid waste removal contracts: “Contracting Best Practices: Incentives and Penalties.”

When negotiating a contract, most people and organizations tend to focus on minimizing their own risk. As result, it’s easy to lose track of the project’s primary purpose: delivering value to the client. Generally speaking, contracts that promote the most equitable allocation of risk create the most value. Such contracts also tend to encourage the best possible behavior on both sides, whereas inequitable contracts tend to bring out the worst in everyone. For example, if a contractor agrees to a fixed-price contract that presumes a ready supply of inexpensive, but high-quality roofing material, only to see the price of shingles go sky-high, the contractor might be tempted to cut corners, and substitute a cheaper material.

External and Internal Contracts

In the past, RFPs, proposals, and contracts were originally used to solicit bids from external organizations, but it’s now common for one department to use RFPs, proposals, and contracts to secure help on a project from other departments in the same organization. Increasingly, organizations distinguish between external contracts—that is, contracts between an organization and external suppliers—and internal contracts—that is, memorandums of agreement between departments within an organization. Unlike an external contract, an internal contract is not designed to stand up to intense legal scrutiny and is simply a clear explanation of an agreement between two parties.

A blog post for the consulting firm NDMA explains the advantages of the inevitable back-and forth negotiation of the contracting process, which can be an opportunity for the type of communication so necessary in living order, with both parties articulating their vision of a project. This is true of both external and internal contracts:

Contracting is not a waste of time, not a bureaucratic ritual. The minutes spent working out a mutual understanding of both the customer’s and the supplier’s accountabilities at the beginning of a project can save hours of confusion, lost productivity, and stress later.

Furthermore, contracts are the basis for holding staff accountable for results. They are not wish-lists; they’re firm commitments. Staff must never agree to a contract unless they know they can deliver results.

Internal contracts also hold customers accountable for their end of the deal. For example, on an IT development project, clients may have to agree to things like providing their people time to work with the development team, negotiating rights to data with other clients, and doing acceptance testing. By agreeing on customers’ accountabilities up front, projects won’t be delayed by clients who are surprised by unexpected demands; and staff won’t be blamed if clients hold up a project. (NDMA n.d.)

A service-level agreement (SLA) is an example of a type of contract that can be external (for example, between a network service provider and its customers) or internal (for example, between an IT team and the departments for which it provides services). An SLA “documents what services the provider will furnish and defines the performance standards the provider is obligated to meet” (TechTarget n.d.). SLAs have evolved in living order as a way to create a blueprint for services in a world of rapidly changing technology:

SLAs are thought to have originated with network service providers, but are now widely used in a range of IT-related fields. Companies that establish SLAs include IT service providers, managed service providers, and cloud computing service providers. Corporate IT organizations, particularly those that have embraced IT service management (ITSM), enter SLAs with their in-house customers (users in other departments within the enterprise). An IT department creates an SLA so that its services can be measured, justified, and perhaps compared with those of outsourcing vendors. (TechTarget n.d.)

A blog post for Wired makes the case for using SLAs for any undertaking involving cloud computing, which is perhaps the ultimate living order situation, involving ever-changing technologies and huge geographical distances. A well-conceived SLA can serve as a roadmap over this bumpy terrain:

In order to survive in today’s world, one must be able to expect the unexpected as there are always new, unanticipated challenges. The only way to consistently overcome these challenges is to create a strong initial set of ground rules, and plan for exceptions from the start. Challenges can come from many fronts, such as networks, security, storage, processing power, database/software availability or even legislation or regulatory changes. As cloud customers, we operate in an environment that can span geographies, networks, and systems. It only makes sense to agree on the desired service level for your customers and measure the real results. It only makes sense to set out a plan for when things go badly, so that a minimum level of service is maintained. Businesses depend on computing systems to survive.

In some sense, the SLA sets expectations for both parties and acts as the roadmap for change in the cloud service—both expected changes and surprises. Just as any IT project would have a roadmap with clearly defined deliverables, an SLA is equally critical for working with cloud infrastructure. (Wired Insider n.d.)

The blog post goes on to list essential items to cover in an SLA. You can read the entire post here: “Service Level Agreements in the Cloud: Who Cares?”

4.7 Different Domains, Different Approaches to Procurement

Procurement is not a one-size-fits-all process. Different situations require different approaches to soliciting bids, submitting proposals, and negotiating contracts. If you’re involved in something simple, like buying a car for your personal use, you probably will want to focus almost exclusively on price and terms. You’d be wise to shop around, perhaps even traveling to another city to get the best possible deal.

When purchasing a software package for use on your personal computer, you’re probably safe taking the same approach. But if you are responsible for buying a customized software solution for a specialized project, price is often less important than ensuring that you buy from a vendor who can provide a reliable implementation of the software. That means you need to get to know the vendor, and perhaps talk to some of the vendor’s clients, to make sure you’re dealing with a company you can rely on.

In manufacturing, single-sourcing is the practice of using one supplier for a particular product. Many large manufacturers are finally coming to terms with the extreme downsides of this form of procurement, in which a single random event can bring manufacturing to a halt. For example, a fire at a seat supplier forced a Jaguar Land Rover factory, which relied entirely on that one supplier, to close for several weeks. In 2012, floods in Thailand affected 70% of the worlds hard drive manufacturing capacity (DatacenterDynamics 2011). Political events can also cut off access to an individual supplier, as can natural disasters. The problem with limited supply options is magnified when more than one organization relies on a particular supplier, as has been the case recently with airbags made by Takata, one of only three large airbag suppliers in the world (Sedgwick 2014).

Some organizations prefer to buy software or equipment from one entity, and then hire another company to get it up and running. Others subscribe to the “one throat to choke” philosophy, preferring to purchase everything from a single vendor. That way, if something goes wrong, it’s clear who’s to blame. The phrase “one throat to choke” was coined in 2000 by Scott McNealy, CEO of Sun Microsystems, as a way to sum up the benefits of a new alliance between major players in the IT world. According to Coupa Software CEO Rob Bernshteyn, the phrase “only half-jokingly referred to the intended benefit of the alliance to customers: providing accountability within multi-partner, multi-million-dollar enterprise software deployment…. It spoke to a level of customer frustration that had reached the boiling point, and having one throat to choke actually represented an improvement over the status quo.” McNealy’s statement was a sad commentary on the state of customer support in the IT world back in the late ‘90’s.

Things have improved dramatically since then in the IT world. In some situations, buying software or equipment from the same vendor that implements it might be the best approach, but in other situations, working with multiple vendors is preferable. Bernshteyn argues that the best approach to procurement focuses on how to achieve success rather than mitigating failure. When you work with multiple vendors, he argues, you have the opportunity to learn from one vendor and push other vendors to do better. Ultimately, as is so often the case with procurement, it comes down to relationships. “It might well be that one vendor is the right choice, or two or three. But the right choice is always the one where you find yourself thinking: I see the opportunity that we have together. I see how our views on the world match in some way. I see how we can work together with integrity toward a shared vision of the future. Instead of thinking about ‘one throat to choke,’ you’re thinking about more hands to shake and more backs to slap in shared victory” (2013).

In the private sector, companies are free to take risks in procurement, trying out innovative approaches, working with whatever vendors they choose, without having to explain their every move. But if you are working in the public domain, things are different. When soliciting bids or submitting proposals for government projects, you’ll have to deal with strict regulations designed to ensure transparency and minimize risk. You might be tempted to roll your eyes at what seems like a stodgy, rule-bound approach to getting things done. But public contracts are paid for with public funds, and the public does not like to have its tax dollars wasted.

A position paper from The Institute for Public Procurement makes the case for openness in public procurement:

Procurement in the public sector plays a unique role in the execution of democratic government. It is at once focused on support of its internal customers to ensure they are able to effectively achieve their unique missions while serving as stewards of the public whose tax dollars bring to life the political will of its representative governing body. The manner in which the business of procurement is conducted is a direct reflection of the government entity that the procurement department supports. In a democratic society, public awareness and understanding of government practice ensures stability and confidence in governing systems…. The manner in which government conducts itself in its business transactions directly affects public opinion and the public’s trust in its political leaders. (Institute for Public Procurement 2010)

The sums at stake in public procurement are significant—ranging between 15 to 30 percent in many countries (United Nations Office on Drugs and Crime 2013, 1). That means the public pays a high price for bribery, conflicts of interest, and other forms of corruption:

These costs arise in particular because corruption in public procurement undermines competition in the market and impedes economic development. This leads to governments paying an artificially high price for goods, services, and works because of market distortion. Various studies suggest that an average of 10-25 per cent of a public contract’s value may be lost to corruption. Applying this percentage to the total government spending for public contracts, it is clear that hundreds of billions of dollars are lost to corruption in public procurement every year. (United Nations Office on Drugs and Crime, 1)

In large infrastructure projects, especially energy and transportation projects, one well-established way to ensure an organization gets its money’s worth far into the future is a DBOM (Design, Build, Operate, Maintain) partnership, in which a private organization builds a facility, and operates it on behalf of the public for as long as 20 years. DBOM partnerships, a high-functioning variation on the one-throat-to-choke approach, have been used since the mid-1980’s to construct and operate waste-to-energy projects that transform trash into electrical power. These arrangements can span nations and multiple companies, as is the case with a recent agreement between a Swiss energy firm, Hitachi Zosen Inova, the Australian firm New Energy Corporation, an international investment firm called Tribe Infrastructure Group, and the city of Perth, Western Australia (Messenger 2017).

A more cutting-edge version of this type of partnership is DBOOM (Design, Build, Own, Operate, Maintain), which makes it possible for public or private organizations to finance and operate huge undertakings like infrastructure, energy, or transportation projects. On the public side, DBOOM has been used to finance projects like building university campuses or public utilities. On the private side, it is a good alternative for financing projects like data centers, corporate campuses, or healthcare facilities.

Such projects can be massively expensive, and face an array of risks, including fluctuating energy markets, changeable availability of resources (including trash, in the case of waste-to-energy facilities), local and national political upheavals (which can affect tax revenues), and construction problems related to new technology. DBOM and DBOOM partnerships facilitate risk-sharing, making it more likely that large-scale projects can proceed. These partnerships can be especially useful in projects that offer sustainability benefits to the public. For example, in the case of municipal waste-to-energy facilities, a DBOM partnership provides the tax advantages of municipal financing while consolidating responsibility for design, construction, and operation to a private vendor.

Certainly, new and even more creative ways to finance large-scale projects will be devised over the coming decades. As a project manager, you don’t need to keep track of every variation, especially if you work in IT or product development, where these types of partnerships likely have little to do with your day-to-day work. But it’s good to be aware that they exist because they demonstrate the vast possibilities for procurement and contracts in living order. More and more, procurement is about more than simply signing a contract and delivering a specific product or service. Procurement unfolds in the ever-changing living order, which means change is the new normal.

4.8 Sustainable Procurement

The ultimate goal of public procurement is serving the public’s needs, so it’s good news that governments have been leaders in the field of sustainable procurement, which emphasizes goods and services that minimize environmental impacts while also taking into account social considerations, such as eradicating poverty, reducing hazardous wastes, and protecting human rights (Kjöllerström 2008). This report, published by the United Nations, is an excellent introduction to the topic of sustainable procurement in the public sector: “Public Procurement as a Tool for Promoting More Sustainable Consumption and Production Patterns.”

Although sustainable procurement is primarily associated with public procurement, private organizations have made significant strides in this area as well. Motivations for going green in the private sector vary, but one recurring theme is that customers and employees see sustainable companies as more prestigious, and so are proud to be associated with them (Network for Business Sustainability 2013). Indeed, many companies are finding that recruiting top-notch employees depends on cultivating a reputation as an organization focused on sustainability. This is particularly true for millennials, who “want to work for companies that project values that align with their own,” with environmental sustainability “gaining ground as a key value for the younger generation” (Dubois 2011). This was one major motivation behind the ongoing transformation of Ford’s Dearborn, Michigan headquarters, a massive DBOOM project which you can read about here: “Ford Motor Company: Dearborn Research and Engineering Campus Central Energy Plant.”

4.9 Agile Procurement

Robert Merrill, a Senior Business Analyst at the University of Wisconsin-Madison, and an Agile coach, points out that “many procurement processes naturally follow or even mandate a negotiation-based approach that is directly at odds with the kind of living order thinking found in the Agile Manifesto, which emphasizes ‘collaboration over contract negotiation’” (pers. comm., June 15, 2018). Nevertheless, some organizations and governments are beginning to rethink their procurement processes in hopes of making them more Agile and, as a result, less costly.

One interesting example is an on-going overhaul of the State of Mississippi’s child welfare information system. After some initial missteps, the state decided to emphasize identifying and contracting with many qualified vendors on portions of the project, rather than attempting to hire a single entity to create the entire information system. A blog post published by 18F, an arm of the U.S. government’s General Services Administration, which provided guidance on the project, describes Mississippi’s new approach to an age-old software development dilemma:

Mississippi’s initial response to solving this problem was a classic waterfall approach: Spend several years gathering requirements then hire a single vendor to design and develop an entirely new system and wait several more years for them to deliver a new complete solution. According to the project team at Mississippi’s Department of Child Protection Services, this “sounds like a good option, but it takes so long to get any new functionality into the hands of our users. And our caseworkers are clamoring for new functionality.” Instead, they’re taking this opportunity to build the first Agile, modular software project taken on within Mississippi state government, and they’re starting with how they award the contracts to build it.

Once this pool of vendors is selected, instead of awarding the entire contract to a single company, Mississippi will release many smaller contracts over time for different sections of the system. This is great for Mississippi. Inspired by the Agile approach, they’ll only need to define what needs to be built next, rather than defining the entire system all up front.

This is also great for vendors. Smaller contracts mean smaller vendors can compete. Small businesses can’t manage or deliver on large multi-million dollar software development contracts, and so are often precluded from competing. But with this approach, many contracts could end up in the single-digit millions (or less!). Smaller contracts means more small businesses can compete and deliver work, resulting in a larger and more diverse pool of vendors winning contracts and helping the state.

Approaching the project in a modular, Agile fashion can be more cost effective and less risky than a monolithic undertaking. To do it, they plan to take an approach called the “encasement strategy,” under which they will replace the system slowly over time while leaving the legacy system in place. It will work like this: The old database will have an API layered on top of it and then a new interface will be built, one component at a time, without risking the loss of data or major disruptions to their workflow. Each module will be standalone with an API interface to interact with the data and the other modules. If they decide to replace a module five years from now, it won’t really impact any of the others. (Cohn and Boone 2016)

4.10 Communication 101

The Beauty of Straight Talk

One cause of procurement waste is the convoluted language used in contracts. Proponents of plain language contracts make the case for simple, straight-forward agreements that anyone with a high school education can understand. Such easy-to-read, jargon-free documents minimize disputes and shorten negotiations because the parties no longer have to spend weeks huddled with expensive lawyers, parsing paragraphs of tedious definitions and outmoded grammar. This Harvard Business Review article describes the successful implementation of plain language contracts at GE Aviation: “The Case for Plain-Language Contracts.”

Of course, all types of business documents can benefit from simplification. The less jargon, the better. If you’re not sure you can recognize jargon when you see it, the Plain English Campaign, a British organization that campaigns against “gobbledygook, jargon, and misleading public information” can help. Click this link to get started generating some gobbledygook: Gobbledygook Generator. After you read a few examples, look for and eliminate similarly meaningless prose from your own writing.

As a project manager, you might be responsible for writing RFPs for your organization’s projects, or proposals in response to RFPs publicized by other organizations. You might also be responsible for drafting parts of a contract—for example language describing the scope of work. At the very least, you will need to be conversant enough with contract terminology so that you can ensure that a contract proposed by your organization’s legal department adequately translates the project requirements into legal obligations. Whatever form they take, to be useful, RFPs, proposals, and contracts must be specific enough to define expectations for the project, yet flexible enough to allow for the inevitable learning that occurs as the project unfolds in the uncertain, living order of the modern world. All three types of documents are forms of communication that express a shared understanding of project success, with the level of detail increasing from the RFP stage to the contract.

Throughout the proposal and contract stages, it’s essential to be clear about your expectations regarding:

- Deliverables

- Schedule

- Expected level of expertise

- Price

- Expected quality

- Capacity

- Expected length of relationship (short- or long-term)

Take care to spell out:

- Performance requirements

- Basis for payment

- Process for approving and pricing changes to the project plan

- Requirements for monitoring and reporting on the project health

At minimum, a proposal should discuss:

- Scope: At the proposal stage, assume you can only define about 80% of the scope. As you proceed through the project you’ll learn more about it and be better able to define the last 20%.

- Schedule: You don’t necessarily need to commit to a specific number of days at the proposal stage, but you should convey a general understanding of the overall commitment, and whether the schedule is mission-critical. In many projects, the schedule can turn out to be somewhat arbitrary, or at least allow for more variability than you might be led to believe at first.

- Deliverables: Make it clear that you have some sense of what you are committing to, but only provide as many details as necessary.

- Cost/resources: Again, make clear that you understand the general picture, and provide only as many specifics as are helpful at the proposal stage.

- Terms: Every proposal needs a set of payment terms, so it’s clear when payments are due. Unless you include “net 30” or “net 60” to a proposal, you could find yourself in a situation in which customers refuse to part with their cash until the project is complete.

- Clarifications and exclusions: No proposal is perfect, so every proposal needs something that speaks to the specific uncertainty associated with that particular proposal. Take care to write this part of a proposal in a customer-friendly way and avoid predatory clarifications and exclusions. For example, you might include something like this: “We’ve done our best to write a complete proposal, but we have incomplete knowledge of the project at this point. We anticipate working together to clarify the following issues”—and then conclude with a list of issues.

If you are on the receiving end of a proposal, remember a potential supplier probably has far more experience than you do in its particular line of business. Keep the lines of communication open and engage with suppliers to use their expertise to help refine deliverables and other project details.

Here are a few tips to keep in mind as you work on contracts:

- Standard vs. Custom: Almost every industry has a set of contractual language that’s been tested through the courts. To the extent that you are able, use that language. With custom contract language, the likelihood that you will be forced to arbitrate or adjudicate to resolve disputes goes way up, because there’s no case law to refer to. You never really know how enforceable a custom contract is until you have to enforce it. Whenever possible, stick with standard contracts.

- Appendices: Contracts almost always have appendices spelling out details such as applicable regulations, licensing agreements, and payment schedules, just to name a few. These are typically cut and pasted from other contracts. Often the person creating a contract neglects to adequately edit the appendices to ensure that they adequately articulate the project issues. If you use contract appendices, make sure they are properly edited to clearly express the issues related to your project.

- Conflicts: Contracts often contain internal inconsistencies, which is why most contain a severability clause that says, essentially, “If something is wrong in this contract, everything else still applies.” You can help make such a clause unnecessary by asking someone to read a contract for you and repeat it back to you in plain English. This can go a long way toward clarifying who is obligated to do what, and to draw your attention to any inconsistencies within the contract.

- Predatory language: The older your organization, the more likely its contracts include language that addresses every unique and anomalous event that has ever happened in the history of your company. That language tends to accumulate in contracts and tends to be harsh. But keep in mind that the United States’ system of law does not allow you to enforce unreasonable contract terms on someone, even though they have signed the contract. Predatory language in a contract might give you comfort at the time that a supplier signs it, but if the contract is adjudicated, it may not hold up in court. Generally, in the United States, we do not use contract law as punishment. We use it as a means to arbitrate decisions.

4.11 Lean Procurement: Even the Best Sometimes Get It Wrong

More on the Risks of Single-Sourcing

You might think Toyota’s procurement debacle would have put American car manufacturers on alert. Yet in 2018, after a fire at an auto parts plant in Michigan, Ford had to halt production of the F-Series pickup at two different plants. The trucks “generate most of Ford’s profits,” and are the top-selling vehicles in the United States, so shutting down production naturally had a huge effect on Ford’s bottom line. After the fire, Joe Hinrichs, president of Ford’s global operations, said, “We have to rebuild the whole supply chain. It’s really a day-to-day, hour-to-hour situation. We have a plan developed on how to get production started back up, but it’s going to take some time to make that happen” (Naughton and Rauwald 2018).

You can read more about this single-sourcing catastrophe here: “Ford Weighs Halting F-150 Output After Supplier Fire.”

To learn about Ford’s remarkable recovery, see this article: “Ford is Resuming F-150 Pickup Production Following Supplier’s Fire.”

In retrospect, from a Lean perspective, procurement debacles like Boeing’s Dreamliner disaster might seem inevitable. In fact, procurement failures can be hard to foresee. You can probably identify smaller, unexpected procurement failures in projects you’ve worked on. And even the most Lean-enabled company of all time, Toyota, experienced procurement difficulties in the aftermath of Japan’s 2011 earthquake and tsunami. The company’s direct suppliers were not seriously affected by the disaster. However, the company was taken off guard by other procurement difficulties, as explained by Jeffrey K. Liker and Gary L. Convis in The Toyota Way to Lean Leadership:

As Toyota quickly found, many of the basic raw materials its suppliers depend on came from the northeast of Japan, near the epicenter of the disaster. Most disturbing to Toyota, it discovered they knew little about the affected companies that were suppliers to suppliers and thus not directly managed by Toyota. Toyota worked with its suppliers, made some direct visits, and put together a map of all the suppliers affected by the disaster. It found there were 500 parts that it was not able to procure just after the March 11 quake. (xx)

Toyota put its teams of engineers to work helping its vendors recover from the catastrophe by removing debris, repairing equipment, and so on. By early May, the company was unable to procure only 30 parts, a huge improvement over the 500 unavailable parts immediately after the earthquake. Still, Toyota was forced to halt a great deal of production in Japan and around the world until it resolved its procurement problems, taking a huge financial hit as a result.

In the aftermath, the company’s leaders looked inward to determine how to avoid similar problems in the future:

The problem was that the suppliers’ sources were invisible to Toyota. Some of Toyota’s suppliers were relying on a single source or two sources in the same geographic area. Toyota had to dig deeper into the supply chain to ensure that a single natural disaster could not bring global production to a halt.

But a bigger lesson was the benefit of teams working together across divisions and across regions. Throughout the world, each region needed to check in daily on the condition of parts and make decisions about priorities for building vehicles…. The daily communication and cooperation needed to deal with this severe challenge both tested the company and strengthened global cooperation. (xxvii)

Once again, we see the vital role of learning in Lean project management. As Toyota learned more about its suppliers’ suppliers, the company was able to strengthen and expand its supply chain, ensuring that all parts worked together reliably and efficiently.

~Practical Tips

The subject of procurement is vast, with best practices varying from one industry to another, and between government and private sector projects. However, as a practitioner of Lean and living order project management, you’ll want to keep the following considerations in mind no matter what type of project you are working on. This list is adapted from suggestions by Victor Sanvido (Dec. 4, 2013):

- Determine the appropriate amount of time for the whole procurement cycle: In a $150 million design and construction project, that might be 18 months. In a smaller project, 1 month might be realistic. In manufacturing, tooling—setting the factory up with the necessary machinery—could take several months.

- Set a budget for procuring the project: This budget should include the amount vendors will spend on pursuing the project.

- Determine if the project’s procurement requirements allow for best value selection: If they do, ensure that the weights assigned to the evaluation criteria reflect the project’s specific requirements.

- Seek the lowest total cost of ownership (TCO): Instead of  focusing solely on the up-front price, focus on the TCO, which includes both direct and indirect costs associated with the product or services.

- Let your team focus on what it does best: When deciding whether to procure project needs from the project team, or from outside the project team, it’s generally best to use your team’s human and financial capital for what you are best at and for things that are mission-centric. Outsource other mission-critical things at highest value.  Buy everything else, especially commodities, at lowest the price.

- Remove burdens from contracts that cause team members to prioritize their interests over the project’s interest: Ideally, contracts should allow for the movement of money across team member boundaries. If possible, they should also pool the team’s risk and profits, so that all are rewarded, or all fail.

- Pick the right people: When deciding which companies to partner with, focus on companies that have the cultures, expertise, and capacity to deliver the project. Make sure you know which individuals within each company will be responsible for delivering the project. Be prepared to build a long-term relationship.

- Learn and look to the future: Once procurement is complete, identify the products and processes you discovered during the procurement process that will offset the time spent in procurement in the future.

~Glossary

- contract—According to Merriam-webster.com, “a binding agreement between two or more persons or parties.” A contract can take many forms, ranging from a submitted invoice (which can serve as a binding agreement) to 200 pages of legal language plus appendices.

- cost-plus: An agreement in which the contractor or seller “is reimbursed for all direct allowable costs (materials, labor, travel) plus an additional fee to cover overhead and profit. This fee is negotiated in advance and usually involves a percentage of the total costs” (Larson and Gray 2011, 452). In small projects, this arrangement is sometimes referred to as time and materials.

- DBOM (Design, Build, Operate, Maintain)—A type of partnership in which a private organization builds a facility and operates it on behalf of the public for as long as 20 years. DBOM partnerships have been used since the mid-1980s to construct and operate waste-to-energy projects that transform trash into electrical power.

- DBOOM (Design, Build, Own, Operate, Maintain)—A new variation on DBOM which makes it possible for public or private organizations to finance and operate huge undertakings like infrastructure, energy, or transportation projects.

- fixed-price: An agreement in which the contractor or seller “agrees to perform all work specified in the contract at a fixed price” (Larson and Gray 2011, 451).

- procurement—The process of acquiring goods and services. Used to refer to a wide range of business activities.

- proposal—According to Merriam-webster.com, “something (such as a plan or suggestion) that is presented to a person or group of people to consider.” Depending on the nature of your company, this “something” might consist of little more than a few notes in an email, or it might incorporate months of research and documentation, costing hundreds of thousands of dollars to produce.

- request for proposal (RFP)—A “document that describes a project’s needs in a particular area and asks for proposed solutions (along with pricing, timing, and other details) from qualified vendors” (Peters 2011).

- service-level agreement (SLA)—“A contract between a service provider and its internal or external customers that documents what services the provider will furnish and defines the performance standards the provider is obligated to meet” (TechTarget n.d.). An SLA is an example of a document that can be used to codify an agreement between an organization and external vendors (that is, an external contract), or between departments within an organization (that is, an internal contract).

- single-sourcing—The practice of using one supplier for a particular product.

- supply chain management—According to the Council of Supply Chain Management Professionals, “the planning and management of all activities involved in sourcing and procurement, conversion, and all logistics management activities.”

- sustainable procurement—Procurement that emphasizes goods and services that minimize environmental impacts while also taking into account social considerations, such as eradicating poverty, reducing hazardous wastes, and protecting human rights (Kjöllerström 2008).

- total cost of ownership (TCO)—All the costs associated with owning a particular asset, throughout the lifetime of the asset.

~References

Bernshteyn, Rob. 2013. “Customer Relations, And The Faults With ‘One Throat To Choke’ Business Alliances.” Forbes.com, October 23. https://www.forbes.com/sites/groupthink/2013/10/23/customer-relations-and-the-faults-with-one-throat-to-choke-business-alliances/#6ea6fe16506a.

Brown, Justin. 2010. “4 Steps to Rebuilding Customer-Supplier Relationships.” Supply Chain Quarterly (Quarter 3). http://www.supplychainquarterly.com/topics/Procurement/scq201003supplier/.

BusinessDictionary.com. n.d. “Procurement.” BusinessDictionary.com. Accessed July 1, 2018. http://www.businessdictionary.com/definition/procurement.html.

Cohn, Zac, and Greg Boone. 2016. “Mississippi brings agile and modular techniques to child welfare system contract.” 18F. September 20. https://18f.gsa.gov/2016/09/20/mississippi-agile-modular-techniques-child-welfare-system/.

Council of Supply Chain Management Professionals. n.d. “Supply Chain Management Definitions and Glossary.” cscmp.org. Accessed July 1, 2018. https://cscmp.org/CSCMP/Educate/SCM_Definitions_and_Glossary_of_Terms/CSCMP/Educate/SCM_Definitions_and_Glossary_of_Terms.aspx?hkey=60879588-f65f-4ab5-8c4b-6878815ef921.

DatacenterDynamics. 2011. “Thai Floods Threaten Hard Disk Drive Production Lines.” DatacenterDynamics. October 31. http://www.datacenterdynamics.com/servers-storage/thai-floods-threaten-hard-disk-drive-production-lines/50970.fullarticle.

Denning, Steve. 2013. “What Went Wrong at Boeing?” Forbes, January 21. http://www.forbes.com/sites/stevedenning/2013/01/21/what-went-wrong-at-boeing/.

Dubois, Shelley. 2011. “How Going Green Can Be a Boon to Corporate Recruiters.” Fortune.com. June 2. http://fortune.com/2011/06/02/how-going-green-can-be-a-boon-to-corporate-recruiters/.

Engel, Bob. 2011. “10 Best Practices You Should Be Doing Now.” Supply Chain Quarterly (Quarter 1). http://www.supplychainquarterly.com/topics/Procurement/scq201101bestpractices/.

Farlex. n.d. “contract.” The Free Dictionary. Accessed July 1, 2018. http://legal-dictionary.thefreedictionary.com.

Harbert, Tam. 2015. “Building Relationships to Win Government Contracts: How a Houston-Based Company Found Success in Government Contracting by Creating and Nurturing Important Business Relationships.” AmericanExpress.com. January 6. https://www.americanexpress.com/us/small-business/openforum/articles/building-relationships-big-government-contracts/.

Inman, R. Anthony. 2015. “Purchasing and Procurement.” Reference for Business. June 29. http://www.referenceforbusiness.com/management/Pr-Sa/Purchasing-and-Procurement.html.

Institute for Public Procurement. 2010. “Transparency in Government; Transparency in Government Procurement.” NIGP. https://www.nigp.org/docs/default-source/New-Site/position-papers/nigpposttranspaper.pdf?sfvrsn=2.

Jones, Tegan. 2014. “2014 PMI Project of the Year Winner: Built to Scale.” PM Network, November 11: 45-51. http://www.pmnetwork-digital.com/pmnetwork/november_2014#pg45.

Kjöllerström, Mónica. 2008. “Public Procurement as a tool for promoting more Sustainable Consumption and Production patterns.” Sustainable Development Innovation Briefs. August. https://sustainabledevelopment.un.org/content/documents/no5.pdf.

Larson, Erik W., and Clifford F. Gray. 2011. Project Management: The Managerial Process, Sixth Edition. New York: McGraw-Hill Education.

Liker, Jeffrey K., and Gary L. Convis. 2012. The Toyota Way to Lean Leadership: Achieving and Sustaining Excellence Through Leadership Development. New York: McGraw-Hill.

MacBeth, Douglas, Terry Williams, Stuart Humby, and Ken James. 2012. Procurement and Supply in Projects: Misunderstood and Under-Researched. Newton Square: Project Management Institute. www.pmi.org.

Makela, Ray. n.d. “How to Partner and Build a Long-Lasting Procurement Relationship.” SalesReadinessGroup.com. Accessed July 1, 2018. https://www.salesreadinessgroup.com/blog/how-to-partner-and-build-long-lasting-procurement-relationship.

Mandell, Paul. 2016. “The 3 Relationships Procurement Executives Must Build to Support Cost Reduction Efforts.” Supply Chain Management Review, April 11. http://www.scmr.com/article/the_3_relationships_procurement_executives_must_build_to_support_cost_reduc.

Messenger, Ben. 2017. “HZI Secures Contract for 28 MW Waste to Energy Plant in Perth, Australia.” Waste Management World, February 10. https://waste-management-world.com/a/hzi-secures-contract-for-28-mw-waste-to-energy-plant-in-perth-australia.

Naughton, Keith, and Christoph Rauwald. 2018. “Ford Weighs Halting F-150 Output After Supplier Fire.” Bloomberg, May 9. https://www.bloomberg.com/news/articles/2018-05-08/ford-is-said-to-weigh-halting-f-150-output-after-supplier-fire.

NDMA. n.d. “SLAs and Internal Contracts: Forming Clear Agreements for Services and Projects, the Basis for Accountability, Teamwork, and Resource Management.” NDMA. Accessed July 1, 2018. http://ndma.com/resources/ndm13318.htm.

Network for Business Sustainability. 2013. “Three Reasons Job Seekers Prefer Sustainable Companies.” nbs.net. June 7. https://nbs.net/p/three-reasons-job-seekers-prefer-sustainable-companies-6f1780d2-0b1d-4778-aef9-20527ab78895.

Patterson, Thom. 2015. “Rehearsal for Paris Air Show.” cnn.com, June 26. http://www.cnn.com/2015/06/11/travel/boeing-dreamliner-paris-air-show-rehearsal-video/.

Peters, Chris. 2011. “An Overview of the RFP Process for Nonprofits, Charities, and Libraries: Some Basic Considerations for Each Phase of the RFP Process.” Tech Soup. May 10. http://www.techsoup.org/support/articles-and-how-tos/overview-of-the-rfp-process.

Retail Merchandiser Magazine. 2012. “Costco Wholesale.” Retail Merchandiser Magazine, January 9. http://www.retail-merchandiser.com/index.php/featured-reports/511-costco-wholesale.

Sanvido, Victor. Dec. 4, 2013. “Lean Construction Institute.” Presentation at 11th Henry C. Turner Prize for Construction Innovation, Washington, D.C. https://www.youtube.com/watch?v=yVmz_KsDE08&feature=youtu.be.

Sedgwick, David. 2014. “Airbag Inflator Shortage Plagues Industry: With Tight Capacity, 2 Years Needed for Replacements.” Auto News. November 24. http://www.autonews.com/article/20141124/OEM11/311249954/airbag-inflator-shortage-plagues-industry.

TechTarget. n.d. “service-level agreement (SLA).” SearchITChannel. WhatIs.com. Accessed June 2018. http://searchitchannel.techtarget.com/definition/service-level-agreement.

United Nations Office on Drugs and Crime. 2013. Guidebook on anti-corruption in public procurement. Vienna, Austria: United Nations. https://www.unodc.org/documents/corruption/Publications/2013/Guidebook_on_anti-corruption_in_public_procurement_and_the_management_of_public_finances.pdf.

Weele, Arjan J. van. 2010. Purchasing & Supply Chain Management: Analysis, Strategy, Planning and Practice. Hampshire, United Kingdom: Cengage.

Williams, Patrick. 2013. “Procurement Transformation Blog.” Capgemini Consulting. September 6. Accessed June 29, 2015. https://www.capgemini-consulting.com/blog/procurement-transformation-blog/2013/09/waste-not-want-not-lean-six-sigma-values-for.

Wired Insider. n.d. “Service Level Agreements in the Cloud: Who Cares?” Wired. Accessed July 1, 2018. http://www.wired.com/insights/2011/12/service-level-agreements-in-the-cloud-who-cares/.

5

Team Formation, Team Management, and Project Leadership

Leadership takes place in the living order. Management takes place in the geometric order.
—John Nelson, PE – Chief Technical Officer, Global Infrastructure Asset Management
Adjunct Professor, Civil & Environmental Engineering, University of Wisconsin-Madison

Objectives

After reading this lesson, you will be able to

- List advantages of teams and strong leadership

- Discuss the role of trust in building a team, and describe behaviors that help build trust

- List motivators and demotivators that can affect a team’s effectiveness

- Explain issues related to managing transitions on a team

- Explain the role of self-organizing teams in Agile

- Describe the advantages of diverse teams and provide some suggestions for managing them

- Discuss the special challenges of virtual teams

The Big Ideas in this Lesson

- Building trust is key to creating an effective team. Reliable promising, emotional intelligence, realistic expectations, and good communication all help team members learn to rely on each other.

- The most effective project managers focus on building collaborative teams, rather than teams that require constant direction from management.

- Teams made up of diverse members are more creative, and better at processing information and coming up with innovative solutions. Organizations with a diverse workforce are significantly more profitable than organizations a homogeneous workforce.

5.1 Teams in a Changing World

According to Jon. R. Katzenbach and Douglas K. Smith, authors of the Wisdom of Teams: Creating the High-Performance Organization, a team is a “small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable” (1993, 45).

Of course, this describes an ideal team. A real team might be quite different. You have probably suffered the pain of working on a team lacking in complementary skills, with no clear common purpose, and plagued by uncommitted members who refuse to hold themselves accountable. However, as a project manager, you need to work with the team you have, not with the team you wish you had, leading your group through the uncertainty inherent in a living order project, and encouraging collaboration at every turn.

Attributes of a good team leader:

Most important tool: ears.

Most important skills: active listening and reflection (Nelson).

The most powerful sources of uncertainty in any project are the people charged with carrying it out. What’s more, because a project is, by definition, a temporary endeavor, the team that completes it is usually temporary as well, and often must come together very quickly. These facts can exacerbate leadership challenges that are not an issue in more stable situations. Some organizations maintain standing teams that tackle a variety of projects as they arise. But even in those cases, individual team members come and go. These minor changes in personnel can hugely affect the team’s overall cohesion and effectiveness.

How can you make your team as effective as possible? For starters, it helps to feel good about being on a team in the first place. According to Katzenbach and Smith, most people either undervalue the power of teams or actually dislike them. They point to three sources for this skepticism about teams: “a lack of conviction that a team or teams can work better than other alternatives; personal styles, capabilities, and preferences that make teams risky or uncomfortable; and weak organizational performance ethics that discourage the conditions in which teams flourish” (1993, 14). But research shows that highly functioning teams are far more than the sum of their individual members:

First, they bring together complementary skills and experiences that, by definition, exceed those of any individual on the team. This broader mix of skills and know-how enables teams to respond to multifaceted challenges like innovation, quality, and customer service. Second, in jointly developing clear goals and approaches, teams establish communications that support real-time problem solving and initiative. Teams are flexible and responsive to changing event and demands…. Third, teams provide a unique social dimension that enhances the economic and administrative aspects of work…. Both the meaning of work and the effort brought to bear upon it deepen, until team performance eventually becomes its own reward. Finally, teams have more fun. This is not a trivial point because the kind of fun they have is integral to their performance. (1993, 12)

Viewed through the lens of living order, perhaps the most important thing about teams is the way they, by their very nature, encourage members to adapt to changing circumstances:

Because of their collective commitment, teams are not as threatened by change as are individuals left to fend for themselves. And, because of their flexibility and willingness to enlarge their solution space, teams offer people more room for growth and change than do groups with more narrowly defined task assignments associated with hierarchical job assignments. (1993, 13)

A Word on Risk

Joining a team—that is, fully committing yourself to a group of people with a shared goal—is always a risk. But risk can bring rewards for those willing to take a chance. Jon R. Katzenbach and Douglas K. Smith, explain that, in their studies of scores of teams, they discovered

an underlying pattern: real teams do not emerge unless the individuals on them take risks involving conflict, trust, interdependence, and hard work. Of the risks required, the most formidable involve building the trust and interdependence necessary to move from individual accountability to mutual accountability. People on real teams must trust and depend on one another— not totally or forever— but certainly with respect to the team’s purpose, performance goals, and approach. For most of us such trust and interdependence do not come easily; it must be earned and demonstrated repeatedly if it is to change behavior. (Katzenbach and Smith 1993)

5.2 Behaviors that Build Trust

Years of psychological research has demonstrated the importance of trust in building effective teams (Breuer, Hüffmeier and Hertel 2016). Because teams often need to come together in a hurry, building trust quickly among members is essential. A team of strangers who are brought together to complete a task in three months can’t draw on the wellspring of interpersonal knowledge and loyalty that might exist among people who have worked side-by-side for years. So as a team leader, you need to focus on establishing trusting relationships at the outset. Your ultimate goal is to encourage an overall sense of psychological safety, which is “a shared belief held by members of a team that the team is safe for interpersonal risk taking.” Teams that do their work under the umbrella of psychological safety are more effective, in part because they are willing to take the risks required to learn and innovate (Edmondson 1999).

Let’s look at a few important traits, techniques, and behaviors that can help you build trust and a sense of psychological safety.

Who is the “Right” Person for Your Project?

As Laufer et al. explain in their book Becoming a Project Leader, “When it comes to projects, one thing is very clear: ‘right’ does not mean ‘stars.’ Indeed, one of the primary reasons for project ‘dream teams’ to fail is ‘signing too many all-stars.’” More important than an all-star is a project team member fully committed to the project goals. Chuck Athas was one such team member. He worked for Frank Snow, the Ground System and Flight Operations Manager at NASA’s Goddard Space Flight Center. Officially listed as the project scheduler and planner, Chuck was eager to help Frank once the schedule was completed and needed less attention. “Anything that needed to be done, and he didn’t care what it was, he would attack with the same gusto and unflappable drive to succeed,” says Frank. “Whatever it took to get the job done, Chuck would do. Was there anything he couldn’t make happen? Probably something. But with Chuck on the team I felt like I could ask for Cleveland, and the next day he would show up with the deed” (Snow 2003). Chuck demonstrated a lack of ego that most all-stars don’t have. His can-do attitude is the antidote to the not-my-job thinking that can sometimes cause team cohesiveness and project completion to falter. His adherence to the project goals over his own goals made him an ideal team member (Laufer, et al. 2018).

Reliable Promising

Nothing erodes trust like a broken promise. We all know this. As Michelle Gielan explains in a blog post for Psychology Today:

When we don’t keep a promise to someone, it communicates to that person that we don’t value him or her. We have chosen to put something else ahead of our commitment. Even when we break small promises, others learn that they cannot count on us. Tiny fissures develop in our relationships marked by broken promises. (2010)

Unfortunately, in fast-moving, highly technical projects, breaking ordinary, everyday promises is inevitable. In living order, it’s just not possible to foresee every eventuality, so the task at the top of today’s To Do list, the one you promised to complete before lunch, might get swept aside in the flood of new tasks associated with a sudden crisis.

Keeping Track of Reliable Promises

It’s helpful to keep a reliable promise log in a spreadsheet. On a big project, you might have 15-20 reliable promises logged at any one time. At every meeting, open the log and go through the reliable promises to find out which were met and which weren’t. Record a success rate in the log for each person. If you craft the promises correctly, this is an extremely helpful metric on team functionality and performance. A success rate of 70% is marginal. The mid- to high ’80s is good. The low ’90s is very good. A success rate above that means someone’s not telling the truth.

That’s why it’s important to distinguish between an ordinary promise, and a reliable promise. In Lean terminology, a reliable promise is an official commitment to complete a task by an agreed-upon time. In order to make a reliable promise, you need to have:

- Authority: You are responsible and accountable for the task.

- Competence: You have the knowledge to properly assess the situation, or you have the ability to engage someone who can advise you.

- Capacity: You have a thorough understanding of your current commitments and are saying “Yes” because you are confident that you can take on an additional task, not because you want to please the team or the team leader.

- Honesty: You sincerely commit to complete the task, with the understanding that if you fail, other people on your team will be unable to complete their work.

- Willingness to correct: After making a reliable promise, if you miss the completion date, then you must immediately inform your team and explain how you plan to resolve the situation.(Nelson, Motivators and Demotivators for Teams 2017)

Not every situation calls for an official, reliable promise. John Nelson estimates that, on most projects, no more than 10 to 20 percent of promises are so important that they require a reliable promise (2019). As Hal Macomber explains in a white paper for Lean Project Consulting, you should save reliable promises for tasks that must be completed so that other work can proceed. And keep in mind that you’ll get the best results from reliable promises if they are made in a group setting, where other teammates can chime in with ideas on how to complete the task efficiently or suggest alternatives to the proposed task. Finally, remember that people tend to feel a more positive sense of commitment to a promise if they understand that they have the freedom to say no:

A sincere “no” is usually better than a half-hearted “ok.” You know exactly what to do with the no—ask someone else. What do you do with a half-hearted “ok?” You can worry, or investigate, or not have time to investigate and then worry about that. Make it your practice to remove fear from promising conversations. (2010)

You can read Hal Macomber’s helpful introduction to reliable promising here: “Securing Reliable Promises on Projects: A Guide to Developing a New Practice.”

The practice of reliable promising was developed as a way to keep Lean projects unfolding efficiently in unpredictable environments. Ultimately, reliable promises are an expression of respect for people, which, as discussed in Lesson 1, is one of the six main principles of Lean. They encourage collaboration and help build relationships among team members. In Agile, the commitments made in every Scrum are another version of reliable promises. And the sincere commitment offered by a reliable promise can be useful in any kind of project. Here are some examples of situations in which reliable promising could be effective:

- For a product development project, when will an important safety test will be completed?

- For a medical technology project, will a report required to seek regulatory approval be completed on time?

- For an IT project, will the procurement team execute a renewal contract for the maintenance agreement before the current agreement expires? If not, the organization risks having no vendor to support an essential software component.

Using Emotional Intelligence

As a manager of technical projects, you might be inclined to think that, as long as you have the technical details under control, you have the whole project under control. But if you do any reading at all in the extensive literature on leadership, you’ll find that one characteristic is crucial to building trusting relationships with other people: emotional intelligence, or the ability to recognize your own feelings and the feelings of others.

High emotional intelligence is the hallmark of a mature, responsible, trustworthy person. In fact, a great deal of new research suggests that skills associated with emotional intelligence—“attributes like self-restraint, persistence, and self-awareness—might actually be better predictors of a person’s life trajectory than standard academic measures” (Kahn 2013). An article in the Financial Post discusses numerous studies that have tied high emotional intelligence to success at work:

A recent study, published in the Journal of Organizational Behavior, by Ernest O’Boyle Jr. at Virginia Commonwealth University, concludes that emotional intelligence is the strongest predictor of job performance. Numerous other studies have shown that high emotional intelligence boosts career success. For example, the U.S. Air Force found that the most successful recruiters scored significantly higher on the emotional intelligence competencies of empathy and self-awareness. An analysis of more than 300 top level executives from 15 global companies showed that six emotional competencies distinguished the stars from the average. In a large beverage firm, using standard methods to hire division presidents, 50% left within two years, mostly because of poor performance. When the firms started selecting based on emotional competencies, only 6% left and they performed in the top third of executive ranks. Research by the Center for Creative Leadership has found the primary cause of executive derailment involves deficits in emotional competence. (Williams 2014)

According to Daniel Goleman, author of the influential book Emotional Intelligence: Why It Can Matter More Than IQ, it’s well established that “people who are emotionally adept—who know and manage their own feelings well, and who read and deal effectively with other people’s feelings—are at an advantage in any domain of life, whether romance and intimate relationships or picking up the unspoken rules that govern success in organizational politics” (1995, 36). In all areas of life, he argues, low emotional intelligence increases the chance that you will make decisions that you think are rational, but that are in fact irrational, because they are based on unrecognized emotion. And nothing erodes trust like a leader who imposes irrational decisions on a team.

To keep your team working smoothly, make regular use of these important words:

- I’m not sure.

- What do you think?

- I don’t know.

- Please.

- Thank you.

- I was wrong. You were right.

- Good job!

Some people are born with high emotional intelligence. Others can cultivate it by developing qualities and skills associated with emotional intelligence, such as self-awareness, self-control, self-motivation, and relationship skills. Of course, it’s no surprise that these are also useful for anyone working on a team. Treating others the way they want to want to be treated—not how you want to be treated—is a sign of a mature leader, and something that is only possible for people who have cultivated the emotional intelligence required to understand what other people want.

The following resources offer more information about emotional intelligence:

- To find out where you fit on the emotional intelligence scale, try this Harvard Business Review quiz: “Quiz Yourself: Do You Lead With Emotional Intelligence?”

- This helpful video breaks down emotional intelligence into five components, as defined by Daniel Goleman, and makes suggestions on how to up your own emotional intelligence quotient: “The Explainer: Emotional Intelligence.”

- Daniel Goleman’s five components are summarized at the end of this article: “Best Practice Report: Workplace Conflict Resolution.”

- In job interviews, employers are increasingly asking questions designed to gauge an applicant’s level of emotional intelligence. This article by Alison Doyle provides sample questions: “Interview Questions About Your Emotional Intelligence.”

Cultivating a Realistic Outlook

You might have had experience with an overly negative project manager who derailed a project with constant predictions of doom and gloom. But in fact, the more common enemy of project success is too much positivity, in which natural human optimism blinds team members to reality. That’s a sure-fire way to destroy painstakingly built bridges of trust between team members. In her book Bright-Sided: How Positive Thinking is Undermining America, social critic Barbara Ehrenrich explains the downside of excessive optimism, which, she argues, is a special failing of American businesses (2009). The optimist clings to the belief that everything will turn out fine, even when the facts indicate otherwise, and so fails to prepare for reality. The optimist also has a tendency to blame the victims of unfortunate events: “If only they’d had a more positive attitude in the first place, nothing bad would have happened.”

In the planning phase, an overly optimistic project manager can make it difficult for team members to voice their realistic concerns. In a widely cited article in the Harvard Business Review, psychologist Gary Klein argues that projects fail at a “spectacular rate,” in part because “too many people are reluctant to speak up about their reservations during the all-important planning phase.” To counteract this effect, Klein pioneered the idea of a troubleshooting session—which he calls a premortem—early on in a project in which people who understand the project but are concerned about its potential for failure feel free to express their thoughts. This widely used technique encourages stakeholders to look to the future and analyze the completed project as if it were already known to be a total failure:

A premortem is the imaginary converse of an autopsy; the hindsight this intelligence assessment offers is prospective. In sum, tasking a team to imagine that its plan has already been implemented and failed miserably increases the ability of its members to correctly identify reasons for negative future outcomes. This is because taking a team out of the context of defending its plan and shielding it from flaws opens new perspectives from which the team can actively search for faults. Despite its original high level of confidence, a team can then candidly identify multiple explanations for failure, possibilities that were not mentioned let alone considered when the team initially proposed then developed the plan. The expected outcomes of such stress-testing are increased appreciation of the uncertainties inherent in any projection of the future and identification of markers that, if incorporated in the team’s design and monitoring framework and subsequently tracked, would give early warning that progress is not being achieved as expected. (Serrat 2012)

Communicating Clearly, Sometimes Using Stories

Reliable promises, emotional intelligence, and a realistic outlook are all meaningless as trust-building tools if you don’t have the skills to communicate with your team members. In his book Mastering the Leadership Role in Project Management, Alexander Laufer explains the vital importance of team communication:

Because a project functions as an ad hoc temporary and evolving organization, composed of people affiliated with different organizations, communication serves as the glue that binds together all parts of the organization. When the project suffers from high uncertainty, the role played by project communication is even more crucial. (2012, 230)

Unfortunately, many people think they are better communicators than they actually are. Sometimes a person will excel at one form of communication but fail at others. For instance, someone might be great at small talk before a meeting but continually confuse co-workers with poorly written emails.

This is one area where getting feedback from your co-workers can be especially helpful. Another option is taking a class, or at the very least, consulting the numerous online guides to developing effective communication skills. To help you get started, here are a few quick resources for improving vital communication skills:

- Making small talk—People often say they dislike small talk, but polite conversation on unimportant matters is the lubricant that keeps the social gears moving, minimizing friction, and making it possible for people to join forces on important matters. If you’re bad at small talk, then put some time into learning how to improve; you’ll get better with practice. There’s no better way to put people at ease. This article includes a few helpful tips: “An Introvert’s Guide to Small Talk: Eight Painless Tips.”

- Writing good emails—An ideal email is clear, brief, calm, and professional. Avoid jokes, because you can never be certain how team members (especially team members in other countries) will interpret them. A good emailer also understands the social rules that apply to email exchanges, as explained here: “The Art of the Effective Business Email.”

- Talking one-on-one—Nothing beats a face-to-face conversation for building trust and encouraging an efficient exchange of ideas, as long as both participants feel comfortable. In fact, Alexander Laufer suggests using face-to-face conversation as the primary communication mode for your team (2012, 230). As a team leader, it’s your job to be aware of the many ways conversations can go awry, particularly when subordinates fear speaking their mind. This excellent introduction to the art of conversation includes tips for recognizing signs of discomfort in others: “The Art of Conversation: How to Improve Face-to-Face Communication in a Digital World.”

Telling stories is an especially helpful way to share experiences with your team. Indeed, stories are “a form of communication that has been used to entertain, persuade, inspire, impart wisdom, and teach for thousands of years. This wide range of uses is due to a story’s remarkable effect on human emotion, experience, and cognition” (Kerby, DeKorver and Cantor 2018).

You’ve probably experienced the way people lower their defenses when they realize they are hearing a tale about specific characters, with an uncertain outcome, rather than a simple recitation of events, or worse, a lecture. Master storytellers seem to do it effortlessly, but in fact they usually shape their stories around the same basic template. Holly Walter Kerby, executive director of Fusion Science Theater, and a long-time science educator, describes the essential story elements as follows:

- A main character your audience can identify with—Include enough details to allow your audience to feel a connection with the main character, and don’t be afraid to make yourself the protagonist of your own stories.

- A specific challenge—Set up the ending of the story by describing a problem encountered by the main character. This will raise a question in the minds of the audience members and make them want to listen to the rest of the story to find out what happens.

- Can Sam and Danielle recover from a supplier’s bankruptcy and figure out how to get three hundred light fixtures delivered to a new office building in time for the grand opening?

- Can Hala, a mere intern, prevent seasoned contractors from using an inferior grade of concrete?[1]

- Three to five events related by cause and effect—The events should build on each other, and show the characters learning something along the way. Describe the events in a way that helps build a sense of tension.

- One or two physical details—People tend to remember specific physical details. Including one or two is a surprisingly effective way to make an entire story more memorable.

- The first new vendor Sam and Danielle contacted agreed to sell them all the light fixtures they needed, but ended up sending only one fixture in a beaten-up box with the corners bashed in.

- Hala, a small person, had to wear an oversized helmet and vest on the job site, which emphasized that she was younger and less experienced than the contractors.

- An outcome that answers the question— The outcome should be simple and easy to understand. Most importantly, it should answer the question posed at the beginning of the story.

- Yes—by collaborating with a new supplier, Sam and Danielle were able to acquire the light fixtures in time for the grand opening.

- No—Hala could not stop the contractors from using inferior concrete, but she did report the problem to her boss, who immediately halted construction until the concrete could be tested, and, in the end, replaced.

- Satisfying Ending—Explain how the events in the story led to some kind of change in the characters’ world.

- Sam and Danielle learned to focus on building relationships with reliable, financially stable vendors.

- Hala learned that even an intern can safeguard a project by speaking up when she sees something wrong.

Keep in mind that in some high-stakes situations, the last thing you want is more tension. In that case, you want the opposite of a story—a straightforward recitation of the facts. For example, when confronting a team member about poor work habits, or negotiating with an unhappy client, it’s best to keep everything simple. Draining the drama from a situation helps everyone stay focused on the facts, keeping resentment and other negative emotions to a minimum (Manning 2018, 64). For more on good techniques for difficult conversations, see Trevor Manning’s book Help! I need to Master Critical Conversations.

[1] Thanks to Hala Nassereddine for sharing her story of her experience as an intern on a construction site in Beirut, Lebanon.

The Beauty of Face-to-Face Communication

As Laufer et al. point out in their book Becoming a Project Leader, “In contrast to interactions through other media that are largely sequential, face-to-face interaction makes it possible for two people to send and receive messages almost simultaneously. Furthermore, the structure of face-to-face interaction offers a valuable opportunity for interruption, repair, feedback, and learning that is virtually instantaneous. By seeing how others are responding to a verbal message even before it is complete, the speaker can alter it midstream in order to clarify it. The immediate feedback in face-to-face communication allows understanding to be checked, and interpretation to be corrected. Additionally, face-to-face communication captures the full spectrum of human interaction, allowing multiple cues to be observed simultaneously. It covers all the senses—sight, hearing, smell, taste, and touch—that provide the channels through which individuals receive information” (2018).

Certainly, in today’s world of project management, in which distributed digital teams are becoming common practice, it may be impossible to sit down in the same room with all team members. But as much as possible, project managers should push for using technology that allows a fuller communication environment—one in which interactions are not just isolated to text. For more, see “The Place of Face-to-Face Communication in Distributed Work” by Bonnie A. Nardi and Steve Whittaker.”

5.3 Team Motivators and Demotivators

To build believable performances, actors start by figuring out their characters’ motivations—their reasons for doing what they do. As a team leader, you can use the same line of thinking to better understand your team members. Start by asking this question: Why do your team members do what they do? Most people work because they have to, of course. But their contributions to a team are motivated by issues that go way beyond the economic pressures of holding onto a job.

In their book The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work, Teresa Amabile and Steven Kramer argue that the most important motivator for any team is making meaningful daily progress toward an important goal. In their study of 12,000 daily journal entries from team members in a variety of organizations and industries, they found that a sense of accomplishment does more to encourage teamwork, on-the-job happiness, and creativity than anything else. “Even when progress happens in small steps,” the researchers explain, “a person’s sense of steady forward movement toward an important goal can make all the difference between a great day and a terrible one” (2011, 77).

According to Amabile and Kramer, the best managers focus on facilitating progress by removing roadblocks and freeing people up to focus on work that matters:

When you do what it takes to facilitate progress in work people care about, managing them—and managing the organization—becomes much more straightforward. You don’t need to parse people’s psyches or tinker with their incentives, because helping them succeed at making a difference virtually guarantees good inner work life and strong performance. It’s more cost-effective than relying on massive incentives, too. When you don’t manage for progress, no amount of emotional intelligence or incentive planning will save the day (2011, 10).

As you might expect, setbacks on a project can have the opposite effect, draining ambition and creativity from a team that, only days before, was charging full steam ahead toward its goal. But setbacks can be counterbalanced by even small wins—“seemingly minor progress events”—which have a surprising power to lift a team’s spirits, making them eager to get back to work the next day (2011, 80). You’ve probably experienced the pleasure that comes from checking at least one task off your to-do list. Even completing a small task can generate a sense of forward momentum that can propel a team toward larger achievements.

Amabile and Kramer’s book is a great resource for team managers looking to improve their motivational abilities. If you don’t have time to read the whole book, they summarize their research and advice in this Harvard Business Review article: The Power of “The Power of Small Wins.”

Through years of practical experience as an executive, consultant, project engineer, and project manager, John Nelson has gained a finely honed understanding of how to manage teams. According to Nelson, the following are essential for motivators for any team:

- A sense of purpose—Individually, and as a whole, a team needs an overarching sense of purpose and meaning. This sense of purpose should go beyond each individual’s project duties. On the macro level, the sense of purpose should align with the organization’s strategy. But it should also align, at least sometimes, with each individual’s career and personal goals.

- Clear performance metrics—How will the team and its individual members be evaluated? What does success look like? You need to be clear about this, but you don’t have to be formulaic. Evaluations can be as subjective as rating a dozen characteristics as good/not-good, or on a score of 1-5.

- Assigning the right tasks to the right people—People aren’t commodities. They aren’t interchangeable, like a router or a hand saw. They are good at specific things. Whenever possible, avoid assigning people to project tasks based on capacity—that is, how much free time they have—and instead try to assign tasks that align with each individual’s goals and interests.

- Encouraging individual achievement—Most people have long-term aspirations, and sometimes even formalized professional development plans. As team leader, you should be on the lookout for ways to nudge team members toward these goals. It’s not your job to ensure that they fully achieve their personal goals, but you should try to allow for at least a little forward movement.

- Sailboat rules communication, in which no one takes offense for clear direction—On a sailboat, once the sail goes up, you need to be ready to take direction from the captain, who is responsible for the welfare of all on board, and not take offense if he seems critical or unfriendly. In other words, you can’t take things personally. Likewise, team members need to set their egos aside and let perceived slights go for the sake of the team. When you start a big project, explain that you are assuming sailboat rules communication. That means that, in a meeting, no one has the privilege of taking anything personally.

- Mentorship—Team members need to be able to talk things over with more experienced people. Encourage your team to seek out mentors. They don’t necessarily have to be part of the project.

- Consistency and follow-through—Team morale falls off when inconsistency is tolerated or when numerous initiatives are started and then abandoned. Encourage a team environment in which everyone does what they commit to do, without leaving loose ends hanging. Be on the lookout for gaps in a project, where things are simply not getting done. (Nelson 2017)

Nelson also recommends avoiding the following demotivators, which can sap the life out of any team:

- Unrealistic or unarticulated expectations—Nothing discourages people like the feeling that they can’t succeed no matter how hard they try. Beware of managers who initiate an impossible project, knowing full well that it cannot be accomplished under the established criteria. Such managers think that, by setting unrealistic expectations, they’ll get the most out of their people, because they’ll strive hard to meet the goal. In fact, this approach has the opposite effect—it drains people of enthusiasm for their work and raises suspicions that another agenda, to which they are not privy, is driving the project. Once that happens, team members will give up trying to do a good job.

- Ineffective or absent accountability—Individual team members pay very close attention to how their leader handles the issue of accountability. If members sense little or no reason to stay on course, they’ll often slack off. As often as possible, stop and ask your team two essential question: 1) How are we doing relative to the metrics? 2) How do we compare to what we said we were going to do? If the answers are encouraging, that’s great. But if not, you need to ask this question: What are we going to do to get back on track?

- Lack of discipline—An undisciplined team fails to follow through on its own rules. Members show up late for meetings, fail to submit reports on time, and generally ignore agreed-upon standards. This kind of lackadaisical attitude fosters poor attention to detail, and a general sense of shoddiness. As a team leader, you can encourage discipline by setting a good example, showing up bright and early every day, and following the team rules. Make sure to solicit input from team members on those rules, so everyone feels committed to them at the outset.

- Anti-team behavior—Self-centered, aggressive bullies can destroy a team in no time, making it impossible for less confrontational members to contribute meaningfully. Overly passive behavior can also be destructive because it makes people think the passive team member lacks a commitment to project success. Finally, bad communication—whether incomplete or ineffective—is a hallmark of any poorly functioning team. (Nelson 2017)

The Best Reward Isn’t Always What You Think

In his book, Drive, Daniel Pink digs into the question of how to have a meaningful, purpose-driven work life. For a quick summary of his often surprising ideas, see this delightful, eleven-minute animated lecture: “Autonomy, Mastery, Purpose: The Science of What Motivates Us, Animated.” Among other things, Pink explains that cash rewards aren’t always the motivators we think they are. For simple, straight-forward tasks, a large reward does indeed encourage better performance. But for anything involving conceptual, creative thinking, rewards have the opposite effect: the higher the reward, the poorer the performance. This has been replicated time and time again by researchers in the fields of psychology, economics, and sociology. It turns out the best way to nurture engaged team members is to create an environment that allows for autonomy, mastery, and a sense of purpose (Pink 2009).

One form of motivation—uncontrolled external influences—can have positive or negative effects. For example, in 2017, Hurricanes Harvey and Irma inflicted enormous damage in Texas and Florida. That had the effect of energizing people to jump in and help out, creating a nationwide sense of urgency. By contrast, the catastrophic damage inflicted on Puerto Rico by Hurricane Maria, and the U.S. government’s slow response, generated a sense of outrage and despair. One possible reason for this difference is that, on the mainland, people could take action on their own, arriving in Florida or Texas by boat or car. Those successes encouraged other people to join the effort, creating a snowball effect. But the geographic isolation of Puerto Rico, and the complete failure of the power grid, made it impossible for the average person to just show up and help out. That, in turn, contributed to the overall sense of hopelessness.

This suggests that small successes in the face of uncontrolled external influences can encourage people to band together and work even harder as a team. But when even small signs of success prove elusive, uncontrolled external influences can be overwhelming.

As a technical team leader, you can help inoculate your team against the frustration of external influences by making it clear that you expect the unexpected. Condition your team to be prepared for external influences at some point throughout the project. For example, let your team know if you suspect that your project could possibly be terminated in response to changes in the market. By being upfront about the possibilities, you help defuse the kind of worried whispering that can go on in the background, as team members seek information about the things they fear.

If you’re working in the public domain, you’ll inevitably have to respond to influences that might seem pointless or downright silly—long forms that must be filled out in triplicate, unhelpful training sessions, and so on. Take the time to prepare your team for these kinds of things, so they don’t become demotivated by them.

5.4 Managing Transitions

High performing teams develop a rhythm. They have a way of working together that’s hard to quantify and that is more than just a series of carefully implemented techniques. Once you have the pleasure of working on a team like that, you’ll begin to recognize this rhythm in action and you’ll learn to value it. Unfortunately, you might also experience the disequilibrium that results from a change in personnel.

Endless books and articles have been written on the topic of change management, with a focus on helping people deal with new roles and personalities. Your Human Resources department probably has many resources to recommend. Really, the whole discipline comes down to, as you might expect with all forms of team management, good communication and sincere efforts to build trust among team members. Here are a few resources with practical tips on dealing with issues related to team transitions:

- In his book, Managing Transitions, William Bridges presents an excellent model for understanding the stages of transition people go through as they adapt to change. The first stage—Ending, Losing, and Letting Go—often involves great emotional turmoil. Then, as they move on to the second stage—the Neutral Zone—people deal with the repercussions of the first stage, perhaps by feeling resentment, anxiety, or low morale. In the third stage—the New Beginning—acceptance and renewed energy kick in, and people begin to move forward (Mind Tools n.d.). You can read more about the Transition Model here: “Bridges’ Transition Model: Guiding People Through Change.”

- A single toxic personality can undermine months of team-building. This article gives some helpful tips on dealing with difficult people: “Ten Keys to Handling Unreasonable and Difficult People.”

- This article offers suggestions on how to encourage likability, and, when that doesn’t work, how to get the most out of unpleasant people: “Competent Jerks, Lovable Fools, and the Formation of Social Networks.”

- A change in leadership can stir up all sorts of issues. This article suggests some ideas for dealing with change when you are the one taking command: “Five Steps New Managers Should Take To Transition Successfully From Peer To Boss.”

- As you’ve probably learned from personal experience, when individual members are enduring personal or professional stress, their feelings can affect the entire group. And when a team member experiences some kind of overwhelming trauma, shock waves can reverberate through the whole group in ways you might not expect. This article explains how an individual’s experience of stress and trauma can affect a workplace, and provides some tips for managing the emotions associated with traumatic events: “Trauma and How It Can Adversely Affect the Workplace.”

5.5 Self-Organizing Agile Teams

Agile software development was founded as a way to help team members work together more efficiently and companionably. In fact, three of the twelve founding principles of the methodology focus on building better teams:

- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

- The best architectures, requirements, and designs emerge from self-organizing teams.

- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Beedle et al. 2001)

The term “self-organizing teams” is especially important to Agile. Nitin Mittal, writing for Scrum Alliance, describes a self-organizing team as a “group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions, and readily adapt to changing demands” (2013).

But that doesn’t mean Agile teams have no leaders. On the contrary, the Agile development process relies on the team leader (known as the ScrumMaster in Scrum) to guide the team, ideally by achieving “a subtle balance between command and influence” (Cohn 2010). Sometimes that means moving problematic team members to new roles, where they can be more effective, or possibly adding a new team member who has the right personality to interact with the problematic team member. In a blog for Mountain Goat Software, Mike Cohn puts it like this:

There is more to leading a self-organizing team than buying pizza and getting out of the way. Leaders influence teams in subtle and indirect ways. It is impossible for a leader to accurately predict how a team will respond to a change, whether that change is a different team composition, new standards of performance, a vicarious selection system, or so on. Leaders do not have all the answers. What they do have is the ability to agitate teams (and the organization itself) toward becoming more agile. (2010)

5.6 The Power of Diversity

The rationale for putting together a team is to combine different people, personalities, and perspectives to solve a problem. Difference is the whole point. Diverse teams are more effective than homogenous teams because they are better at processing information and using it to come up with new ideas. According to David Rock and Heidi Grant, diverse teams tend to focus more on facts, process those facts more carefully, and are more innovative (2016). What’s more, researchers investigating creativity and innovation have consistently demonstrated “the value of exposing individuals to experiences with multiple perspectives and worldviews. It is the combination of these various perspectives in novel ways that results in new ideas ‘popping up.’ Creative ‘aha’ moments do not happen by themselves” (Viki 2016). In his book: The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies, Scott Page puts it like this:

As individuals we can accomplish only so much. We’re limited in our abilities. Our heads contain only so many neurons and axons. Collectively, we face no such constraint. We possess incredible capacity to think differently. These differences can provide the seeds of innovation, progress, and understanding. (2007, xxx)

Despite these widely documented advantages of diverse teams, people often approach a diverse team with trepidation. Indeed, bridging differences can be a challenge, especially if some team members feel threatened by ideas and perspectives that feel foreign to them. But diversity can result in conflict, even when everyone on the team only wants the best for others. This is especially true on teams made up of people from different countries. Such teams are vulnerable to cultural misunderstandings that can transform minor differences of opinion into major conflicts. Cultural differences can also make it hard for team members to trust each other, because different cultures have different ways of demonstrating respect and trust.

In her book The Culture Map: Breaking Through the Invisible Boundaries of Global Business, Erin Meyer describes negotiations between people from two companies, one American and one Brazilian. The first round of negotiations took place in Jacksonville, Mississippi, with the American hosts taking care stick to the agenda, so as to avoid wasting any time:

At the end of the two days, the American team felt great about all they had accomplished. The discussions, they believed, were efficient and productive. The short lunches and tight scheduling signified respect for the time the Brazilians invested in preparing for the negotiations and traveling to an out-of-the-way location. The Brazilians, on the other hand, were less upbeat and felt the meetings had not gone as well as hoped. (2014, 164)

As it turned out, the Brazilians felt that the efficient, organized American approach left them no time to get to know their potential new business partners. During the next round of negotiations, in Brazil, the South American hosts left time for long lunches and dinners that “stretched into the late evening,” lots of good food and conversation. But this “socializing marathon” made the Americans uncomfortable because they thought the Brazilians weren’t taking the negotiations seriously. In fact the opposite was true—the Brazilians were attempting to show respect for the Americans by attempting to get to know them so as to develop “personal connection and trust” (2014, 163-165).

Decades of psychology research has established that the best way to convince someone to adopt a new behavior is to convince him that other people have already adopted that behavior. So if you want individual team members to start showing up on time for meetings, for example, you can start by pointing out that the majority of team members do show up on time. As Leon Neyfakh writes in an article about how to change the way people do things: “a culture of respect and kindness isn’t necessarily made up of angels—just people who have come to believe that that’s what everyone else thinks is the right way to act” (Neyfakh 2012).

When they go unrecognized, cross-cultural misunderstandings like this can cause a host of ill-feelings. The first step toward preventing these misunderstandings is self-knowledge. What are your cultural biases, and how do they affect what you expect of other people? To find out, take this helpful quiz based on Erin Meyer’s research on cross-cultural literary: “What’s Your Cultural Profile?”

When thinking about culture, keep in mind that different generations have different cultures, too. Behavior that might feel perfectly acceptable to a twenty-four-year-old (texting during a meeting, wearing casual clothes to work) are often frowned on by older workers. Like cross-cultural differences, generational traits can cause unexpected conflicts on a team. This can be exacerbated if older team members feel threatened by younger workers, perhaps because younger workers are better at mastering new technology. Meanwhile, because of their lack of experience, younger workers might lack the ability to synthesize new information about a project. Your attempts to manage a multi-generational team can really go off the rails if you make the mistake of confusing “character issues like immaturity, laziness, or intractability with generational traits” (Wall Street Journal n.d.). This helpful guide suggests some ways to bridge the generation gap: “How to Manage Different Generations.”

Teams also have their own cultures, and sometimes you’ll have to navigate widely-diverging cultures on multiple teams. Take the time to get to know your team’s set of norms and expectations, especially if you’re joining a well-established group. After a little bit of observation, you might conclude that your team’s culture is preventing it from achieving its goals, in which case, if you happen to be the team leader, you’ll need to lead the team in a new direction.

Personality Power

Even among people from similar backgrounds, differences in personality can invigorate a team, injecting fresh perspectives and new ideas. A team of diverse personality types can be a challenge to manage, but such a team generates richer input on the project’s progress, increasing the odds of project success. For more on teams with diverse personalities, see this article from the American Society of Mechanical Engineers: “More Diverse Personalities Mean More Successful Teams.” For tips on managing a truly toxic individual, see this Harvard Business Review article: “How To Manage a Toxic Employee.”

5.7 Virtual Teams: A Special Challenge

Managing a team of people who work side-by-side in the same office is difficult enough. But what about managing a virtual team—that is, a team whose members are dispersed at multiple geographical locations? In the worldwide marketplace, such teams are essential. Deborah L. Duarte and Nancy Tennant Snyder explain the trend in their helpful workbook, Mastering Virtual Teams:

Understanding how to work in or lead a virtual team is now a fundamental requirement for people in many organizations…. The fact is that leading a virtual team is not like leading a traditional team. People who lead and work on virtual teams need to have special skills, including an understanding of human dynamics and performance without the benefit of normal social cues, knowledge of how to manage across functional areas and national cultures, skill in managing their careers and others without the benefit of face-to-face interactions, and the ability to use leverage and electronic communication technology as their primary means of communicating and collaborating. (Duarte and Tennant Snyder 2006, 4)

Names Matter

People like to hear their names used in conversation because it suggests that you are trying to get to know them and to address their concerns. But names can be tricky when you are working with people from cultures other than your own. Use this site to learn how to pronounce names from languages you don’t speak: PronounceNames.com.
For some tips on using and remembering names, see this article: “The Power of Using a Name.”

When properly managed, collaboration over large distances can generate serious advantages. For one thing, the diversity of team members “exposes members to heterogeneous sources of work experience, feedback, and networking opportunities.” At the same time, the team’s diversity enhances the “overall problem-solving capacity of the group by bringing more vantage points to bear on a particular project” (Siebdrat, Hoegel and Ernst 2009, 65). Often, engaging with stakeholders via email allows for more intimacy and understanding than face-to-face conversations, which, depending on the personality types involved, can sometimes be awkward or ineffective.

However, research consistently underscores the difficulties in getting a dispersed team to work effectively. In a widely cited study of 70 virtual teams, Vijay Govindarajan and Anil K. Gupta found that “only 18% considered their performance ‘highly successful’ and the remaining 82% fell short of their intended goals. In fact, fully one-third of the teams … rated their performance as largely unsuccessful” (2001). Furthermore, research has consistently shown that virtual team members are “overwhelmingly unsatisfied” with the technology available for virtual communication and do not view it “as an adequate substitute for face-to-face communication” (Purvanova 2014).

Given these challenges, what’s a virtual team manager to do? It helps to be realistic about the barriers to collaboration that arise when your team is scattered around the office park or around the globe.

The Perils of Virtual Distance

Physical distance—the actual space between team members—can impose all sorts of difficulties. According to Frank Siebdrat, Martin Hoegl, and Holger Ernst, most studies have shown that teams who are located in the same space, where members can build personal, collaborative relationships with one another, are usually more effective than teams that are dispersed across multiple geographical locations.

Potential issues include difficulties in communication and coordination, reduced trust, and an increased inability to establish a common ground…. Distance also brings with it other issues, such as team members having to negotiate multiple time zones and requiring them to reorganize their work days to accommodate others’ schedules. In such situations, frustration and confusion can ensue, especially if coworkers are regularly unavailable for discussion or clarification of task-related issues. (Siebdrat, Hoegel and Ernst 2009, 64)

Even dispersing teams on multiple floors of the same building can decrease the team’s overall effectiveness, in part because team members “underestimate the barriers to collaboration deriving from, for instance, having to climb a flight of stairs to meet a teammate face-to-face.” Team members end up behaving as if they were scattered across the globe. As one team leader at a software company noted, teams spread out within the same building tend to “use electronic communication technologies such as e-mail, telephone, and voicemail just as much as globally dispersed teams do” (Siebdrat, Hoegel and Ernst 2009, 64).

Communication options like video conferences, text messages, and email can do wonders to bridge the gap. But you do need to make sure your communication technology is working seamlessly. Studies show that operational glitches (such as failed Skype connections or thoughtlessly worded emails) can contribute to a pernicious sense of distance between team members. Karen Sobel-Lojeski and Richard Reilly coined the term virtual distance to refer to the “psychological distance created between people by an over-reliance on electronic communications” (2008, xxii). Generally speaking, it is tough to build a team solely through electronic communication. That’s why it’s helpful to meet face-to-face occasionally. A visit from a project manager once a year or once a quarter can do wonders to nurture relationships among all team members and keep everyone engaged and focused on project success.

In their book Uniting the Virtual Workforce, Sobel-Lojeski and Reilly document some “staggering effects” of virtual distance:

- 50% decline in project success (on-time, on-budget delivery)

- 90% drop in innovation effectiveness

- 80% plummet in work satisfaction

- 83% fall off in trust

- 65% decrease in role and goal clarity

- 50% decline in leader effectiveness (2008, xxii)

The Special Role of Trust on a Virtual Team

So what’s the secret to making virtual teams work for you? We’ve already discussed the importance of building trust on any team. But on virtual teams, building trust is a special concern. Erin Meyer describes the situation like this: “Trust takes on a whole new meaning in virtual teams. When you meet your workmates by the water cooler or photocopier every day, you know instinctively who you can and cannot trust. In a geographically distributed team, trust is measured almost exclusively in terms of reliability” (Meyer 2010).

All sorts of problems can erode a sense of reliability on a virtual team, but most of them come down to a failure to communicate. Sometimes the problem is an actual, technical inability to communicate (for example, because of unreliable cell phone service at a remote factory); sometimes the problem is related to scheduling (for example, a manager in Japan being forced to hold phone meetings at midnight with colleagues in North America); and sometimes the problem is simply a failure to understand a message once it is received. Whatever the cause, communication failures have a way of eroding trust among team members as they begin to see each other as unreliable.

And as illustrated in Figure 5-1, communicating clearly will lead your team members to perceive you as a reliable person, which will then encourage them to trust you.

Figure 5-1: The benefits of clear communication

You can learn more about Leigh Thompson’s ideas in this entertaining four-minute video: “Optimizing Virtual Teams.”

Leigh Thompson, a professor at Northwestern University’s Kellogg School of Management, offers a number of practical suggestions for improving virtual team work, including the following:

- Verify that your communication technology works reliably, and that team members know how to use it.

- Take a few minutes before each virtual meeting to share some personal news, so that team members can get to know each other.

- Use video conferencing whenever possible, so everyone can see each other. The video image can go a long way toward humanizing your counterparts in distant locales. If video conferencing is not an option, try at least to keep a picture of the person you’re talking to visible, perhaps on your computer. Studies have shown that even a thumbnail image can vastly improve your ability to reach an agreement with a remote team member. (2015)

Here are a few other resources on virtual teams. You’ll notice that they all emphasize good communication and building trust among team members:

- Ten basic principles for making virtual teams work: “Making Virtual Teams Work: Ten Basic Principles.”

- A helpful ebook on managing virtual teams: Influencing Virtual Teams: 17 Tactics That Get Things Done with Your Remote Employees.

- Tips for leveraging technology to keep your virtual team running smoothly: “Working in a Virtual Team: Using Technology to Communicate and Collaborate.”

5.8 Core Considerations of Leadership

Good teamwork depends, ultimately, on a leader with a clear understanding of what it means to lead. To judge by the countless books on the topic, you’d think the essential nature of leadership was widely understood. However, few people really understand the meaning of “leadership.”

In his book, Leadership Theory: Cultivating Critical Perspectives, John P. Dugan examines “core considerations of leadership,” zeroing in on misunderstood terms and also false dichotomies that are nevertheless widely accepted as accurate explanations of the nature of leadership. Dugan argues that a confused understanding of these essential ideas makes becoming a leader seem like a far-off dream, which only a select few can attain (Dugan 2017). But in fact, he argues, anyone can learn how to be a better leader.

Here’s what Dugan has to say about core considerations of leadership:

- Born Versus Made: This is one of the most pernicious false dichotomies regarding leadership. Dugan explains, “that there is even a need to address a consideration about whether leaders are born or made in this day and age is mind-numbingly frustrating. Ample empirical research illustrates that leadership is unequivocally learnable when defined according to most contemporary theoretical parameters.”

- Leader Versus Leadership: People tend to conflate the terms leader and leadership, but, according to Dugan, “Leader refers to an individual and is often, but not always, tied to the enactment of a particular role. This role typically flows from some form of formal or informal authority (e.g., a supervisor, teacher, coach). When not tied to a particular role, the term leader reflects individual actions within a larger group, the process of individual leader development, or individual enactments attempting to leverage movement on an issue or goal. Leadership, on the other hand, reflects a focus on collective processes of people working together toward common goals or collective leadership development efforts.”

- Leader Versus Follower: “The conflation of leader and leadership makes it easier to create an additional false dichotomy around the terms leader and follower,” with follower considered a lesser role. “The label of leader/follower, then, is tied solely to positional authority rather than the contributions of individuals within the organization. If we flip the example to one from social movements, I often see an interesting shift in labeling. In the Civil Rights Movement in the United States there are multiple identified leaders (e.g., Martin Luther King, Jr., Malcom X, Rosa Parks, James Baldwin) along with many followers. However, the followers are often concurrently characterized as being leaders in their own right in the process. In social movements it seems we are more willing to simultaneously extend labels of leader and follower to a person.”

- Leadership Versus Management: “Also tied up in leader/leadership and leader/follower dichotomies are arguments about whether leadership and management represent the same or unique phenomena. Once again, the role of authority gets tied up in the understanding of this. Many scholars define management as bound to authority and focused on efficiency, maintenance of the status quo, and tactics for goal accomplishment. An exceptional manager keeps systems functioning through the social coordination of people and tasks. Leadership, on the other hand, is less concerned with the status quo and more attentive to issues of growth, change, and adaptation.”

Emergent Leadership

Traditionally, engineers tended to be rewarded primarily for their analytical skills and their ability to work single-mindedly to complete a task according to a fixed plan. But in the modern world, plans are rarely fixed, and a single-minded focus blinds you to the ever-changing currents of living order. This is especially true when multiple people come together as a team to work on a project.

The old, geometric order presumes the continuation of the status quo, with humans working in a strict hierarchy, directed from above, performing their prescribed tasks like ants storing food for winter. By contrast, living order unfolds amidst change, risk-taking, collaboration, and innovation. This is like an ant colony after a gardener turns on a hose, washing away carefully constructed pathways and cached supplies with a cold gush of water, transforming order into chaos, after which the ants immediately adapt, and get to work rebuilding their colony. In such an unpredictable environment, the truly effective project manager is one who can adapt, learn, and perceive a kind of order—living order—in the chaos. At the same time, the truly effective project leader knows how to create and lead a team that is adaptable and eager to learn.

~Practical Tips

- At the end of every day, summarize what you and your team accomplished: In The Progress Principle, Teresa Amabile and Steven Kramer include a detailed daily checklist to help managers identify events throughout the day that promoted progress on the team’s goals, or that contributed to setbacks (2011, 170-171). “Ironically,” they explain, “such a microscope focus on what’s happening every day is the best way to build a widespread, enduring climate of free-flowing communication, smooth coordination, and true consideration for people and their ideas. It’s the accumulation of similar events, day by day, that creates that climate” (2011, 173). Or if you prefer a less regimented approach, consider writing periodic snippets, five-minute summaries of what you and your team accomplished, and then emailing them to stakeholders. Snippets became famous as a productivity tool at Google. You can learn all about snippets here:  http://blog.idonethis.com/google-snippets-internal-tool/.

- Establish a clear vision of what constitutes project success, and then work hard in the early stages to overcome any hurdles: This is job one for any project team leader. Focus all your teamwork skills on this essential goal.

- Build trust by establishing clear rules for communication: This is important for all teams, but especially for virtual teams spanning multiple cultures:

Virtual teams need to concentrate on creating a highly defined process where team members deliver specific results in a repeated sequence. Reliability, aka trust, is thus firmly established after two or three cycles. Because of that, face-to face meetings can be limited to once a year or so. (Meyer 2010)

- Take time to reassess: In an article summarizing work on teams completed by faculty at the Wharton School of the University of Pennsylvania, Jennifer S. Mueller, a Wharton professor of management, explains how to get a team back on track:

While teams are hard to create, they are also hard to fix when they don’t function properly. So how does one mend a broken team? “You go back to your basics,” says Mueller. “Does the team have a clear goal? Are the right members assigned to the right task? Is the team task focused? We had a class on the ‘no-no’s of team building, and having vague, not clearly defined goals is a very, very clear no-no. Another no-no would be a leader who has difficulty taking the reins and structuring the process. Leadership in a group is very important. And third? The team goals cannot be arbitrary. The task has to be meaningful in order for people to feel good about doing it, to commit to the task. (Wharton School 2006)

- Keep your team small if possible: Social psychologists have been studying the question of the ideal team size for decades. The latest research suggests that smaller is better. So for large projects, it’s sometimes helpful to divide a team into layers of sub-teams of about ten members. As Jennifer S. Mueller explains, when deciding on team size, you have to consider the type of project:

Is there an optimal team size? Mueller has concluded … that it depends on the task. “If you have a group of janitors cleaning a stadium, there is no limit to that team; 30 will clean faster than five. But,” says Mueller, “if companies are dealing with coordination tasks and motivational issues, and you ask, ‘What is your team size and what is optimal?’ that correlates to a team of six” (2006).

- Pick the right people: In his book Mastering the Leadership Role in Project Management, Alexander Laufer describes project managers who succeeded in part because they “selected people not only on the basis of their technical, functional, or problem-solving skills, but also on the basis of their interpersonal skills”(2012, 223-224). He emphasizes the importance of selecting the best possible members for your team:

With the right people, almost anything is possible. With the wrong team, failure awaits. Thus, recruiting should be taken seriously, and considerable time should be spent finding and attracting, and at times fighting for, the right people. Even greater attention may have to be paid to the selection of the right project manager. (2012, 222)

- Use a buddy system: One way to deal with large, virtual teams is to pair individuals in a specific area (design, purchasing, marketing) with a buddy in another group, company, or team. This will encourage direct contact between peers, making it more likely that they will pick up the phone to resolve issues one-on-one outside the normal team meetings or formal communications. Often these two-person teams within a team will go on to build personal relationships, especially if they get to meet face-to-face on occasion, and even better, socialize.

- Use Skype or other video conference options when possible: Video conferences can do wonders to improve team dynamics and collaboration. After all, only a small percentage of communication is shared via words. The remainder is body language and other visual cues.

- Bring in expert help: It’s common for a team to realize it is underperforming because of interpersonal problems among team members but then fail to do anything about perhaps because of a natural aversion to conflict. But this is when the pros in your company’s human resources department can help. If your team is struggling, all you need to do is ask. As explained in this article, you may be surprised by all the ways your human resources department can help you and your team: “6 Surprising Ways That Human Resources Can Help Your Career.” Other resources for repairing a dysfunctional team include peer mentors and communities of practice.

- Consider the possibility that you are the problem: If most or all of the teams you join turn out to be dysfunctional, then it’s time to consider the possibility that you are the problem. Examine your own behavior honestly to see how you can become a better team member. Peer mentors and communities of practice can be an invaluable way to sharpen your teamwork skills. It’s also essential to understand the role you typically play in a team. This 28-question quiz is a good way to start evaluating your teamwork skills: “Teamworking Skills.”

- Learn how to facilitate group interactions: Just as musicians need to study and practice their instruments, leaders need to study and practice the best ways to facilitate team interactions. Here are two helpful resources:

- Ingrid Bens, the author of Faciliating with Ease, is a widely recognized expert on group facilitation. Her web site provides helpful resources, include free templates and videos: “Facilitation Techniques for Consultants: Books by Ingrid Bens.”

- Liberating Structures offers a wealth of tools and techniques for teams and groups here: “Liberating Structures.”

- Do your team-building exercises: People often claim to dislike team-building exercises, but they can be essential when kicking off major projects. This is especially true for teams that do not know each other, but also for teams that have worked together before or that inhabit the same building. Your team-building efforts don’t need to be major events. In fact, the less planned they appear to be, the better.

- Take time to socialize: The camaraderie generated by a few hours of socializing helps build the all-important trust needed for a team to collaborate effectively. Try to make your work hours fun, too. Of course, if you are working with teams that span multiple cultures, you need to be sensitive to the fact that what’s fun for one person might not be fun for another. But at the very least, most people enjoy a pleasant conversation about something other than work. Encourage team members to tell you stories about their lives. In the process, you’ll learn a lot about your team members and how they filter information. Sharing stories also makes work more interesting and helps nurture relationships between team members.

- Have some fun: Something as simple as having your team choose a name for a project and creating a project logo can help create a sense of camaraderie. Consider encouraging friendly competitions between teams, such as ‘first to get a prototype built’ or ‘most hours run on a test cell in the week.’ If your office culture is relatively relaxed, you might want to try some of the fun ideas described in this article: “25 Ways to Have Fun at Work.”

- Celebrate success: Too often teams are totally focused on the next task or deliverable. Take the time to celebrate a mid-project win. This is especially helpful with lengthy, highly complex projects.

~Summary

- A team is a “small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable” (Katzenbach and Smith 1993, 45). A high-functioning team is more than the sum of its individual members. They offer complementary sets of skills and varying perspectives that make it possible to solve problems as they arise. Perhaps most importantly, teams are good at adapting to changing circumstances.

- Trust is the magic ingredient that allows team members to work together effectively. Because teams often come together in a hurry, building trust quickly is essential. Several techniques, traits, and behaviors help foster trusting relationships:

- Reliable promises—a specialized type of commitment pioneered in Lean—formalizes the process of agreeing to a task. A reliable promise is predicated on a team member’s honest assessment that she does indeed have the authority, competence, and capacity to make a promise, and a willingness to correct if she fails to follow through.

- Emotional intelligence, or the ability to recognize your own feelings and the feelings of others, is crucial to a team’s effectiveness. Some people are born with high emotional intelligence. Others can cultivate it by developing skills associated with emotional intelligence such as self-awareness, self-control, self-motivation, and relationship skills.

- An unrealistically positive attitude can destroy painstakingly built bridges of trust between team members. Especially in the planning phase, an overly optimistic project manager can make it difficult for team members to voice their realistic concerns.

- Reliable promises, emotional intelligence, and a realistic outlook are only helpful if you have the skills to communicate with your team members. This is one area where getting feedback from your co-workers or taking classes can be especially helpful.

- According to John Nelson, team motivators include a sense of purpose; clear performance metrics; assigning the right tasks to the right people; encouraging individual achievement; sailboat rules communication, in which no one takes offense for clear direction; options for mentorship; and consistency and follow-through. Team demotivators include unrealistic or unarticulated expectations; ineffective or absent accountability; a lack of discipline; and selfish, anti-team behavior. One form of motivation—uncontrolled external influences—can have positive or negative effects, depending on the nature of the team and its members’ abilities to adapt.

- Even high-performing teams can be knocked off their stride by personnel transitions or other changes. The Transition Model, developed by William Bridges, describes the stages of transition people go through as they adapt to change: 1) Ending, Losing, and Letting Go; 2) the Neutral Zone; and 3) New Beginning. Many resources are available to help teams manage transitions.

- In Agile, a self-organizing team is a “group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions, and readily adapt to changing demands” (Mittal 2013).

- Diverse teams are more effective than homogenous teams because they are better at processing information and are more resourceful at using new information to generate innovative ideas. Companies with a diverse workforce are far more successful than homogeneous organizations.

- Virtual teams present special challenges due to physical distance, communication difficulties resulting from unreliable or overly complicated technology, and cross-cultural misunderstandings. For this reason, building trust is especially important on virtual teams.

~Glossary

- emergent leaders—People who emerge as leaders in response to a particular set of circumstances.

- emotional intelligence—The ability to recognize your own feelings and the feelings of others.

- physical distance—The actual space between team members.

- premortem—A meeting at the beginning of a project in which team members imagine that the project has already failed and then list the plausible reasons for its failure.

- reliable promise—A commitment to complete a task by an agreed-upon time. In order to make a reliable promise, you need to have the authority to make the promise and the competence to fulfill the promise. You also need to be honest and sincere in your commitment and be willing to correct the situation if you fail to keep the promise.

- self-organizing team—As defined in Agile, a “group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions, and readily adapt to changing demands” (Mittal 2013).

- team—A “small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable” (Katzenbach and Smith 1993, 45).

- virtual distance—The “psychological distance created between people by an over-reliance on electronic communications” (Lojeski and Reilly 2008, xxii).

References

Amabile, Teresa, and Steven Kramer. 2011. The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work. Boston: Harvard Business Review Press.

Beedle, Mike, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Andrew Hunt, et al. 2001. “Principles behind the Agile Manifesto.” Agile Manifesto. Accessed July 1, 2018. http://agilemanifesto.org/iso/en/principles.html.

Breuer, Christina, Joachim Hüffmeier, and Guido Hertel. 2016. “Does Trust Matter More in Virtual Teams? A Meta-Analysis of Trust and Team Effectiveness Considering Virtuality and Documentation as Moderators.” Journal of Applied Psychology 101 (8): 1151-1177. doi:http://dx.doi.org/10.1037/apl0000113.

Cohn, Mike. 2010. “The Role of Leaders on a Self-Organizing Team.” Mountain Goat Software. January 7. https://www.mountaingoatsoftware.com/blog/the-role-of-leaders-on-a-self-organizing-team.

Duarte, Deborah L., and Nancy Tennant Snyder. 2006. Mastering Virtual Teams: Strategies, Tools, and Techniques that Succeed. San Francisco: Josey-Bass, A Wiley Imprint.

Dugan, John P. 2017. Leadership Theory: Cultivating Critical Perspectives. San Francisco, CA: Jossey-Bass.

Edmondson, Amy. 1999. “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly 44 (2): 350-383. http://www.jstor.org/stable/2666999.

Ehrenreich, Barbara. 2009. Bright-Sided. New York: Henry Holt and Company, LLC.

Gielan, Michelle. 2010. “Why Keeping Your Promise is Good for You.” Psychology Today. https://www.psychologytoday.com/blog/lights-camera-happiness/201005/why-keeping-your-promise-is-good-you.

Goleman, Daniel. 1995. Emotional Intelligence: Why It Can Matter More Than IQ. New York: Random House.

Govindarajan, Vijay, and Anil K. Gupta. 2001. “Building an EFfective Global Business Team.” MIT Sloan Management Review. http://sloanreview.mit.edu/article/building-an-effective-global-business-team/.

Hunt, Vivian, Dennis Layton, and Sara Prince. 2015. “Why Diversity Matters.” McKinsey.com. January. https://www.mckinsey.com/business-functions/organization/our-insights/why-diversity-matters.

Kahn, Jennifer. 2013. “Can Emotional Intelligence Be Taught?” New York Times Magazine, September 11. http://www.nytimes.com/2013/09/15/magazine/can-emotional-intelligence-be-taught.html?pagewanted=all.

Katzenbach, Jon R., and Douglas K. Smith. 1993. Wisdom of Teams. New York: McKinsey & Company.

Kerby, Holly Walter, K. Brittland DeKorver, and Joanne Cantor. 2018. “Fusion Story Form: a novel, hybrid form of story.” International Journal of Science Education, September 1: 1774-1794.

Laufer, Alexander. 2012. Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results. Upper Saddle River: FT Press.

Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects. New York: Palgrave Macmillan.

Lojeski, Karen Sobel, and Richard R. Reilly. 2008. Uniting the Virtual Workforce: Transforming Leadership and Innovation in the Globally Integrated Enterprise. Hoboken: John Wiley & Sons, Inc.

Macomber, Hal. 2010. “Securing Reliable Promises on Projects: A Guide to Developing a New Practice.” LeanProject. https://www.leanproject.com/wp-content/uploads/Securing-Reliable-Promises-on-Projects-v-3.11.pdf.

Manning, Trevor. 2018. Help! I need to Master Critical Conversations. Trevor Manning Consultancy Pty Ltd.

Meyer, Erin. 2010. “The Four Keys To Success With Virtual Teams.” Forbes, August 19. http://www.forbes.com/2010/08/19/virtual-teams-meetings-leadership-managing-cooperation.html.

—. 2014. The Culture Map: Breaking Through the Invisible Boundaries of Global Business. New York: Public Affairs.

Mind Tools. n.d. “Bridges’ Transition Model: Guiding People Through Change.” MindTools. Accessed July 1, 2018. https://www.mindtools.com/pages/article/bridges-transition-model.htm.

Mittal, Nitin. 2013. “Self-Organizing Teams: What and How.” Scrum Alliance. January 7. https://scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-how.

Nelson, John. 2017. “Lecture on reliable promising for EPD612: Technical Project Management, University of Wisconsin-Madison .” October 4.

—. 2017. “Motivators and Demotivators for Teams.” Lecture for EPD612: Technical Project Management, University of Wisconsin-Madison. October 4.

Neyfakh, Leaon. 2012. “How to change a culture.” Boston Globe, September 23. https://www.bostonglobe.com/ideas/2012/09/22/how-change-culture/HitMpC95xPFidEjEl2cx9J/story.html.

Page, Scott E. 2007. The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies. Princeton, New Jersey: Princeton University Press.

Pink, Daniel H. 2009. Drive: The Surprising Truth About What Motivates Us. New York: Riverhead Books.

Purvanova, Radostina K. 2014. “Face-to-face versus virtual teams: What have we really learned?” The Psychologist-Manager Journal 17 (1): 2-29.

Rock, David, and Heidi Grant. 2016. “Why Diverse Teams are Smarter.” Harvard Business Review, November 4. https://hbr.org/2016/11/why-diverse-teams-are-smarter.

Serrat, Olivier. 2012. “The Premortem Technique.” DigitalComments@ILR. March. https://digitalcommons.ilr.cornell.edu/cgi/viewcontent.cgi?article=1218&context=intl.

Siebdrat, Frank, Martin Hoegel, and Holger Ernst. 2009. “How to Manage Virtual Teams.” MIT Sloan Management Review (Summer): 63-68.

Snow, Frank. 2003. “Give it to Chuck.” Ask Magazine, 12-13.

Thompson, Leigh. 2015. “Optimizing virtual teams.” Kellog School of Management. July 31. https://www.youtube.com/watch?v=0SzWrazgt7Y&feature=youtu.be.

Viki, Tendayi. 2016. “Why Diverse Teams Are More Creative.” Forbes, December 6. https://www.forbes.com/sites/tendayiviki/2016/12/06/why-diverse-teams-are-more-creative/#f27da2772628.

Wall Street Journal. n.d. “How to Manage Different Generations.” Wall Street Journal. Accessed July 1, 2018. http://guides.wsj.com/management/managing-your-people/how-to-manage-different-generations/.

Wharton School. 2006. “Is Your Team Too Big? Too Small? What’s the Right Number?” Knowledge @ Wharton. June 14. http://knowledge.wharton.upenn.edu/article/is-your-team-too-big-too-small-whats-the-right-number-2/.

Williams, Ray. 2014. “The Biggest Predictor of Career Success? Not Skills or Education—But Emotional Intelligence.” Financial Post, January 1. http://business.financialpost.com/executive/careers/the-biggest-predictor-of-career-success-not-skills-or-education-but-emotional-intelligence.

6

Project Planning

In preparing for battle, I have always found that plans are useless but planning is indispensable.
–Dwight D. Eisenhower, President of the United States (1953-1961), Supreme Commander of the Allied Forces in Europe (1943-1945)

Objectives

After reading this lesson, you will be able to

- Describe the living order approach to project planning

- Explain and distinguish between push and pull planning

- Describe the Agile approach to project planning

- Explain the relationship between sustainability and continuous improvement

- Discuss issues related to contingency plans

The Big Ideas in this Lesson

- Uncertainty is a permanent feature of a project leader’s work.

- In the living order, planning is a learning, collaborative, and adaptive exercise in which team members stand ready to alter the plan at any time to address changing conditions.

- Living order planning is exemplified by pull planning, in which planners start by identifying the desired end-state, and then work backwards to plan activities that will achieve that goal.

6.1 A New Way to Think About Planning

Merriam Webster’s definition of planning is “the act or process of making a plan to achieve or do something.” This suggests that the ultimate goal of planning is the plan itself. It also presumes that once a plan has been formulated, you only need to follow the plan to achieve the desired outcome. That’s fine for ordinary conversation. But when we begin to think about living order project planning, a more expansive understanding of the nature of planning emerges. In living order, planning is a process that prepares the project team to respond to events as they actually unfold. The whole point of planning is to develop strategies to mangage

- Changes to scope

- Schedule

- Cost

- Quality

- Resources

- Communication

- Risk

- Procurement

- Stakeholder engagement

Planning results in a plan, but the plan is not an end in itself. Rather, a plan is a strategic framework for the scheduling and execution of a project. It’s only useful if it includes the information team members require to begin moving forward. And it only remains useful if team members modify the plan as they learn the following about the project:

- Key constraints such as the timeline, cost, and functional requirements.

- Information on project system issues, such as workflow and milestones, which provide a broad look at the project as a whole.

- Plans for periodic check-ins that allow participants and leadership to reevaluate the project and its original assumptions.

Planning is Accepting Uncertainty

Die-hard geometric order planners  take a deterministic approach, laboring under the false notion that once everyone agrees on a plan, the plan itself determines what comes next. Indeed, it is tempting to think you can nail down every detail at the beginning of a project and then get going without looking back. But effective living order planners understand that, especially early in a project, these details are nearly always provisional and subject to change. Thus, effective living order planners stand ready to alter their plans in response to what they learn in changing conditions. They also understand that the context in which a project unfolds has varying levels of detail and variability, with potentially thousands of decisions made over the project’s life cycle. Figure 6-1 shows the expanding circles of context surrounding an individual task within a project. Each circle adds its own variability and uncertainty to a project.

Figure 6-1: Each circle of context adds its own variability and uncertainty to a project.

As Alexander Laufer and Gregory Howell explained in an article for Project Management Journal, a project leader’s work is founded in uncertainty (1993). Uncertainty is not an exceptional state in an otherwise predictable process of work, they argue. Instead, it is a permanent feature of modern work. What’s more, the longer the time between planning and implementation, the higher the uncertainty surrounding individual activities. Naturally, the higher the uncertainty in a project, the more difficult it is to plan, and the less effective the plans will be at articulating actions and outcomes. Finally, they emphasize that no amount of planning can eliminate the variability intrinsic to the work of a complex project.

Planning for Complexity

Alexander Laufer and Gregory Howell remind that the variability intrinsic to the work of a complex project cannot be eliminated by planning (1993). But what exactly is a complex project? Are all difficult projects complex? In a blog post for Team Gantt, Tera Simon explains: “A complex project isn’t necessarily a difficult project. Projects can be difficult due to reasons such as cost or performance, but this doesn’t automatically mean the project is complex. Complexity refers to projects that include ambiguity or uncertainty. They are surrounded by unpredictability” (2016).

Examples of complex projects range from megaprojects like Boston’s Big Dig, to more focused undertakings like developing software for a medical technology that is not yet functional and that will be used by people in changeable healthcare settings. A truly complex project would have some of the following characteristics:

- Uncertainty regarding the project’s ultimate goal.

- Ambiguously defined or changing constraints.

- New or insufficient technologies.

- The need for new, previously untested solutions.

- A large, changing cast of stakeholders from many disciplines.

- An evolving context involving, for example, unpredictable climate or geological constraints, political transitions and economic upheavals.

If you’re interested in a more theoretical investigation of the idea of complexity, read up on the Cynefin framework, which is a decision-making tool designed to help managers make sense of complexity. Created by David Snowden and Mary E. Boone, the Cynefin framework allows leaders “to see things from new viewpoints, assimilate complex concepts, and address real-world problems and opportunities.” It focuses on identifying the type of situation in which you are operating (simple, complicated, complex, or chaotic) and then making choices appropriate to that context.

For technical project managers, the framework’s most useful insight is the distinction between complicated and complex projects. Snowden and Boone discuss this idea in an article for the Harvard Business Review:

In a complicated context, at least one right answer exists. In a complex context, however, right answers can’t be ferreted out. It’s like the difference between, say, a Ferrari and the Brazilian rainforest. Ferraris are complicated machines, but an expert mechanic can take one apart and reassemble it without changing a thing. The car is static, and the whole is the sum of its parts. The rainforest, on the other hand, is in constant flux—a species becomes extinct, weather patterns change, an agricultural project reroutes a water source—and the whole is far more than the sum of its parts. This is the realm of “unknown unknowns,” and it is the domain to which much of contemporary business has shifted. (2007)

Further Reading

- Snowden and Boone’s article on the Cynefin framework describes the full spectrum of project complexity and includes links to more information: https://hbr.org/2007/11/a-leaders-framework-for-decision-making.

- Tera Simon’s post on complex projects describes the skills you need to tackle complex projects: https://www.teamgantt.com/blog/tackle-complex-projects.

- This post by Kathleen B. Hass describes a variety of complex projects and introduces a new project management discipline, complex project management: https://www.projecttimes.com/articles/managing-complex-projects-part-1.html

Planning is Learning

In living order, it’s helpful to think of a project as a knowledge development activity . Project Planning , then, is the continuous process of incorporating new knowledge into a project plan. At the beginning of highly complex or unfamiliar projects, you may know little to nothing about how to achieve the desired outcome. By the end, you know vastly more. The more you learn, the greater your ability to fine tune the plan to achieve the desired project outcome. This means that a plan will acquire detail as you move forward. It’s important to resist the temptation to include details about factors you don’t yet completely understand because those details will almost certainly turn out to be wrong. Take care not to plan at a level of precision that exceeds your understanding of the many factors that could affect the project.

When you commit to this adaptive approach to planning, you can treat project planning in a fundamentally different way. Instead of constantly asking, “How can I steer my project back onto the original plan?” you can ask, “How can I use this new knowledge to refine my plan and improve the likelihood of project success?” When you learn something, encounter a setback, or have a success, you can treat that experience as another data point to incorporate into the ongoing planning process. It’s a piece of information you didn’t have before, which you can then use to improve your overall project plan on your journey toward the project outcome.

A project is a knowledge development activity.

Once you have accepted the inevitable transition from a state of ignorance to a state of discovery, you will begin to question the possibility of certainty in project planning. A good rule of thumb is that if you are certain about what the future holds for your project, you’re probably wrong or actually don’t need a project plan; a simple task list may work. This is especially true in fields where work occurs in varying locations, under changing, often unpredictable circumstances. As Dora Cohenca-Zall, Alexander Laufer, and others demonstrated in their research on construction project planning, “high levels of uncertainty are the rule rather than the exception” (1994). As we discussed in Lesson 1, modern projects unfold in what Peter Vaill calls a state of “permanent whitewater” (Laufer 2012). It’s simply not possible to foresee all the problems that might arise throughout the life of a project.

The ultimate goal of project planning is a well-thought-out strategy that has enough flexibility to adapt to developing circumstances. The planners themselves must continually engage in what psychologists call cognitive reframing, which means reconsidering events and facts to see them in a new way. Only then can they adapt to changing circumstances throughout the life of the project.

Planning is Adaptation and Collaboration

The goal of a project plan is to explain who creates what, how they create it, and for what purpose. In other words, a project plan is a tool for collaboration. The process of planning is itself a collaborative exercise that is often the first test of a team leader’s ability to build trust among members and to take advantage of the multiple perspectives offered by a diverse team. Success in planning requires all the teamwork skills and techniques at your disposal, which, as discussed in Lesson 5, includes reliable promising, emotional intelligence, a realistic outlook, and good communication skills. The more team members trust each other, the more willing they will be to take the kinds of risks required to adapt to changing circumstances.

In Becoming a Project Leader, Alexander Laufer, Terry Little, Jeffrey Russell, and Bruce Maas tell stories about project managers who navigated volatile, complicated projects by fostering adaptation and collaboration (2018). These successful managers combined four essential strategies:

- Evolving planning: A learning-based approach to project planning that presumes that the project team will expand their knowledge of the project as it unfolds.

- Responsive agility: Quick action to solve problems as a project unfolds, combined with clear, up-to-date communication.

- Proactive resilience: Challenging “the status quo, proactively and selectively” to prevent potential problems.

- Collaborative teamwork: Encouraging flexible, responsive, and interactive teamwork.

In Becoming a Project Leader, Alexander Laufer, Terry Little, Jeffrey Russell, and Bruce Maas explain the value of a rolling wave approach to planning in volatile situations in which it’s difficult to make firm commitments. Successful project managers develop plans “in waves as the project unfolds and information becomes more reliable.” This approach involves combining “detailed short-term plans” with 90-day, medium-term plans, and more general master plans that cover the project’s duration:

This style of planning does not imply that decisions should be arbitrarily “put off until later.” Rather, it is an act of deliberately splitting off those planning aspects that can be acted upon more opportunely in the future. By applying this approach, two extreme situations are avoided. The first is the preparation of overly detailed plans too soon, which may lead to rapid obsolescence because some decisions are based on information provided by intelligent guesses rather than on reliable data. The other extreme situation is delaying the planning until all the information is complete and stable. In both cases, project effectiveness will suffer. One can make timely and firm decisions only by adopting the planning style that provides greater detail at the appropriate stage of the project. (18-19)

6.2 The Geometric Order Approach: Push

The traditional, geometric-order approach to planning is founded on the idea that, with enough research and forethought, planners can foresee most eventualities. In other words, geometric order planners assume that it is possible to know everything, or nearly everything, about a project before it begins. Because planners assume they will have little need to adjust as the project unfolds, geometric order planning presumes a linear progression of sequential, predictable activities. Each participant has a specific place in a hierarchical, sequential order.

Geometric order planning works well for straight-forward, predictable activities that are easy to repeat, such as laying new sewer pipe. It tends to focus on optimizing individual activities, with each activity presumed to occur as scheduled. The problem with this way of thinking is that it leads planners to disregard the uncertainty associated with activities that are dependent on each other—for example, suppose you are designing a product for a foreign market and a trade war breaks out, placing a large tariff on your product, making it much more expensive. In that case you would need to rethink your product, its potential markets, and perhaps where it is manufactured.

The term push plan is used to describe a project plan founded on an assumption of geometric order principles. Once the plan is complete, it’s assumed the work will unfold accordingly, resulting in a predetermined project outcome. (See Figure 6-2.) Once a push plan is set in motion, stakeholders tend to focus on keeping the parts of the plan moving forward. The term push was first used in manufacturing to describe a system in which “production is based on a projected production plan and where information flows from management to the market, the same direction in which the materials flow” (BusinessDictionary n.d.).

Figure 6-2: Once a push plan is set in motion, stakeholders tend to focus on keeping the parts of the plan moving forward.

A push system is typically built around forecasts of customer demand, which may or may not be right. However, once a push plan is set in motion, the actual demand for the final product is of less concern during production than the need to keep the parts of the plan moving forward. A push plan can be appropriate where the project type and the activities to be performed are well known and very similar to previous projects. It is also appropriate when producing a commodity for a general audience. In construction and manufacturing, the ultimate goal of push planning is to produce a product for the least possible cost. In a push-plan project, subcontractors focus on completing their work on time and on budget, so they can call their work finished and move on to another project. It is built around forecasts of labor availability (see Figure 6-3 ), which are actually hard to predict and are often wrong. Meanwhile, managers are typically judged by their ability to meet the predefined production schedule. In this way, individual self-interest drives a push project forward, with limited regard for a project in which workflow is managed and waste prevented by collaboration and coordination.

Figure 6-3: Push planning is built around forecasts of labor availability, which can be wrong. (Adapted from an image by David Thomack.)

You’ll sometimes find push planning referred to as make-to-stock—the idea being that a push manufacturing system processes large batches of items at the fastest possible rate, based on forecasts of demand, and then moves them “to the next downstream process or into storage” (Plex 2017). That’s a simplistic way of thinking about push, but it’s a good way to start getting a grasp on the basic idea. To that end, here are some simplified examples of push systems:

- Textbooks that are printed and shipped to a warehouse, where they await orders from bookstores that might or might not need them. The total depends in part on sales forecasts of student demand and in part on the least number of books the printer is willing to print.

- Sidewalk salt that is manufactured and shipped to hardware stores in St. Louis. The same amount is shipped every year, even during an exceptionally warm winter in which the temperature never goes below freezing.

For a humorous yet informative example of extremely bad push planning, see the famous chocolate-wrapping scene from I Love Lucy, in which poor Lucy and Ethel attempt to keep up with an increasingly fast conveyor belt:

A YouTube element has been excluded from this version of the text. You can view it online here: https://wisc.pb.unizin.org/technicalpm/?p=944

More complicated examples of push planning can be found in every industry, including manufacturing, product development, healthcare, and construction. You can identify a push system by looking at the various processes in a particular system and identifying what triggers a particular process to begin work. In a push system, an upstream process is responsible for pushing work onto the next downstream process. For example, in a hospital, the emergency department might push a newly arrived patient downstream, to the surgery floor to await a procedure (See Figure 6-4.) If the surgery floor does not have any beds available, the patient will have to wait in the emergency department until one opens up. In this push setting, where “the transition of work is the responsibility of the upstream (i.e., prior) process,” it’s up to the emergency personnel to manage the situation, finally ensuring that the patient does indeed get a spot downstream on the surgery floor (Institute for Healthcare Improvement n.d.).

Figure 6-4: Flow of patients in a push hospital setting.

A push system lacks any explicit limit on the amount of work that can be in process in the system at any one time (Hopp and Spearman 2004, 142). Once work begins, it is supposed to continue, with no regard for delays due to errors, resource availability, and other problems. Thus, when problems do arise, the system slows to a crawl or stops entirely because it lacks the built-in mechanisms for evaluating and improving flow found in Lean and other living order methodologies.

In software development, the classic example of push planning is the waterfall model, illustrated in Figure 6-5. In its purest form, the waterfall model conceives of software development as a set of discrete, sequential steps. It presumes a highly predictable project outcome, with little or no opportunity for adjustments as the project unfolds. Indeed, once the project reaches the testing stage, costs and other considerations make it nearly impossible to go back and alter the original plan.

Figure 6-5: Waterfall model of software development.

The many variations of push planning are fundamentally appealing because they presume that the world operates according to a prescribed set of rules. After all, as Isaac Newton taught us, we live in a world where the laws of physics produce predictable results. If you drop a football, you know it will hit the ground. If you throw it, you know it will travel through the air. In other words, we are wired to think that careful planning can produce predictable results. But that static, geometric order way of thinking does not adequately reflect the reality of modern project planning. We must take living order into account.

Waterfall Model: Some History

The Waterfall model was first introduced by Winston W. Royce, in a 1970 paper entitled “Managing the Development of Large Software Systems.” Royce described an ideal development process, in which developers engaged in detailed planning at the beginning of the project and then wrote the code to match minute specifications, producing a predictable outcome. But Royce was not recommending this as a realistic way to develop software. In fact, the sentence immediately following his waterfall diagram reads, “I believe in this concept, but the implementation described above is risky and invites failure” (Royce). Much to his dismay, his description of the overly simplistic waterfall method tore through the software development world of the 1970s and 1980s like wildfire. For an engaging telling of the history of the waterfall method, see this video by Glen Vanderburg, starting at 9:00:

“Real Software Engineering – Glenn Vanderberg, Lone Star Ruby Conference 2010.”

A YouTube element has been excluded from this version of the text. You can view it online here: https://wisc.pb.unizin.org/technicalpm/?p=944

6.3 The Living Order Approach: Pull Planning

Pull planning is the practical application of the living order approach to project planning. It is collaborative, flexible, and recursive, and is especially suited for highly complex projects in which stakeholders have to adapt to new information. It presumes a group of workers who coordinate regularly, updating their plan to reflect current conditions. It focuses on producing as much as can actually be completed and no more. The ultimate goal of pull planning is creating the best possible value.

The thinking behind pull originated in 1948 with Taiichi Ohno, known as the “father of the Toyota Production System,” which in turn led to Lean and Agile. Living in post-World-War-II Japan, where food shortages were a frequent problem, Ohno drew his inspiration from American supermarkets, with their seemingly magical ability to provide whatever customers wanted, when they wanted it:

Pull Thinking Comes Before Pull Scheduling

In lesson 7, you’ll learn about creating pull schedules, which are typically created by a group of stakeholders who collaborate by placing multi-colored Post-it notes on a wall-sized planning board. It’s good to know how to create pull schedules, but before you can do that, you need to grasp the fundamentals of pull thinking discussed in this lesson. For most people, pull thinking is a whole new way of looking at project planning. Pull scheduling is the practical implementation of pull thinking. Once you grasp the essential concepts of pull thinking, the process of creating a pull schedule is something you can learn by doing.

From the supermarket we got the idea of viewing the earlier process in a production line as a kind of store. The later process (customer) goes to the earlier process (supermarket) to acquire the needed parts (commodities) at the time and in the quantity needed. The earlier process immediately produces the quantity just taken (re-stocking the shelves). (Ohno 1988, 26)

A pull system is sometimes referred to as make-to-order—suggesting that a customer places an order, at which point the entire production facility kicks into gear to create the item required to fulfill that one order. That’s a highly simplified version of pull, but it’s a helpful starting point. These two supply-chain examples illustrate this elementary version of pull:

- A student orders a textbook online, a single copy of which is then printed and shipped directly to the student.

- A paint store customer puts the last three containers of primer in her cart, prompting the store clerk to restock the primer bin.

In reality, the concept of the “customer” means more in pull than just the end user. In a pull system, a downstream process is the customer of the prior, upstream process. Here’s what this would mean on a construction site:

All work is done at the pull of the customer. So the electrician is completing her in-wall rough-in so that the drywaller, her customer, can start standing rock. The drywaller is hanging rock so that his customer, the painter, can begin work. By working backward from a project milestone … we make sure that all work is pulled into the plan. The result is that work happens at the right time, not just whenever it can. (Lemke 2016)

Pull planning is a key concept in Lean, which values the seamless flow of work without the inevitable stops and starts (i.e., waste) that characterize push planning. As illustrated in Figure 6-6, pull planning eliminates unnecessary steps, saving as much as one-third of the time required to complete a similar project designed according to a traditional push plan.

Figure 6-6: Pull planning eliminates waste by eliminating unnecessary steps. (Source: John Nelson)

In Lean thinking, planning is a fluid, real-time process. To be an effective Lean project planner, you need to understand that living order continues to evolve. Planning is no longer about communicating and reinforcing a formal, predefined static plan to all team members. It’s about giving each team member a way of thinking about the project and a process for incorporating new knowledge into the plan, with regular options for resetting the plan as the project unfolds.

6.4 Distinguishing Between Push and Pull

In pull planning, you start by identifying the desired end state of the project, which is the value you want to create. Then you work backwards to determine the most efficient (least wasteful) way to get there. This is similar to a crew of kayakers trekking to the bottom of a stretch of rapids and looking back up to formulate a plan for traversing them. After that, they can return to the beginning of the whitewater and attempt to navigate the rapids with a better sense of the challenges that lie ahead.

The best way to grasp the nature of a pull system is to compare it to push. As a simple example, suppose you are planning a European vacation. If you were taking a push planning approach, you would start making a list of all the recommended sites in the countries you will be visiting. The result would be a schedule that allocates all the available time to the various destinations. Such a vacation plan is essentially a checklist of things to do or see. By contrast, a pull approach would be entirely focused on how you want to feel on the way home—that is, the value you want the trip to create. You might review the same list of possible sites and activities, but your decisions about which to include in your plan would depend on how you want to feel when the trip is over.

Figure 6-7 illustrates the beginnings of a pull plan for two possible types of vacations—one that leaves you feeling rested, and one that leaves you feeling invigorated by new experiences. As with all pull plans, the secret is to start at the end. How do you want to feel on the way home? Then, as shown in Figure 6-8, you can add activities to your plan that ensure you end up feeling that way. As you can see, Post-it Notes are used in both figures. While there are many scheduling and planning programs to choose from, Post-it Notes, a very low-tech option, are used widely in pull scheduling because they are easy to move around, thus encouraging the planner to try out new ideas.

Figure 6-7: In pull planning, you start with the desired end-state

Figure 6-8: After you identify the desired end-state, you can plan the activities that will result in that end-state.

Pull Planning in Action

For a more extensive introduction to pull planning, see this one-hour video, produced by the authors of this book, which uses planning a vacation as a way to explain essential pull-planning concepts.

A YouTube element has been excluded from this version of the text. You can view it online here: https://wisc.pb.unizin.org/technicalpm/?p=944

As you learn to identify push and pull at work in various environments, you’ll begin to see how organizations use one or the other, or combine both approaches to achieve their goals. The fact is, “in the real world, there are no pure push or pure pull systems” (Hopp and Spearman 2004, 143). You’ll also discover that the concepts of push and pull are used to emphasize different concerns in different contexts.

For example, consider how the terms are used in the world of supply chain management, which encompasses “all the activities that must take place to get the right product into the right consumer’s hands in the right quantity and at the right time – from raw materials extraction to consumer purchase” (Mays Business School n.d.). In supply chain management, push/pull experts often speak of the boundary between a push portion of a system and the pull portion (Sehgal 2009). As in the following example, the boundary between push and pull usually arises after a product has been manufactured in a push environment, based on general forecasts of consumer demand, and warehoused until specific requests from specific customers pull the product into the marketplace:

A food manufacturer may make mushroom soup that they brand in a few ways— their own label plus those of several supermarket chains. The manufacturer has a good idea of the amount of soup that they need each month. They are less sure, however, of how to package it to meet demand. As a result, they will likely choose to mass-produce the mushroom soup and inventory it in unlabeled cans until orders materialize. Then they can quickly label the cans and ship them out when customers place their orders. (McGinley 2016)

But don’t let these more specialized applications of the concepts of push and pull distract you from the fundamental meaning of pull. Whatever your area of expertise, you’ll never go wrong by applying some pull thinking to a new project. What’s the desired end-state of the project? What value do you want the project to create? Most importantly, how will you collaborate with the project stakeholders to achieve it?

Pull Public Speaking

Matthew David Potter, a Masters in Engineering Management student at the University of Wisconsin-Madison, noted that, when working on a class presentation, he tried to focus on what would be useful for his fellow students, rather than what he wanted to include. In other words, like all good communicators, he zeroed in on the needs of his audience. Later, he realized that focusing on the audience is actually a form of pull thinking—starting at the desired end-state, and then figuring out how to achieve it.

He summarizes his experience as follows:

- If you start at the end (customer), identify the three key points (value) and then pull that value back through as you create the slides (value stream and flow), the end result is way tighter. Taking that approach encouraged me cut information that might be interesting to me, but that wasn’t critical to make my main points (waste).

- By contrast, the geometric push approach starts with identifying all the information you want to share, followed by creating slides for each important point, and then a scramble to tie it all together and somehow edit it to keep the presentation under the prescribed time limit (pers. comm., June 15, 2018).

6.5 Pull and Agile

Agile to the Rescue

The many problems associated with the roll-out of the HealthCare.gov website in 2013 can be traced to an attempt to use a waterfall development model for a vast and complicated project. The project was rescued by a team of Agile developers, many of whom essentially volunteered their time to get the system up and running. You can read all about it here: “Obama’s Trauma Team: How an Unlikely Group of High-Tech Wizards Revived Obama’s Troubled HealthCare.gov Website.”

Agile software development emphasizes an iterative approach to planning. Whereas the traditional, waterfall approach to software development presumes few changes to the project after the software requirements have been formulated, Agile is specifically designed to allow project participants to adapt to changing circumstances, the most important of which is often the customer’s evolving notion of the software requirements. Rather than planning the entire project at the beginning, Agile project planners focus on creating accelerated, evolving iterations of the product in one- to two-week development sprints.

Unlike traditional project management, which presumes a well-defined beginning to a project, with tasks unfolding until the well-defined end, Agile project management has an iterative, circular flow. The engine that propels this flow is continuous feedback from the product owners about how well the software meets their needs. As the software begins to take shape, product owners are continually asked to make decisions

about which features they value most, and which might be dispensed with in order to meet the project budget and schedule. This means that, in Agile development, the planning doesn’t end until the project is over. Predictability emerges if you give it time to emerge naturally and eludes you if you try to force it too soon. One of the gifts of Agile is that it is self-calibrating. Once you’re run a few sprints, an actual rate of progress starts to emerge, calibrated to the particular team, sponsor, technology, and requirements. (Merrill 2017)

As software grows increasingly important in many types of products, it’s likely that Agile, with its cycles of fast feedback and revisions, will become more common in product development, including among large manufacturers such as John Deere. The cycles of Agile development produce working software faster, making it easier to get feedback from marketing and customers earlier in the product development life cycle. Agile engineering, as this new form of product development is called, encourages teams to learn about their product and make improvements faster than they could with traditional product development. In a blog post for FormLabs, a manufacturer of high-end 3D printers, Joris Peels writes,

Learning from failure through prototypes helps companies quickly build better products. By validating assumptions and collecting data, these products are made in a more accurate, evidential way.

With traditional methods, teams painstakingly make world maps and then spend months planning a possible route through this imagined world. Only then do they have a product and really know where they stand. With Agile Engineering, products emerge in the first week of product development. Teams set off and check their compass often. (2016)

6.6 Sustainability: Planning for Continuous Improvement

Continuous improvement is “a method for identifying opportunities for streamlining work and reducing waste” (LeanKit n.d.). Known in Lean as kaizen (Japanese for improvement), continuous improvement is a key concept in Lean and Agile, but is a motivating force in all types of organizations. To fully incorporate continuous improvement into your organization’s philosophy, you need to build it into projects, starting with the planning phase. Indeed, the very process of planning is itself a continuous improvement activity because it involves looking to the future and thinking about how to do things better.

Continuous improvement is an important concept for organizations seeking to make systematic sustainability changes, and for individual projects concerned with sustainability. This is especially true for projects unfolding over a long period of time because new sustainability technologies might become available during the course of the project. According to Bill Wallace, author of Becoming Part of the Solution: The Engineer’s Guide to Sustainable Development , continuous improvement programs devoted to amplifying a company’s sustainability efforts should include the following:

Baseline assessment. The firm should determine its current environmental and societal impact. This should be done by first defining the scope of the firm’s activities and assessing the impacts of those activities against existing performance standards, norms, or other benchmarked firms….

Set objectives for improvement. Based on the results of the baseline assessment, the firm should devise a comprehensive set of objectives for improvement. The objectives should be measurable against established indicators. Schedules…should also be established….

Implementation. Once objectives and schedules are set, the firm should devise programs for implementation and allocate sufficient funding to achieve the objectives. Regular sustainable performance reports should be generated and sent to top management…. The reports should also contain an assessment of technology developments that could change current practices.

Review and revision. The firm should schedule periodic reviews…to check progress against the objectives and plans and to see how program funds were spent. Based on program performance, client expectations, new benchmarks, new technologies, firmwide performance, or other variables, the objectives should be revisited and revised accordingly. (2005, 95)

6.7 A Word on Contingency Plans

Beware the Planning Fallacy

According to this interesting and entertaining podcast, humans are genetically wired for optimism. This makes us painfully susceptible to the planning fallacy, a cognitive bias that makes us think we can finish projects faster, and for less money, than is actually realistic: “Here’s Why All Your Projects Are Always Late — And What to Do About It (Freakonomics Podcast).”

In addition to creating the project plan, you need to create a contingency plan, which is a plan for addressing key possible obstacles to project success. A contingency plan defines alternate paths for the project in case various risks are realized. A contingency plan typically includes a contingency fund, which is an amount of resources set aside to cover unanticipated costs. Contingency plans and funds are necessary because even the most seasoned project planner sometimes succumbs to excessive optimism, assuming everything will go well and that all resources will be available when needed. Also, no matter how thoroughly you plan a project, you will inevitably miss at least a few small issues.

Examples of issues that might necessitate the use of a contingency fund:

- Inadequate initial estimates

- Small items not covered in planning

- Errors in initial estimates

- Small deviations due to inevitable delays

Note that a contingency fund is not designed to manage major deviations or scope changes.

A simple and effective form of contingency planning is setting aside a contingency fund consisting of a fixed percentage of all resources (time, money, people) in addition to the amounts spelled out in the final budget. Ten percent is a typical amount, but that can vary depending on the size and type of project, as well as the type of industry. For example, this set of contingency guidelines, created by Arizona State University for campus construction projects, shows a range of contingency percentages: “Project Contingency Guidelines.” Likewise, the U.S. Department of Energy describes a fixed percentage approach to contingency planning here: “Contingency.”

One of the chief difficulties of contingency planning is getting people to agree on exactly what is and is not covered by a contingency fund, and how it applies in specific circumstances. A considerable amount of research has been done on this topic, but there is still no clear consensus. For that reason, before launching a major project, you would be wise to investigate the ins and outs of contingency planning at your organization in particular, and in your industry in general.

Contingency planning is closely related to risk management, which is discussed in Lesson 8. When you are working on small projects of limited complexity, you can probably assume that a fixed percentage contingency plan will cover most risks. However, for highly complex, technically challenging projects, it’s important to distinguish between generic budget planning contingencies (using a fixed percentage) and the more sophisticated modeling of risk for uncertainty.

~Practical Tips

- Use the right level of detail: A project plan needs to be pitched at the right level, with just enough detail. A very high-level plan with minimal detail won’t be meaningful to all stakeholders. On the other hand, an extremely complex project plan with needless detail and endless lists of tasks can be so difficult to update that people will often simply neglect to do so. At that point, such a plan becomes worse than useless. As a rule of thumb, a project plan needs between 15-50 activities. That will help ensure that a plan is detailed enough to act on but manageable enough to keep updated. You can then use sub-plans to break down tasks down to more detail.

- Be prepared to adapt your plan to reflect changing realities: When planning a project, don’t ever assume you are trying to hit a fixed target. In the vast majority of projects, the target actually moves. You need to be flexible and adapt your plan as necessary.

- Plan at the appropriate level of precision: Take care not to plan at a level of precision that exceeds your understanding of the many factors that could affect the project. Doing so generates waste twice: first in the planning process, and then later in the execution stage when you find that the plan needs to be revised to reflect the reality of the situation. You can be sure your planning involves an unrealistic level of precision if, for instance, it results in an estimate like $380,275,465.47. That level of precision implies a level of accuracy that does not exist in the real world. It’s more helpful to say that such a project is worth somewhere in the $350- to $400-million range.

- Use scheduling technology as one of many planning tools: Use technology tools, such as project management software, that all stakeholders understand and know how to access. But don’t make the mistake of thinking that creating a schedule is the same as planning the project. A schedule is just one aspect of a project plan.

- Keep your eye on success: Throughout the planning process, maintain a clear focus on the definition of project success.

- Get everyone together to plan: If your team is scattered across multiple geographic locations, try to get everyone to meet in one place for at least part of the planning phase. This can go a long way toward clearing up misunderstandings caused by poorly worded emails or conference calls in which some stakeholders might dominate more than others.

- Think holistically about your project plan: A good project plan touches on every element of the project. This 3.5-minute video gives a quick overview of things to think about when planning a project: “What Goes Into a Project Plan?”

~Summary

- In living order, a plan is not an end in itself, but rather a strategic framework for the scheduling and execution of a project. It’s helpful to think of a project as a knowledge development activity. Project planning, then, is the continuous process of incorporating new knowledge into a project plan. A project plan is a tool for collaboration, and the process of planning is itself a collaborative exercise that is often the first test of a team leader’s ability to build trust among members and to take advantage of the multiple perspectives offered by a diverse team.

- Geometric order planning presumes a linear progression of sequential, predictable activities. The term push plan is used to describe a project plan founded on an assumption of geometric order principles.

- Pull planning is the practical application of the living order approach to project planning. It is collaborative, flexible, and recursive, and is especially suited for highly complex projects in which stakeholders have to adapt to new information. It presumes a collaborative group of workers who coordinate regularly, updating their plan to reflect current conditions. It focuses on producing as much as can actually be completed and no more.

- Agile takes a pull planning approach to software development. It is iterative and presumes constant adaptation in response to the customer’s evolving notion of the software requirements.

- Continuous improvement, a key concept in Lean and Agile, is an important idea for organizations seeking to make systematic sustainability changes, and for individual projects concerned with sustainability.

- In addition to creating a project plan, you need to create a contingency plan that addresses outcomes not spelled out in the project plan.

~Glossary

- Agile engineering—A new form of product development that makes use of the interative cycles of fast feedback and revisions first implemented in Agile software development. It encourages teams to learn about their product and make improvements faster than they could with traditional product development.

- cognitive reframing—The process of reconsidering events and facts to see them in a new way.

- contingency plan—A plan for an alternative route to project success that can be implemented if an obstacle to progress arises.

- contingency fund—Resources set aside to cover unanticipated costs.

- plan—A strategic framework for the scheduling and execution of a project. In traditional, geometric order project planning, a plan presumes events will unfold in a predictable way, with little need to update the plan. In living order project planning, the plan is always provisional and subject to change.

- planning bias—A cognitive bias that makes us think we can finish projects faster, and for less money, than is actually realistic.

- project planning—In traditional, geometric order project planning, the process of formulating the plan that will guide the rest of the project. In living order project planning, “project planning” also refers to the continuous process of incorporating new knowledge into the initial project plan.

- pull planning—Project planning that accounts for the unpredictable, ever-changing nature of the living order. Pull planners start at the desired end state of the project, working backwards to determine the most efficient (least wasteful) way to achieve the desired outcome. To be effective, pull planning requires a collaborative group of workers who coordinate regularly, updating their plan to reflect current conditions.

- pull schedule—A schedule typically consisting of color-coded sticky notes that can be removed or repositioned as necessary. This can also be replicated in a number of different software programs. The key is to start with the end goal and then work backwards to determine the tasks required to achieve that goal.

- push planning—Project planning that presumes events will unfold in a predictable, geometric order. Push planning is founded on management forecasts of customer demand, with great emphasis placed on the need to keep the parts of the plan moving forward. Managers and subcontractors focus on their individual portions of the project, with limited regard for managing workflow and preventing waste through collaboration and coordination.

- supply chain management—All the “activities that must take place to get the right product into the right consumer’s hands in the right quantity and at the right time—from raw materials extraction to consumer purchase” (Mays Business School n.d.).

- waterfall model—A push plan model used for software that breaks the development process into a set of discrete, sequential steps. It presumes a predictable project outcome, with little or no opportunity for adjustments as the project unfolds.

Additional Resources

- This one-hour video, produced by the authors of this book, uses planning a vacation as a way to explain essential pull-planning concepts: https://go.wisc.edu/livingpm.

- Lean Construction Institute’s glossary, with definitions of “push” and “pull”: “Push” and “Pull” Definitions.

- In this book, Peter Vaill introduces the term “permanent whitewater:” Managing as a Performing Art: New Ideas for a World of Chaotic Change (1989).

- In this video, workshop participants build two houses out of plastic blocks, the first while following a traditional push plan and the second while employing the elements of pull planning: “Pull Planning Workshop: San Diego Mesa College.” You won’t be surprised to learn that the pull-planning houses were completed more quickly, with more cooperation and greater overall satisfaction among the team members.

References

BusinessDictionary. n.d. “Push System.” BusinessDictionary. Accessed July 1, 2018. http://www.businessdictionary.com/definition/push-system.html.

Cohenca-Zall, Dora, Alexander Laufer, Aviad Shapira, and Gregory A. Howell. 1994. “Process of Planning during Construction.” Journal of Construction Engineering and Management, September: 561-578. http://tx.technion.ac.il/~avishap/During-Construction-Planning.pdf.

Hopp, Wallace J., and Mark L. Spearman. 2004. “To Pull or Not to Pull: What is the Question?” Manufacturing & Service Operations Management 133-148.

Institute for Healthcare Improvement. n.d. “Use Pull Systems to Improve Flow.” ihi.org. Accessed July 1, 2018. http://www.ihi.org/resources/Pages/Changes/UsePullSystems.aspx.

Laufer, Alexander. 2012. Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results. Upper Saddle River: FT Press.

Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects. New York: Palgrave Macmillan.

LeanKit. n.d. “What is Continuous Improvement?” LeanKit. Accessed July 1, 2018. https://leankit.com/learn/kanban/continuous-improvement/.

Lemke, Klaus. 2016. “3 Simple Rues for Effective Pull Planning.” LeanProject. December 15. http://www.leanproject.com/news/3-simple-rules-for-effective-pull-planning/.

Mays Business School. n.d. “What is Supply Chain Management?” Mays Business School, Texas A&M University. Accessed July 1, 2018. http://mays.tamu.edu/department-of-information-and-operations-management/what-is-supply-chain-management/.

McGinley, Bill. 2016. “How to Determine When to Use Push or Pull Production Scheduling.” Carpedia. October 24. http://carpedia.com/blog/determine-use-push-pull-production-scheduling/.

Merrill, Robert, interview by Ann Shaffer. 2017. Senior Business Analyst, University of Wisconsin-Madison (October 2).

Ohno, Taiichi. 1988. Toyota Production System: Beyond Large Scale Production. Cambridge, MA: Productivity press.

Peels, Joris. 2016. “Why Agile Engineering is the Future of Product Design.” FormLabs. March 7. Accessed 5 2017, October. https://formlabs.com/blog/agile-engineering-product-development/.

Plex. 2017. “Push vs. Pull Manufacturing: Is a Kanban Pull System Right for Your Company?” Industry Week, July 28. http://www.industryweek.com/cloud-computing/push-vs-pull-manufacturing-kanban-pull-system-right-your-company.

Royce, W.W. 1987. “Managing the development of large software systems: Concepts and Techniques.” ICSE ’87 Proceedings of the 9th international conference on Software Engineering. Monterey: IEEE Computer Society Press. 328-338.

Sehgal, Vivek. 2009. “Push or Pull?” Supply Chain Musings. October 7. http://www.supplychainmusings.com/2009/10/push-or-pull.html.

Simon, Tera. 2016. 5 Valuable Skills You Need to Tackle Complex Projects like a Pro. December 5. Accessed 10 2019, September. https://www.teamgantt.com/blog/tackle-complex-projects.

Snowden, David J., and Mary E. Boone. 2007. “A Leader’s Framework for Decision Making.” Harvard Business Review. https://hbr.org/2007/11/a-leaders-framework-for-decision-making.

Thomack, David. 2018. “Introduction to Lean and Project Delivery.” Video Lecture for CEE 498: Construction Management. University of Wisconsin-Madison, College of Engineering, April 20.

Thomsen, Chuck, Joel Darrington, Dennis Dunne, and Will Lichtig. n.d. “Managing Integrated Project Delivery.” LeanConstruction.org. Accessed September 26, 2018. https://www.leanconstruction.org/wp-content/uploads/2016/02/CMAA_Managing_Integrated_Project_Delivery_1.pdf.

Wallace, Bill. 2005. Becoming Part of the Solution: The Engineers Guide to Sustainable Development. Washington, D.C.: American Council of Engineering Companies.

7

Project Scheduling

Essentially, all models are wrong, but some are useful.
– George Box, Founder of the Department of Statistics, University of Wisconsin-Madison

Objectives

After reading this lesson, you will be able to

- Discuss issues related to moving from the planning phase of a project to the scheduling phase

- Define terms related to scheduling

- List the scheduling methods most closely associated with geometric and living orders

- Explain concepts related to the critical path method, including potential pitfalls and techniques for schedule compression

- Explain concepts and techniques related to pull scheduling

- Describe ways to integrate pull thinking with the critical path method

- Discuss the importance of project milestones

The Big Ideas in this Lesson

- A project schedule is a shared time map for successful completion of the project. Depending on what constututes “success” for the project, the schedule may include several hard deadlines and be highly constrained, or may be completely flexible and unconstrained.

- Scheduling is a phase of project management that necessarily blends geometric and living order, often combining the preditability of critical path techniques with the agility offered by pull scheduling.

- Because a schedule is a communication and thinking tool, the level of detail with which it is prepared and communicated should be tailored for the needs of the project and team members.

- The critical path method—the consummate geometric, push tool—is essential for identifying activities that determine the expected duration of a complex project. However, an excessive focus on critical path analysis during project execution can divert needed attention and energy from pull-focused project delivery.

7.1 Crossing the Bridge from Planning to Scheduling

As you learned in the previous lesson, a project plan is a high-level view of the project that roughly maps out how to achieve the project’s ultimate goals, given the available time and resources. In living order, a project plan is provisional and open to revision as you learn more about the project. A schedule is a specific, time-based map designed to help the project team get from the current state to successful project completion.

You can think of a project plan as similar to a football coach’s strategy for winning a particular game, which might, for instance, include ideas for containing a highly mobile quarterback, or for double-teaming an exceptionally good wide receiver. By contrast, a schedule is all about tactics; it is similar to the specific plays a team uses to ensure that the right players are in the right places on the field at the right time. A team will know some of these plays backwards and forwards after endless practice; other plays will be the result of adaptation and inspiration as the game unfolds. In the same vein, in living order, a schedule typically requires regular adjustments to account for the changing realities of the project.

Above all else, a schedule is a form of communication with everyone involved in the project. The attention of project stakeholders is a scarce resource. Therefore, you should strive to make your schedule worthy of your team’s attention. It’s important to shape a schedule to the team’s needs and strengths, and to your organization’s culture. A good role model for this type of flexibility is the jazz and classical musician Wynton Marsalis. When he is performing Mozart’s Trumpet Concerto in D with a symphony orchestra, he follows the strict rules of the classical music world. When he plays bebop at Lincoln Center, he switches to the free-form, improvisatory style of the jazz world. In the same way, as a project manager operating within living order, you need to be aware of what is and isn’t appropriate and useful for your particular project and organization throughout the life of your project.

In all cases, it’s essential to include the right amount of detail—neither too much nor too little. You should start by identifying key milestone dates as hard deadlines—the most important of which is the final delivery date. Those dates are often set in advance by other stakeholders and cannot be changed. Then build a schedule that provides paths to meeting those deadlines. If, as you build the schedule, you realize that meeting those deadlines is not possible, then you may have to adjust milestones and project completion dates.

Starting with the most important milestone, delivery date, and then building the schedule backwards, can help ensure that plans don’t get squeezed at the end. It is not uncommon for people to start out with a generous schedule for the first few activities and gradually get more aggressive with timing as they run up against the delivery date. The immediacy of the first activities means that people are more realistic about timings, whereas future activities get planned with more hope than knowledge.

Sometimes it’s helpful to start with the deadlines you want to meet, and then create a schedule that fits those dates. This can be a useful exercise that helps you understand the scheduling challenges you face, including identifying the project milestones. It’s also a good way to figure out what parts of the project you need to reevaluate and adjust.

It’s also important to tailor a schedule to match the project’s overall complexity and time requirements (for example, whether deadlines are hard or soft). Projects are not equal in terms of complexity and criticality. This means that the type of schedule that works for one project may not work for another.

You can choose from a host of software possibilities for generating schedules, such as MS Project. Whichever one you use, take care not to get so lost in the details of building a schedule, and interacting with the software interface, that you lose sight of the project goals as expressed in the project plan. Always keep in mind the project’s definition of success as expressed by the stakeholders, as well as the overall plan for completing the work. A good project manager is able to cross the bridge from the generalities of a project plan to the specifics of a schedule, without losing sight of the big picture.

7.2 Choosing Your Words

Making sure all stakeholders use the same terminology is crucial in all phases of project management, but it’s especially important when you are trying to get a group of diverse people to agree to a schedule. After all, a schedule only works as a form of communication if it is written in a language everyone understands. And since contract terms are often tied to schedule, a lack of common agreement on the meaning of specific terms in a schedule can have far-ranging effects.

Terminology is so important that many state governments around the United States publish their own project management glossaries. As you embark on a new project, you’d be wise to find out if the organization you work for, or the vendors you will be working with, have compiled such a glossary. If such organizational resources exist, use them as a starting point for your own project glossary. Otherwise, you can always turn to the Project Management Institute’s lexicon (available here: “PMI Lexicon of Project Management Terms”) or glossaries provided online by consulting firms or other project management resources such as the following:

- “Project Management Glossary of Terms”

- “Free Glossary of Project Management Terms and Definitions”

The following definitions of scheduling-related terms are taken from a variety of sources. You’ll find links to these sources in the bibliography at the end of this lesson.

- milestone: “A significant event in the project; usually completion of a major deliverable” (State of Michigan: Department of Technology, Management & Budget 2013). An important distinction is that a milestone is a zero-duration activity; e.g., “acceptance of software by client” is a milestone, preceded by many contributing activities.

- activity: “An element of work performed during the course of a project. An activity normally has an expected duration, an expected cost, and expected resource requirements” (Project-Management.com 2016). Beware that some organizations subdivide activities into tasks while others use task and activity synonymously.

- duration: “The amount of time to complete a specific task given other commitments, work, vacations, etc. Usually expressed as workdays or workweeks” (State of Michigan: Department of Technology, Management & Budget 2013).”

- resource: “Any personnel, material, or equipment required for the performance of an activity” (Project-Management.com 2016).

- cost: “An expenditure, usually of money, for the purchase of goods or services” (Law 2016).

- slack: “Calculated time span during which an event has to occur within the logical and imposed constraints of the network, without affecting the total project duration” (Project-Management.com 2016). Or put more simply, slack, which is also called float, is the amount of time that a task can be delayed without causing a delay to subsequent tasks or the project’s overall completion date.

A Single Source of Information for Your Project Team

One growing area of project management is virtual project environments. These relatively low-cost, stand-alone environments usually include a built-in project planner, as well as issues databases, resource allocation utilities, task managers, dashboards, and so on. These virtual environments are especially useful for dispersed teams and make access to MS Project or similar software unnecessary. Most importantly, a virtual project environment serves as a single source of information for important documents like project plans, thus avoiding problems with out-of-date or incorrect information circulating among team members. To see some examples, do a web search for Smartsheet, Mavenlink, and Genius Project.

7.3 Geometric and Living: Two Ways to Schedule

Scheduling is a phase of project management that necessarily blends geometric and living order. Sometimes you need to hew to a predetermined order of activities on a tightly regulated schedule; sometimes you need to allow for the flexibility required when one activity is dependent on another activity of uncertain duration and complexity. In a true geometric order situation, you’ll likely spend more time planning upfront than updating later. In living order, the opposite is true. Generally speaking, in a geometric order, push environment, 60 percent of effort might go into planning, 10 percent into scheduling, and 30 percent into updating and revising the schedule. In a living order, pull environment, those percentages shift, with 30 percent of effort devoted to planning, 10 percent to scheduling, and 60 percent to adjusting and refining the schedule.

The planning and scheduling technique most closely associated with push planning and the geometric order is the critical path method (CPM), which is a “step-by-step project management technique for process planning that defines critical and non-critical tasks with the goal of preventing time-frame problems and process bottlenecks” (Rouse 2015). You can use CPM to identify impacts of proposed changes to the timing and duration of tasks. The key to CPM is identifying sequences of connected activities, known as paths (Larson and Gray 2011, 662). The critical path is defined as “the series of activities which determines the earliest completion of the project” (Project-Management.com 2016).

The scheduling technique that best exemplifies living order principles is a pull schedule created collaboratively by stakeholders, typically by using multi-colored Post-it notes. Details of this type of scheduling have been codified in the Last Planner System, a proprietary production planning system, based on Lean principles, and developed by Glenn Ballard and Greg Howell. Agile also makes use of pull scheduling techniques.

Although protecting the critical path is important in these types of living order scheduling, explicitly identifying and monitoring the critical path throughout the entire project may be less of a concern. We’ll explore why that’s true later in this lesson. First, let’s look at the basics of CPM. Then we’ll discuss the details of pull scheduling and consider ways to combine push and pull systems to achieve the ultimate goals of Lean: creating value and eliminating waste.

7.4 Push: The Critical Path Method (CPM)

CPM is especially useful for large, complex projects where schedule interrelationships may not be readily apparent. It is “ideally suited to projects consisting of numerous activities that interact in a complex manner” (Rouse 2015). First used in industry in the late 1950’s, CPM has its roots in earlier undertakings, most notably on the Manhattan Project.

CPM focuses on identifying the critical path and then closely monitoring the activities on the critical path through the entire project. For example, when developing a new machine, the electronic circuit design may be the critical path defining the time to launch. Designing the mechanical structure might also be important, but it may not dictate the overall time to completion and therefore the critical path.

Creating a CPM model of a project involves these six steps:

1. Identify the project milestones or deliverables.

2. Create a list of all the activities in the project, as described in a work breakdown structure.

3. Identify the duration for each activity.

4. Construct a network diagram that identifies the dependencies between activities.

5. Calculate early-start, late-start, early-finish, and late-finish dates for each activity.

6. Identify the sequence of tasks through the project with tasks of zero float (slack). This is the critical path.

Using CPM, you can identify:

- The minimum total time required to complete the project—that is, the critical path.

- Flexibility, or slack, in the schedule along other, non-critical paths.

A key value of CPM analysis is the understanding it can reveal to the project team about the chain of activities that are likely to establish the earliest completion of the project. This understanding can help the team explore ways to reduce project duration and can help the team focus on efficient execution of time-critical activities.

If you are considering pursuing certification as a Project Management Professional (PMP), you’ll definitely want to gain experience in CPM. As a technical project manager, you need to become conversant in CPM, even if you lack the technical expertise to create a full-blown CPM analysis in one of the many software products available for the job. Here are some helpful resources on the topic:

- A helpful introduction to CPM: “The Ultimate Guide to the Critical Path Method.”

- Comments from veteran project managers on the importance of CPM: page 174 in Project Management: The Managerial Process by Erik W. Larson and Clifford F. Gray.

- A 13-minute video introduction to CPM: “Project Scheduling: Ed March.”

- A blog post that describes where determining the critical path falls in the overall schedule process: “Efficient Project Scheduling Techniques To Keep Things Running Smoothly.”

Avoiding CPM Pitfalls

As you explore the tools available for implementing CPM, keep in mind that CPM is the ultimate geometric order tool for project management. It can lure you into a false sense of security regarding the predictableness of a project, causing you to presume, for instance, that it is always possible to identify all project activities and their durations ahead of time, or that the dependencies between them is always clear. But in the constantly changing living order, you need to be prepared for change at all times. In some large projects, there actually may be more than one critical path, or the critical path may shift during project execution. This means you need to keep your eye on near critical activities and paths, so you can spring into action if they suddenly become more critical than your original analysis had foreseen.

CPM provides a helpful model for testing the feasibility of a project’s overall schedule, and is therefore useful in the initial strategizing phase. However, it can become more of a burden than a help during execution if the project team feels compelled to follow the dictates of the CPM model too rigidly. It has limited value in guiding daily schedule decisions and on-the-job coordination. Project managers who spend too much time looking at their CPM models will miss the realities of day-to-day execution. This can enable reactive rather than proactive project management—that is, managing by looking out the rearview mirror instead of out of the windshield.

A successful project manager uses CPM as a means of keeping the project on track and assigning the most reliable personnel to critical activities, all the while keeping in mind that CPM does not deliver absolute truths. In the words of Dr. George Box, the founder of the Department of Statistics at the Univeristy of Wisconsin-Madison, “Essentially, all models are wrong, but some are useful.” This is absolutely true of CPM. You need to evaluate your CPM project models regularly to ensure that they are in alignment with the stakeholders’ definition of project success.

In the fast-changing projects that are becoming increasingly common in living order environments, you might have to start with a schedule for project milestones, with only a hypothesis of the overall critical path. Then, throughout the project, you might need to continually revise your concept of the critical path. For instance, when planning a large conference, your critical path may change if registrations significantly lag (or exceed) expectations, requiring you to adjust marketing efforts, logistics, and even the content of the conference. In software development, the critical path may change due to actions by competitors, changes in technology, risk mitigation efforts, scope changes and integration issues, just to name a few.

Schedule Compression

CPM can be very helpful when you need to compress a schedule—that is, when you need to take a schedule you have already developed and reduce it without adjusting the project’s scope. You can only compress a schedule by adjusting the schedule of activites on the critical path. Keep in mind that compressing a schedule adds cost and risk—often a lot of both. And compressing a schedule is often only achieved at the expense of the people doing the work—increasing their stress levels and overall frustration with their job.

There are two key ways to compress a schedule:

- fast tracking—A schedule compression technique in which “activities that would have been performed sequentially using the original schedule are performed in parallel. In other words, fast tracking a project means the activities are worked on simultaneously instead of waiting for each piece to be completed separately. But fast tracking can only be applied if the activities in question can actually be overlapped” (Monnappa 2017). For example, when building a new house, you might be able to overlap pouring the concrete for an exterior patio and shingling the roof, but you can’t overlap digging the foundation for the house and shingling a roof that has not yet been built.

- crashing—This technique involves adding resources such as overtime or more equipment to speed up the schedule. Because of the costs involved in adding resources, crashing is “the technique to use when fast tracking has not saved enough time on the project schedule. With this technique, resources are added to the project for the least cost possible. Cost and schedule tradeoffs are analyzed to determine how to obtain the greatest amount of compression for the least incremental cost” (Monnappa 2017). Note that crashing is not typically effective with IT projects.

The important thing to remember when attempting to compress a schedule it that you need to focus on compressing the critical path. It doesn’t do any good to speed up tasks that aren’t on the critical path. According to an early, but still useful article about CPM, you can think of the critical path as the “bottleneck route:”

Only by finding ways to shorten jobs along the critical path can the overall project time be reduced; the time required to perform noncritical jobs is irrelevant from the viewpoint of total project time. The frequent (and costly) practice of “crashing” all jobs in a project in order to reduce total project time is thus unnecessary. Typically, only about 10% of the jobs in large projects are critical. (This figure will naturally vary from project to project.) Of course, if some way is found to shorten one or more of the critical jobs, then not only will the whole project time be shortened but the critical path itself may shift and some previously noncritical jobs may become critical. (Levy, Thompson and Wiest 1963)

Brooks’ Law and Agile Development

In his seminal book The Mythical Man-Month, Fred Brooks explains that crashing a schedule doesn’t work in software development because: 1) people need time (often a lot of time) to get up to speed on a project; 2) as you add more people to a project, you increase the amount of communication required, which reduces everyone’s productivity; and 3) software development tasks can’t be subdivided into smaller tasks the way physical tasks such as painting a house can be. His entire argument can be boiled down to one widely quoted line, known as Brooks’ Law: “Adding manpower to a late software project makes it later” (1975, 25).

Dave Pagenkopf, an Application Development & Integration Director at the UW-Madison, explains how Agile software development offers an alternative to the painful realities of Brooks’ Law:

Early in my career, like many software engineers, I didn’t see how Brooks Law could possibly be true. But as I began to lead software projects, I began to see first-hand the problems that come with crashing a software development schedule. One of the reasons that I prefer Agile so much is that the approach keeps options open when a project is behind schedule. To hit a date in an Agile project, you can reduce the scope (keeping in mind that you can always add more scope later). An Agile software project that is 80% completed is likely still useful. A waterfall software project that is 80% completed is likely useless.

Here are a few tips to keep in mind when attempting to compress a schedule:

- Engage the entire team in searching for opportunities with the largest time/cost impact.

- Look for ways to increase concurrency, and for activities in which increasing assigned resources will shorten the activity’s duration.

- Consider offering incentives for early completion. This is common, for example, in some highway projects, in which contractors are charged for every day that a lane is closed, or a bonus for completing the project early. This gives the contractors incentives to minimize the amount of lane closures at any given time.

- Not all activities have equal value to project delivery. Some are merely “nice to have” activities. This is often true in open-ended projects, such as product development projects. Once you get to work shortening a project plan, you may be surprised by how much you can cut out without significantly affecting final deliverables.

- Make schedule compression changes carefully, always keeping in mind that schedule compression can add risk. Make sure you thoroughly understand the eliminated activities to ensure you don’t miss something crucial.

- Although CPM presumes a geometric order approach to planning and scheduling, it is not blind to the uncertainties that can arise in any project. A typical CPM schedule specifies the slack (or float), associated with each activity, thereby allowing leeway for activities that might run longer or take less time than expected.

7.5 Pull: Post-Its, Last Planner, and Agile

Now that you are familiar with CPM, the geometric order response to the demands of scheduling, let’s focus on the living order approach, pull scheduling. A pull schedule is by its very nature a work in progress. Creating it is a collaborative process, and it must be updated regularly in response to current conditions. As you saw in Lesson 6, an initial pull schedule is often created during a structured collaborative session with key project members using color-coded Post-it notes that can be removed or repositioned as necessary. The orange notes in Figure 7-1 represent deliverables; the yellow notes represent steps required to produce the deliverables. After all stakeholders agree, a schedule like this is typically translated into a digital format, such as Microsoft Project or Microsoft Excel.

Figure 7-1: Pull schedules are often created with Post-it Notes on a white board (Source: John Nelson)

In a pull schedule, it is essential to define the project’s deliverables and handoffs, which, cumulatively, add up to the project’s outcome. That’s why color-coded Post-it notes are so useful; they allow you to see all the project’s deliverables at a glance. A pull schedule also makes it easy to see the steps required to produce a deliverable, and to identify when the handoff to the next phase of the project occurs. As in a relay race, where runners pass the baton from one to the other, the handoffs are crucial to a project’s success. If a runner drops the baton, it often doesn’t matter how quickly she ran her leg of the race, because the other runners will never be able to make up for the time lost in retrieving the dropped baton. The same is true in living order project management, in which the flow of work from one phase to the next is of paramount concern, and in which successful handoffs between phases can mean the difference between a project that fails or succeeds.

Creating a Pull Schedule

You can create a pull schedule electronically, using any number of scheduling programs. But to encourage the kind of collaborative conversations that encourage all stakeholders to become pull thinkers, it’s helpful to start by gathering all stakeholders in a room with a large white board (or an entire wall) set aside to use as the schedule work area. Working backwards from a target completion date, stakeholders place color-coded Post-it notes on the schedule to indicate when they will complete various tasks. No participant is allowed to move another participant’s Post-it note. Instead, as scheduling conflicts become apparent, stakeholders need to negotiate with each other, repositioning Post-it notes only after stakeholders agree on a solution to each scheduling problem.

Because the people creating the schedule are the actual people responsible for the various activities, the process inevitably focuses on activities that are dependent on other activities. For example, passage of a key internal user test for new software would need to precede release of the software to an expanded beta test group. The end result of this kind of planning is a schedule with far greater team buy-in than can be produced with CPM alone.

Post-it Note Planning

The word is out about the power of Post-it notes in the world of project management. Innovators in many fields now advocate using sticky notes as an essential tool for brainstorming and stirring up creativity, as well as for scheduling and planning. Here are some resources with tips for taking advantage of these powerful pieces of paper:

- “Why Post-It Notes Might be the Most Important Tool for Product Managers.”

- “ How The Post-it Note Could Become The Latest Innovation Technology .”

- “Post-It Meeting Tools and Tactics.”

The step-by-step process of creating a pull schedule is hard to grasp in the abstract. To really learn how it works, you have to do it. But you can get a better sense of the steps involved in pull scheduling by watching these videos:

- A quick three-minute introduction to pull planning schedules in construction: “Pull Planning: Miron Construction Co.”

- A more in-depth, 30-minute discussion: “Pull Planning: Lean Construction.”

- Although essentially an ad for a company that sells supplies related to pull planning, this one-minute video shows one way to organize a room for pull scheduling: Pull Planning Kit: Big Room Supplies.

Varieties of Pull Scheduling

Pull scheduling, in the form of the Last Planner System (LPS) is essential to Lean. The goal of the LPS is “to produce predictable work flow and rapid learning in programming, design, construction, and commissioning of projects” (Lean Construction Institute n.d.).

The five main elements of the LPS include:

- Master Scheduling (setting milestones and strategy; identification of long lead items);

- Phase “Pull” planning (specify handoffs; identify operational conflicts);

- Make Work Ready Planning (look ahead planning to ensure that work is made ready for installation; re-planning as necessary);

- Weekly Work Planning (commitments to perform work in a certain manner and a certain sequence); and

- Learning (measuring percent of plan complete (PPC), deep dive into reasons for failure, developing and implementing lessons learned). (Lean Construction Institute)

Note that these elements are similar to Agile scrum, which is not surprising given that the LPS and Agile both emerged from Lean. Also, these five elements of LPS tie back to the concept of rolling wave planning, described in Lesson 6.

Schedules in the LPS focus on the last responsible moment, which is the “instant in which the cost of the delay of a decision surpasses the benefit of delay; or the moment when failing to make a decision eliminates an important alternative” (Lean Construction Institute). The last responsible moment is similar to choosing when to make an airline reservation. You want to wait long enough to know enough details to avoid costly changes and you want to take advantage of possible sale prices, but you also want to avoid cost increases and fully booked flights in the weeks just before travel. You choose the last responsible moment to book your travel using acquired knowledge and expectations about the future. In a construction site, there may be an LRM for finalizing excavation, another LRM for setting the forms, and yet another LRM for pouring the concrete.

Project managers who are new to LPS scheduling find this focus on the last responsible moment to be counter-intuitive, because once we identify the critical path, our intuition tells us to move things along the critical path as fast as possible. However, this presumes that you know everything there is to know about a project at the very beginning, which of course is never the case. In fact, focusing on the critical path sometimes causes us to do things earlier than we need to, which can lead to mistakes and rework as the needs of the project become clearer. In living order, we see projects as knowledge collection experiences, and therefore strive to put off doing any task until it is absolutely necessary. The LPS forces you to ask the question “How long can I defer this until I absolutely have to do it, because something else depends on it?”

When creating schedules in a Lean manufacturing environment, reducing batch sizes is an essential concept. Rather than scheduling a series of tasks to be completed once on a large batch, the small batch approach schedules many passes through the same series of tasks. This approach is more flexible and eliminates waste, ultimately increasing overall efficiency. It has been used successfully in paper mills, steel mills, and other industries (Preactor 2007). For more on small-batch scheduling, see this blog post: “Batch Scheduling in a Lean Manufacturing World.”

In all industries, a well-thought-out schedule—one that stakeholders can rely on—forms the basis for the formal commitments between team members that, in the world of Lean and the LPS, are known as reliable promises. As you learned in Lesson 5, a reliable promise is predicated on a team member’s honest assessment that she does indeed have the authority, competence, and capacity to make a promise, and a willingness to correct if she fails to follow through. A reliable promise identifies when a handoff will occur and the expectation that the receiver can be assured that the handoff will be complete and of the expected quality. For example, in the course of a project, stakeholders might make reliable promises regarding the completion of a required report, completion of a portion of software, or completion of a subcontractor’s work on a designated portion of a building.

7.6 The Critical Path in Living Order

In any undertaking, keeping track of the sequence of activities that must be completed to ensure that a project is concluded on time is essential. Indeed, in some situations, identifying and monitoring the critical path using CPM is a contractual obligation. This is most common in governmental work, especially in construction projects for departments of transportation.

But in highly fluid, living order situations, it’s important to ask exactly how much time and effort you should spend keeping track of the critical path. CPM advocates would argue your primary job as a project manager is to monitor the critical path. But some experts experienced in managing large, highly complex projects argue that focusing too much on the critical path can be counterproductive.

In their insightful paper, “The Marriage of CPM and Lean Construction,” two experienced Boldt company executives—Bob Huber, scheduling manager, and Paul Reiser, vice president of production and process innovation—look at the scheduling process through the lens of Lean. True to their experience in Lean construction techniques pioneered by the Boldt company, they start by asking the essential question of any Lean enterprise: what value does it provide? Their analysis shows that a schedule provides different value to different stakeholders. For the owner, the “value received from the schedule is the ability to communicate project duration and financing needs to upstream and downstream interested parties.” The value provided to other stakeholders include “project duration, impacts to adjacent facilities, expectations for the timing of engineering deliverables, crew flow map, just-in-time delivery opportunities” (2003).

For stakeholders primarily interested in project duration, the critical path is a special focus. But not everyone involved in a project requires minute details on the status of activities on the critical path. Huber and Reiser argue that, on a construction site, providing constant schedule updates using the complicated software available to manage CPM schedules wastes one of the most important resources available on any project: the attention of project stakeholders.

The explosive growth in the capability and sophistication of computer-based project management software over the last few decades has not been closely matched by a parallel interest in or need for the data and analysis that they provide. This is especially true of the interests and needs of the front-line production manager on a construction site. The planning effort, as it demands time and energy from the front-line managers, has to compete with day-to-day project requirements for safety and environmental considerations, scope management, financial management, labor relations, owner relations, procurement, payroll, and documentation. In this competitive environment, the competition being that for the attention of the front-line production manager, the CPM schedule must necessarily deliver its value quickly and efficiently or it faces the distinct possibility of losing out to other persistent demands on the manager’s time and attention. Just because we can create an extremely detailed WBS-based resource loaded and leveled schedule and just because we can report its content in a mind-numbing array of diagrams, charts, and graphs doesn’t mean we should. In fact, practiced as an interactive discussion of crew flow and site coordination needs, with data captured and analyzed for alignment with project needs in real time, the CPM scheduling process can fulfill its assigned functions very efficiently. The test should always be whether the CPM schedule is delivering value and being readily consumed by the site production controllers. (Huber and Reiser 2003)

John Nelson, adjunct professor of Engineering at the UW-Madison, and a veteran of many years in the construction industry, argues that an excessive focus on the critical path can derail a project’s chance of success: “Most critical path projects don’t meet their milestones. Most living order projects which ignore critical path do meet their milestones. An excessive focus on the critical path uses up too much energy; everyone is working on updating the critical path without actually getting anything done.”

Still, he explains, all forms of scheduling have their benefits. “Instead of just focusing on one way of thinking about a schedule, you should take advantage of all the scheduling techniques available: critical path, push, pull, and so on. If you use all these techniques to stress-test your conceptual understanding of the project, then you’re going to have a higher probability of success. And always keep in mind that a schedule conceived in one situation may have to be thrown out if externalities intervene. That’s the nature of living order. This is a special concern with CPM. If you try to manage to a critical path that was conceived under different circumstances, you have a lower probability of meeting your goals.”

7.7 Focus on Milestones

One way to avoid getting lost in a sea of details is to focus on your project’s milestones, which can serve as a high-level guide. You can use pull planning to identify your project’s milestones, and then use critical path to figure out how to hit those milestones. It gives a reality test to whether your milestones are in fact achievable. Then you’re off and running, in living order.

In an excellent blog post on the usefulness of milestones, Elizabeth Harrin explains that milestones should be used “as a way of showing forward movement and progress and also show people what is going on, even if they don’t have a detailed knowledge of the tasks involved to get there. In that respect, they are very useful for stakeholder communication and setting expectations” (Harrin 2017). You can use milestones, she explains, to track your progress, focusing on

- The start of significant phases of work

- The end of significant phases of work

- To mark the deadline for something

- To show when an important decision is being made. (Harrin 2017)

Milestones are especially useful as a form of communication on the health of a project. A version of a project schedule that consists only of milestones allows stakeholders to get a quick sense of where things stand. As you’ll learn in Lesson 11, you’ll also want to report on milestones in the project’s dashboard, which should serve as an at-a-glance update for the project.

~Practical Tips

- Make sure you understand the difference between a plan and a schedule: The relationship between a plan and a schedule is similar to the relationship between a plan for a trip, which spells out general goals, and the trip itinerary, which defines how and when you will get from one stop to the next and complete the trip within available time. A project plan has to include some consideration of time, but it doesn’t need to go into details.

- Creating a schedule can help you organize your thoughts: Creating a schedule is typically a practical endeavor, focused on planning actual work. However, you can also create a schedule as a way of organizing your thoughts and sharing what you have learned about the project.

- Develop a schedule at the detail necessary to plan and coordinate: Planning beyond the necessary detail adds no value. A schedule pitched at too high a level runs the risk of missing key activities or identifying critical risks. A schedule that’s too comprehensive becomes a burden to update and can make it hard for team members to track activities, thus making it of little practical value.

- Think of a schedule as a tool for communicating with stakeholders: Above all else, a schedule is a communication tool, devised to keep stakeholders up to date about all current knowledge about the project. That means it is a living document that can’t be considered final until the project is finished. A schedule should be updated regularly and revised to incorporate the latest knowledge and information as the project advances. Strive to develop and communicate the project schedule in a manner that is most helpful to project participants.

- Planning for perfect execution inevitably leads to delays: Always plan for the imperfections of reality. Draw on your own past experience when you review a schedule to help you decide if it is realistic. If you don’t have any relevant past experience, then consult with someone who does. You might find it helpful to talk to a more experienced colleague. You can also draw on the many resources available within your industry.

- From time to time ask yourself this important question: What is a reasonable number of activities for a single project? There’s no hard and fast answer to this question, as all projects are different and require differing degrees of activity definition. But as a rule of thumb, most people can successfully keep track of 30-50 activities. More than that and they start getting lost in the detail. Other team members might have sub-tasks of 30-50 activities, meaning an overall plan may have hundreds of rolled-up activities.

- Understand the relationship between resource allocation and the critical path: In many cases, the critical path is only valid once resources have been allocated. If resources are over-allocated, the critical path might give you a false sense of security.

- Do not schedule a task too early in the project, just because it’s on the critical path: Focusing on the critical path sometimes causes us to do things earlier than we need to, which can lead to mistakes and rework as the project constraints become clearer. In living order, we see projects as knowledge collection experiences and therefore avoid starting activities prematurely.

- A schedule does not guarantee project success: Creating and updating a schedule is an ongoing process that must be adapted to externalities and needs of the customer and used to align stakeholders.

~Summary

- A schedule is a specific, time-based map designed to help the project team get from the current state to successful project completion. Whereas a plan is like a football coach’s strategy for winning, a schedule is all about tactics. Above all else, it is a form of communication with everyone involved in the project. It should contain just the right amount of detail.

- Making sure all stakeholders use the same terminology is crucial in all phases of project management, but it’s especially important when you are trying to get a group of diverse people to agree to a schedule. Important terms related to scheduling include milestone, activity, duration, resource, cost, and slack.

- Scheduling is a phase of project management that necessarily blends geometric and living order. The planning and scheduling technique most closely associated with push planning and the geometric order is the critical path method (CPM). The scheduling technique that best exemplifies living order principles is a pull schedule created collaboratively by stakeholders, typically by using multi-colored Post-it notes. Details of this type of scheduling have been codified in the Last Planner System and in Agile.

- The Critical Path Method (CPM) focuses on identifying the critical path of activities required to ensure project success, and then closely monitoring the activities on the critical path through the entire project. CPM is especially useful for large, complex projects where schedule interrelationships may not be readily apparent. It is the ultimate geometric order tool for project management and can lure you into a false sense of security regarding the predictableness of a project. However, it can be very helpful when you need to compress a schedule by fast tracking or crashing.

- A pull schedule is by its very nature a work in progress. Creating it is a collaborative process, and it must be updated regularly in response to current conditions. An initial pull schedule is often created using color-coded Post-it notes that can be removed or repositioned as necessary. Pull scheduling, in the form of the Last Planner System (LPS) is essential to Lean. Schedules in the LPS focus on the last responsible moment and rely on the use of reliable promises.

- In some situations, especially in governmental work, monitoring the critical path is a contractual obligation. But it is possible to overemphasize the critical path, thereby wasting the energy and attention of project stakeholders.

- Focusing on project milestones is a good way to provide a high-level schedule that is useful for most stakeholders.

~Glossary

- activity—“An element of work performed during the course of a project. An activity normally has an expected duration, an expected cost, and expected resource requirements” (Project-Management.com 2016). Beware that some organizations subdivide activities into tasks, while others use task and activity synonymously.

- compress a schedule—The process of taking a schedule you have already developed and reducing it without adjusting the project’s scope.

- cost—“An expenditure, usually of money, for the purchase of goods or services” (Law 2016).

- crashing—A schedule compression technique that involves adding resources such as overtime or more equipment to speed up the schedule. Because of the costs involved in adding resources, crashing is “the technique to use when fast tracking has not saved enough time on the project schedule. With this technique, resources are added to the project for the least cost possible” (Monnappa 2017).

- critical path—The “series of activities which determines the earliest completion of the project” (Project-Management.com 2016).

- duration—“The time needed to complete an activity, path, or project” (Larson and Gray 2011, 659).

- fast tracking—A schedule compression technique in which “activities that would have been performed sequentially using the original schedule are performed in parallel. In other words, fast tracking a project means the activities are worked on simultaneously instead of waiting for each piece to be completed separately. But fast tracking can only be applied if the activities in question can actually be overlapped” (Monnappa 2017).

- float—See slack.

- Last Planner System (LPS)—A proprietary production planning system that exemplifies living order concepts and pull thinking; developed by Glenn Ballard and Greg Howell as a practical implementaion of Lean principles.

- last responsible moment—“The instant in which the cost of the delay of a decision surpasses the benefit of delay; or the moment when failing to make a decision eliminates an important alternative” (Lean Construction Institute).

- milestone—“A significant event in the project; usually completion of a major deliverable” (State of Michigan: Department of Technology, Management & Budget).

- path—“A sequence of connected activities” (Larson and Gray 2011, 662).

- reliable promise—In Lean and the Last Planner System, a formal commitments between team members. As defined by the Lean Construction Institute, “A promise made by a performer only after self-assuring that the promisor (1) is competent or has access to the competence (both skill and wherewithal), (2) has estimated the amount of time the task will take, (3) has blocked all time needed to perform, (4) is freely committing and is not privately doubting ability to achieve the outcome, and (5) is prepared to accept any upset that may result from failure to deliver as promised” (Lean Construction Institute n.d.).

- resource—“Any personnel, material, or equipment required for the performance of an activity” (Project-Management.com 2016).

- schedule—A specific, time-based map designed to help the project team get from the current state to successful project completion. A schedule should build value, have an efficient flow, and be driven by pull forces.

- slack— “Calculated time span during which an event has to occur within the logical and imposed constraints of the network, without affecting the total project duration” (Project-Management.com 2016). Or put more simply, slack, which is also called float, is the “amount of time that a task can be delayed without causing a delay” to subsequent tasks or the project’s ultimate completion date (Santiago and Magallon 2009).

- sprint—In Agile project management, a brief (typically two-week) iterative cycle focused on producing an identified working deliverable (e.g., a segment of working code).

- task—See activity.

~References

Brooks, Jr., Frederick P. 1975. The Mythical Man-Month. Boston: Addison-Wesley.

Harrin, Elizabeth. 2017. “Learn What a Project Milestone Is.” The Balance Careers. October 13. https://www.thebalance.com/what-is-a-project-milestone-3990338.

Huber, Bob, and Paul Reiser. 2003. The Marriage of CPM and Lean Construction. The Boldt Company.

Larson, Erik W., and Clifford F. Gray. 2011. Project Management: The Managerial Process, Sixth Edition. New York: McGraw-Hill Education.

Law, Jonathan, ed. 2016. A Dictionary of Business and Management. Oxford: Oxford University Press. https://books.google.com/books?id=w3owCwAAQBAJ&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false.

Lean Construction Institute. n.d. “Glossary.” Lean Construction Institute. Accessed July 1, 2018. http://www.leanconstruction.org/training/glossary/#l.

—. n.d. “The Last Planner.” Lean Construction Institute. Accessed July 1, 2018. http://www.leanconstruction.org/training/the-last-planner/.

Levy, F. K., G. L. Thompson, and J. D. Wiest. 1963. “The ABCs of the Critical Path.” Harvard Business Review. https://hbr.org/1963/09/the-abcs-of-the-critical-path-method.

Monnappa, Avantika. 2017. “Project Management Learning Series: Fast Tracking versus Crashing.” Simplilearn. December 19. https://www.simplilearn.com/fast-tracking-vs-crashing-article.

Preactor. 2007. “Batch Scheduling in a Lean Manufacturing World.” Preactor. February. http://www.preactor.com/Batch-Scheduling-in-a-Lean-Manufacturing-World.

Project-Management.com. 2016. “PMO and Project Management Dictionary.” PM Project Management.com. December 16. https://project-management.com/pmo-and-project-management-dictionary/.

Rouse, Margaret. 2015. “Critical Path Method (CPM).” WhatIs.TechTarget.com. January. http://whatis.techtarget.com/definition/critical-path-method-CPM.

State of Michigan: Department of Technology, Management & Budget. 2013. “Project Management Key Terms, Definitions and Acronyms.” August. https://www.michigan.gov/documents/suite/PM_KeyTerms_Defs_Acronyms_080213_431285_7.pdf.

8

Managing Project Risks

I may say that this is the greatest factor—the way in which the expedition is equipped—the way in which every difficulty is foreseen, and precautions taken for meeting or avoiding it. Victory awaits him who has everything in order—luck, people call it. Defeat is certain for him who has neglected to take the necessary precautions in time; this is called bad luck.

—Roald Amundsen, Norwegian polar explorer (The South Pole: An Account of the Norwegian Antarctic Expedition in the “Fram,” 1910-1912, 370)

Objectives

After reading this lesson, you will be able to

- Distinguish between risks and issues

- Identify types of risks, and explain how team members’ roles can affect their perception of risk

- Compare traditional, geometric-order risk management with a living-order approach

- Discuss risks associated with product development and IT projects

- Explain the concept of a black swan event and its relevance to risk management

- Discuss the connections between ethics and risk management

The Big Ideas in this Lesson

- A risk is a specific threat to a project multiplied by the consequences if the threat materializes. With risk comes opportunity and new possibility, as long as you can clearly identify the risks you face and employ reliable techniques for managing them.

- The living-order approach to risk management emphasizes sharing risk, with the most risk assigned to the party best able to manage it and most likely to benefit from it. By contrast, the more traditional, geometric order approach to risk focuses on avoiding it, shifting it to other parties whenever possible.

- A risk is caused by external factors that the project team cannot control, whereas an issue is a known concern—something a team will definitely have to address.

8.1 Identifying Risks

Most people use the term risk to refer to something bad that might happen, or that is unavoidable. The connotations are nearly always negative. But in fact, with risk comes opportunity and new possibility, as long as you can clearly identify the risks you face and employ reliable techniques for managing them. Risks can impact a project’s cost and schedule. They can affect the health and safety of the project team or the general public, as well as the local or global environment. They can also affect an organization’s reputation, and its larger operational objectives.

More Risk-Related Terms

Risk Capacity: The maximum amount of risk an organization can bear.

Risk Appetite: The maximum amount of risk an organization is willing to assume.

According to Larry Roth, Vice President at Arcadis and former Assistant Executive Director of the American Society of Civil Engineers, the first step toward identifying and managing risks is a precise definition of the term. He defines risk as “the probability that something bad will happen times the consequences if it does.” The likelihood of a risk being realized is typically represented as a probability value from 0 to 1, with 0 indicating that the risk does not exist, and 1 indicating that the risk is absolutely certain to occur. According to Roth, the term tolerable risk refers to the risk you are willing to live with in order to enjoy certain benefits (pers. comm., April 23, 2018).

In daily life, we make risk calculations all the time. For example, when buying a new smartphone, you are typically faced with the question of whether to insure your new device. If you irreparably damage your phone, the potential consequence is the cost of a new phone—let’s say $500. But what is the actual probability of ruining your phone? If you are going to be using your phone in your office or at home, you might think the probability is low, and so choose to forgo the insurance. In this case, a risk analysis calculation might look like this:

0.2 X $500 = $100

In other words, you might decide that the risk of damaging your phone is a tolerable risk, one you are willing to live with. The benefit you gain from tolerating that risk is holding onto the money you would otherwise have to pay for insurance.

But what might make you decide that the risk of damaging the phone was not a tolerable risk? Suppose you plan to use your phone regularly on a boat. In that case, the chance of damaging it by dropping it in the water is high, and so your calculation might look like this:

0.99 X $500 = $495

For many people, this might make insurance might seem like a good idea.

Your tolerance of risk is partly a matter of personality and attitude. This article describes a range of attitudes toward risk, ranging from “risk paranoid” to “risk addicted”: https://www.pmi.org/learning/library/risk-management-expected-value-analysis-6134.

8.2 Threats, Issues, and Risks

Inexperienced project managers often make the mistake of confusing threats, issues, and risks. A threat is a potential hazard, such as dropping your phone in the water. A threat is not in itself a risk. A risk is the probability that the threat will be realized times the consequences.

On the other end of the uncertainty spectrum are issues, which are known potential problems that the project team will definitely have to keep an eye on. For example, the mere possibility of exceeding a project’s budget is not a risk. It’s a well-known issue associated with any project; part of managing the project is managing the budget. But if your particular project involves extensive use of copper wiring, then an increase in the price of copper is a direct threat to your project’s success, and the associated risk is the probability of higher copper prices times the consequences of such an increase. Team members cannot control the price of copper; it is a risk that you’ll have to respond to, making decisions in response to the changing situation.

Risk expert Carl Pritchard distinguishes between risks and issues as follows: “A risk is out there in the future, and we don’t know if it is going to happen; but if it does happen it will have an impact. Issues are risks realized. They are the risks whose time has come, so to speak” (Pritchard and Abeid 2013). That’s not to say that all issues used to be risks. And some things can be issues at an organizational level, but a risk when it comes to your particular project. Pritchard explains:

An issue in your organization may be that management changes its mind….If your management is constantly changing their minds, time and time and time again—that’s an issue. But for your particular project, they haven’t changed their mind yet. So for your project it’s still a risk. It’s a future phenomenon, because it hasn’t happened to you yet. You’re anticipating that eventually it will become an issue. But for now, at least, it’s still out there in the future. (Pritchard and Abeid 2013)

Table 8-1 compares issues, threats, and risks on different projects.

Project

Issue

Threat

Risk

Developing a new cell phone

The phone must be released on schedule or consumers will consider it obsolete.

Introduction of new features in a competing product, which would necessitate adding the same feature to your product.

The probability that a competitor will introduce a new feature times the consequences in time and money required to remain competitive.

Constructing a sea wall

The sea wall must be resilient even if exposed to the most severe storm surge that can be anticipated given our current knowledge.

Rising sea levels caused by climate change make it hard to predict the future meaning of the words “the most severe storm surge.”

The probability of sea levels rising higher than the sea wall times the monetary and safety consequences of flooding.

Constructing an addition to a clinic

Cost of capital has significant impact on capital project decision-making.

The Federal Reserve raises interest rates, increasing the cost of borrowing money for the project.

The probability of rising interest rates times the increase to overall project cost if interest rates do go up.

Table 8-1: Distinguishing between issues, threats, and risks

The Fine Art of Perceiving Risk

A quick perusal of recent articles published in Risk Management magazine hints at the vast array of risks facing modern organizations. If you were asked to generate your own list, you might include environmental disasters, financial setbacks, and data theft as obvious risks. But what about the more obscure dangers associated with patent translations or cyber extortion?

The following examines a few varieties of issues and related risks you might not have considered. Can you think of any issues and risks specific to your industry that you would add this list?

- Human capital: Turnover among team members is an inevitable issue on long-running projects. People will come and go, and you have to be prepared to deal with that. But some forms of turnover go beyond issues and are in fact real risks. For example, one human capital risk might be loss of a key manager or technical expert whose relationship with the client is critical to keeping the contract. Team members behaving unethically is another human capital risk. Suppose a member on a highway construction project is fired for taking a bribe. This could have effects that ripple through the entire team for a long time to come. Team members might feel that their professional reputations are at risk, or they might decide that the team’s manager is not to be trusted. Once team cohesion begins to crumble in this way, it can be hard to put things back together. Other human capital issues include catastrophic work events and negligent hiring practices (Lowers & Associates 2013). For example, the 2013 launch of HealthCare.gov failed, in part, because the project team lacked software developers with experience launching a vast, nationwide website. Meanwhile, departures of vital staff members at the agency responsible for overseeing the insurance marketplace also hampered progress (Goldstein 2016). These unidentified human capital risks brought the project to a standstill. It was ultimately saved by a “hastily assembled group of tech wizards” with the know-how required to get the website up and running (Brill 2014).

- Marketing: Project management teams often struggle to communicate with an organization’s marketing department. Rather than drawing on the marketing department’s understanding of customer needs, project teams often prefer to draw on their own technological know-how to create something cool, and then attempt to push the new product onto the market. But this can be a disaster if the new product reaches the market without the support of a fine-tuned marketing campaign. This is especially true for innovative products. For example, product developers might focus on creating the most advanced hardware for a smart thermostat, when in fact customers primarily care about having a software interface that’s easy to use. As in many situations, a pull approach—asking the marketing department to tell your team what the market wants—is often a better option. Of course, this necessitates a good working relationship with the marketing department, which is not something you can establish overnight. Sometimes a marketing risk takes the form of a product or service that only partly serves the customer’s needs. For example, one of the many problems with the rollout of the HealthCare.gov website, in 2013, was a design that “had capacity for just a fraction of the planned number of consumers who could shop for health plans and fill out applications”(Goldstein 2016).

- Compliance: In many cases, you’ll need to make sure your project complies with “rules, laws, policies, and standards of governance that may be imposed by regulatory bodies and government agencies.” Indeed, some projects are exclusively devoted to compliance tasks and can “range from implementation of employment laws to setting up processes and structures for meeting and reporting statutory tax and audit requirements to ensuring compliance with industry standards such as health and safety regulations” (Ram 2016). In any arena, the repercussions of failing to follow government regulations can be extreme. Ensuring compliance starts with learning what regulations apply to your particular project and staying up-to-date on changes to applicable laws. (For more on compliance projects, see this blog post by Jiwat Ram: https://www.projectmanagement.com/articles/351236/Compliance-Projects–Fragile–Please-Handle-with-Care-.) Keep in mind that safety concerns can evolve quickly, as was the case with Samsung’s Galaxy Note 7 phone; millions of phones had to be recalled and the company’s new flagship smartphone scrapped after lithium-ion batteries caused devices to catch fire (Lee 2016).

- Sustainability: Although businesses have always had to deal with issues associated with the availability of natural resources, in the past they rarely questioned the validity of a business model that presumed the consumption of vast amounts of natural resources. But as scientists provide ever more startling evidence that endless economic growth is not a realistic strategy for the human race, businesses have had to focus on issues related to sustainability if they want to survive. For one thing, people increasingly want to work for organizations they perceive as having a serious commitment to sustainability. Indeed, the need to recruit top talent in the automotive world is one motivation behind the on-going transformation of Ford’s Dearborn, Michigan campus into a sustainability showcase (Martinez 2016). Meanwhile, Ford’s $11 billion investment in electric vehicles is a bid to remain viable in foreign markets that have more stringent sustainability requirements than the United States (Marshall 2018). A report on sustainability risks by Wilbury Stratton, an executive search firm, lists some specific sustainability risks:

Social responsibility risks that threaten the license to operate a mining operation, risks tied to perceptions of over-consumption of water, and reputational risks linked to investments in projects with potentially damaging environmental consequences…. Additional trends in sustainability risk include risks to financial performance from volatile energy prices, compliance risks triggered by new carbon regulations, and risks from product substitution as customers switch to more sustainable alternatives. (2012)

- Complexity: Complex projects often involve risks that are hard to identify at the outset. Thus, complex projects often require a flexible, adaptable approach to risk management, with the project team prepared to respond to new risks as they emerge. Complex projects can be derailed by highly detailed plans and rigid controls which can “lock the project management team into an inflexible mindset and daily pattern of work that cannot keep up with unpredictable changes in the project. Rather than reduce risk, this will amplify it and reduce [the team’s] capacity to achieve [its] goals. The effort to control risk might leave the team trying to tame a tiger while stuck in a straitjacket” (Broadleaf 2016). Agile was specifically developed to deal with the challenges associated with the kinds of complexity found in IT projects. Pull planning also offers advantages in complex environments, in part because it forces team members to communicate and stay flexible.

Perhaps the hardest risks of all to prepare for are the risks that your training and professional biases prevent you from perceiving in the first place. As an engineer, you are predisposed to identify technical risks. You might not be quite as good at recognizing other types of risks. In Chapter 1 of Proactive Risk Management, Preston G. Smith and Guy M. Merritt list some risks associated with a fictitious product. The list includes marketing, sourcing, regulatory, and technical risks. In summing up, the authors point out two essential facts about the list of risks: “First, it is specific to this project and market at this point in time. Second, it goes far beyond engineering items” (2002, 2-3). Later in the book, in a chapter on implementing a risk management program, they have this to say about an engineer’s tendency to perceive only technical risks:

Good risk management is cross-functional. If engineers dominate product development, you might consider letting engineering run project risk management. This is a mistake. If you assign risk management to the engineering department and engage only engineers to identify, analyze, and plan for risks, they will place only engineering risks on their lists. (186)

How Team Members Perceive Risk

The role team members play in a project can hugely affect their perception of risk. According to David Hillson, a consultant and author of many books on risk, a project sponsor (upper management or the customer) and the project manager perceive things very differently:

- The project manager is accountable for delivery of the project objectives, and therefore needs to be aware of any risks that could affect that delivery, either positively or negatively. Her scope of interest is focused on specific sources of uncertainty within the project. These sources are likely to be particular future events or sets of circumstances or conditions which are uncertain to a greater or lesser extent, and which would have some degree of impact on the project if they occurred. The project manager asks, “What are the risks in my project?”….

- The project sponsor, on the other hand, is interested in risk at a different level. He is less interested in specific risks within the project, and more in the overall picture. Their question is “How risky is my project?”…. Instead of wanting to know about specific risks, the project sponsor is concerned about the overall risk of the project. This represents her exposure to the effects of uncertainty across the project as a whole.

These two different perspectives reveal an important dichotomy in the nature of risk in the context of projects. A project manager is interested in “risks” while the sponsor wants to know about “risk.” While the project manager looks at the risks in the project, the project sponsor looks at the risk of the project. (Hillson 2009, 17-18)

Even when you think you understand a particular stakeholder’s attitude toward risk, that person’s risk tolerance can change. For example, a high-level manager’s tolerance for risk when your organization is doing well financially might be profoundly different from the same manager’s tolerance for risk in an economic downturn. Take care to monitor the risk tolerance of all project stakeholders—including yourself. Recognize that everyone’s risk tolerances can change throughout the life of the project based on a wide range of factors.

8.3 Risk Management and Project Success

Successful project managers manage the differing perceptions of risk, and the widespread confusion about its very nature, by engaging in systematic risk management. According to the Financial Times, risk management is “the process of identifying, quantifying, and managing the risks that an organization faces” (n.d.). In reality, the whole of project management can be thought of as an exercise in risk management because all aspects of project management involve anticipating change and the risks associated with it.

The tasks specifically associated with risk management include “identifying the types of risk exposure within the company; measuring those potential risks; proposing means to hedge, insure, or mitigate some of the risks; and estimating the impact of various risks on the future earnings of the company” (Financial Times). Engineers are trained to use risk management tools like the risk matrix shown in Figure 8-1, in which the probability of the risk is multiplied by the severity of consequences if the risk does indeed materialize.

Figure 8-1: A risk matrix is a tool engineers often use to manage risk

This and other risk management tools can be useful because they provide an objective framework for evaluating the seriousness of risks to your project. But any risk assessment tool can do more harm than good if it lulls you into a false sense of security, so that you make the mistake of believing you really have foreseen every possible risk that might befall your project. You don’t want to make the mistake of believing that the tools available for managing risk can ever be as precise as the tools we use for managing budgets and schedules, even as limited as those tools are.

Perhaps the most important risk management tool is your own ability to learn about the project. The more you know about a project, the better you will be at foreseeing the many ways the project could go awry and what the consequences will be if they do, and the better you will be at responding to unexpected challenges.

The Risk of Failing to Define “Success” Accurately

Different people will have different interpretations of the nature of risks associated with a company’s future earnings, depending on how broadly one defines “success” and consequently the risks that affect the likelihood of achieving success. An example of a company failing to define “success” over the long term, with tragic consequences, is the 2010 BP spill, which poured oil into the Gulf of Mexico for 87 days.

This event, now considered one of the worst human-caused disasters in history, started with a methane explosion that killed 11 workers and ultimately sank the Deepwater Horizon oil rig. After the explosion, engineers counted on a specialized valve, called a blind shear ram, to stop the flow of oil. For reasons that are still not entirely understood, the valve failed, allowing the oil to pour unchecked into the Gulf. Despite the well-known vulnerability of the blind shear ram, and the extreme difficulties of drilling at a site that tended to release “powerful ‘kicks’ of surging gas,” BP chose not to install a backup on the Deepwater Horizon.

In hindsight, that now looks like an incredibly short-sighted design and construction decision, especially considering the fact that nearly all oil rigs in the gulf are equipped with a backup blind shear ram to prevent exactly the type of disaster that occurred on the Deepwater Horizon (Barstow, et al. 2010). The well’s installation might have been considered “successful” at the time of completion if it met schedule and budget targets. However, if BP had focused more on long-term protection of the company’s reputation and success, and less on the short-term economics of a single oil rig, the world might have been spared the Deepwater Horizon catastrophe. As companies venture into ever deeper waters to drill for oil, this type of risk management calculation will become even more critical.

A New Approach to Risk Management

In traditional, geometric order thinking, risk is a hot potato contractually tossed from one party to another. In capital projects in particular, risk has traditionally been managed through aversion rather than fair allocation. Companies do everything they can to avoid suffering the consequences of uncertainty. Unfortunately, this often results in parties being saddled with risk they can’t manage or survive. As explained in an interview with John Nelson, this often means that, in capital projects, customers are unsatisfied because

conflict inherent in improper risk allocation often results in expensive and unwanted outcomes, such as numerous RFIs [Requests for Information] and change orders, redesign, delays, spiraling project costs, loss of scope to “stay in budget,” claims and disputes, a changing cast of players, poorly functioning or unmaintainable designs, unmet expectations, productivity losses, and in a worst case: lawsuits. (Allen 2007)

The essential problem with traditional risk management in capital projects is that it forces each party to

act in its own interests, not in the common interest because there is no risk-sharing that binds together the owner, architect, and constructor. In the traditional model, the owner often unintentionally presumes he will get the minimum—the lowest quality of a component, system, etc.—that all the other project parties can get away with. So, when a problem occurs, such as a delay, each party naturally acts to protect their own interests rather than look for a common answer. (Allen 2007)

The traditional approach sees risk as something bad that must be avoided as much as possible. By contrast, a living order approach sees risk as a sign of opportunity, something essential to capitalism and innovation. Rather than tossing a hot potato of risk from stakeholder to stakeholder, a living order approach seeks a more equitable, holistic form of risk-sharing, with the most risk assigned to the party best able to manage it and most likely to benefit from it. In a capital project, for instance, the owner must assume “some of the risk because at the end of the day the owner has the long-term benefit of a completed facility” (Allen 2007).

Risk Management Calculations Can be Risky

In their book Becoming a Project Leader, Laufer et al. question the usefulness of risk management calculations, positing redundancies as a better method for handling unpredictable events in projects. They point to “Zur Shapira, who asked several hundred top executives (of permanent organizations, not of projects) what they thought about risk management, [and] found they had little use for probabilities of different outcomes. They also did not find much relevance in the calculate-and-decide paradigm. Probability estimates were just too abstract for them. As for projects, which are temporary and unique endeavors, it is usually not possible to accumulate sufficient historical data to develop reliable probabilities, even when the risky situation can be clearly defined” (Shapira 1995).

Laufer et al. also point to the expertise of Brian Muirhead from NASA, who “disclosed that when his team members were asked to estimate the probability of failures, ‘many people simplistically assigned numbers to this analysis—implying a degree of accuracy that has no connection with reality’” (Muirhead 1999).

Furthermore, Gary Klein, in his analysis “The Risks of Risk Management,” concluded unequivocally, “In complex situations, we should give up the delusion of managing risk. We cannot foresee or identify risks, and we cannot manage what we can’t see or understand” (Klein 2009). It therefore behooves us to build in some redundancies so that we’re able to cope with problems that may arise (Laufer, et al. 2018).

In a report on managing the extensive risks involved in highly complex infrastructure projects, Frank Beckers and Uwe Stegemann advocate a “forward-looking risk assessment” that evaluates risk throughout the project’s entire lifecycle. The questions they raise are helpful to ask about any type of project unfolding in living order:

- Forward-looking risk assessment: Which risks is the project facing? What is the potential cost of each of these risks? What are the potential consequences for the project’s later stages as a result of design choices made now?

- Risk ownership: Which stakeholders are involved, and which risks should the different stakeholders own? What risk-management issues do each of the stakeholders face, and what contribution to risk mitigation can each of them make?

- Risk-adjusted processes: What are the root causes of potential consequences, and through which risk adjustments or new risk processes might they be mitigated by applying life-cycle risk management principles?

- Risk governance: How can individual accountability and responsibility for risk assessment and management be established and strengthened across all lines of defense?

- Risk culture: What are the specific desired mind-sets and behaviors of all stakeholders across the life cycle and how can these be ensured? (Beckers and Stegemann 2013)

When thinking of risk and a project’s life cycle, it’s important to remember that many manufacturing companies, such as Boeing and John Deere, have begun focusing on making money from servicing the products they produce—putting them in the same long-term service arena as software developers. At these companies, project managers now have to adopt a greatly expanded view of a product’s life cycle to encompass, for example, the decades-long life span of a tractor. Living as we do in an era when time is constantly compressed, and projects need to be completed faster and faster, it can be hard to focus on the long-term risks associated with a product your company will have to service for many years.

All forms of business are in need of a radical rethinking of risk management. For starters, in any industry, it’s essential to collaborate on risk management early on, during project planning, design, and procurement. The more you engage all key stakeholders (e.g., partners, contractors, and customers) in the early identification of risks and appropriate mitigation strategies, the less likely you are to be blindsided later by unexpected threats.

In addition to paying attention to risk early, a good risk manager also practices proactive concurrency, which means intentionally developing an awareness of options that can be employed if things don’t work out. This doesn’t necessarily mean you need to have a distinct plan for every possible risk. But you should strive to remain aware of the potential for risk in every situation and challenge yourself to consider how you might respond.

At all times, be alert to consequences that are beyond your team’s control. Sometimes management’s definition of project success is tied to longer-term or broader outcomes, often involving things well outside the control of the project’s stakeholders. If you find yourself in that situation, do all you can to raise awareness of the consequences of a threat to the project being realized, emphasizing how they might affect the broader organization. It is then up to the senior management, who presumably has the authority and ability to influence wider aspects, to take action or make adjustments.

Product Development Risks

In product development, the most pressing risks are often schedule-related, where it is essential to get the product out to recover the initial investment and minimize the risk of obsolescence. In this environment, anything that can adversely affect the schedule is a serious risk. A less recognized product development risk is complacency: product designers become so convinced they have created the best possible product that they fail to see drawbacks that customers identify the second the product reaches the market.

An opportunity as the opposite of a threat. For example, anything that can positively affect a schedule is an opportunity.

This famously happened in 2010 with Apple’s iPhone 4, which tended to drop calls if the user interfered with the phone’s antenna by touching the device’s lower-left corner. At first, Apple chose to blame users, with Steve Jobs infamously advising annoyed customers, “Just avoid holding it that way” (Chamary 2016). Eventually, the company was forced to offer free plastic cases to protect the phone’s antenna, but by then the damage was done. Even die-hard Apple customers grew wary of the brand, the company’s stock price fell, and Consumer Reports announced that it could not recommend the iPhone 4 (Fowler, Sherr and Sheth 2010).

Product development firms are especially susceptible to market risks. Maintaining the power of a company’s brand is a major issue that can lead to numerous risks. One such risk is the erosion of a long-established legacy of consumer trust in a particular brand. A new, negative association (think of the Volkswagen emissions-control software scandal) can drive customers away, sabotaging the prospects for new products for years to come. Even changing a company logo presents great risks. This blog post describes redesign failures, some of which costs hundreds of millions of dollars: https://www.canny-creative.com/10-rebranding-failures-how-much-they-cost/. Another market risk is a sudden, unexpected shift in consumer preferences, as occurred in the 1990’s, when, in response to an economic downturn, consumers switched from national brand groceries to less expensive generic brand, and never switched back, even after the economy improved. These days, higher quality generic brands, such as Costco’s Kirkland brand, are big business—a development few analysts saw coming (Danziger 2017). Market risks can undermine all the good work engineers do in developing a product or service. For example, Uber engineers excelled in developing a system that employs geo-position analytics to enable vehicles, drivers, and riders to efficiently connect. However, the company failed to assess and address key market issues like rider safety, governmental approvals, and data security (Chen 2017).

In traditional product development, risk management is relegated to research and development, with marketing and other teams maintaining a hands-off approach. But as products grow more complex, this tendency to focus only on technical risks actually increases the overall risk of project failure. In the product development world, the risk of failure is increasingly dictated by when the product arrives in the marketplace, and what other products are available at that time. In other words, in product development, schedule risks can be as crucial, if not more crucial, than technical risks.

In an article adapted from his book Developing Products in Half the Time, Preston G. Smith argues, “When we view risk as an R&D issue, we naturally concentrate on technical risk. Unfortunately, this guides us into the most unfruitful areas of risk management, because most products fail to be commercially successful due to market risks, not technical risks.” Even at companies that tend to look at the big picture, “engineers will tend to revert to thinking more narrowly of just technical risk. It is management’s job to keep the perspective broad” (1999). Companies that lack the broad perspective end up piling risk on risk.

Although others may think of risk as solely a technical issue and attribute it to the R&D department, most risk issues have much broader roots than this. If you treat development risk as R&D-centric, you simply miss many risks that are likely to materialize later. If others try to place responsibility for product-development risk on R&D, they unwittingly mismanage the problem. (Smith 1999)

Smith advocates for a proactive approach to risk management in which companies identify threats early and work constantly to “drive down” the possibility of a threat actually materializing, while staying flexible on unresolved issues as long as possible. He provides some helpful risk management techniques that you can read about on pages 30-32 of this article: http://www.strategy2market.com/wp-content/uploads/2014/05/Managing-Risk-As-Product-Development-Schedules-Shrink.pdf.

IT Risks

The IT world faces a slew of risks related to the complexity of the products and services it provides. As a result, IT projects are notoriously susceptible to failure. In fact, a recent survey reported a failure rate of over 50% (Florentine 2016). This figure probably under reports the issue because it focuses on the success rate for IT projects in the short run—for example, whether or not developers can get their software up and running. But as software companies rely more and more on a subscription-based business model, the long-term life cycle of IT products becomes more important. Indeed, in a world where software applications require constant updates, it can seem that some IT projects never end. This in turn, raises more risks, with obsolescence an increasing concern. Add to this the difficulties of estimating in IT projects and the cascading negative effects of mistakes made upfront in designing software architecture, and you have the clear potential for risk overload.

By focusing on providing immediate value, Agile helps minimize risk in software development because the process allows stakeholders to spot problems quickly. Time is fixed (in preordained sprints), so money and scope can be adjusted. This prevents schedule overruns. If the product owner wants more software, she can decide this bit-by-bit, at the end of each sprint.

In a blog post about the risk-minimizing benefits of Agile, Robert Sfeir writes,

Agile exposes and provides the opportunity to recognize and mitigate risk early. Risk mitigation is achieved through cross-functional teams, sustainable and predictable delivery pace, continuous feedback, and good engineering practices. Transparency at all levels of an enterprise is also key. Agile tries to answer questions to determine risk in the following areas, which I will discuss in more detail in a future post:

- Business: Do we know the scope? Is there a market? Can we deliver it for an appropriate cost?

- Technical: Is it a new technology? Does our Architecture support it? Does our team have the skills?

- Feedback (verification & validation): Can we get effective feedback to highlight when we should address the risks?

- Organizational: Do we have what we need (people, equipment, other) to deliver the product?

- Dependency: What outside events need to take place to deliver the project? Do I have a plan to manage dependencies? (2015)

Keep in mind that in all industries, simply identifying threats is only the first step in risk management. Lots of time and money could be lost by failing to understand probabilities and consequences, causing your team to place undue management focus on threats that have a low probability of occurrence, or that may have minimal impact.

Monetizing Risk

One way to manage risk is to monetize it. This makes sense because risk usually manifests itself as additional costs. If a project takes longer than expected or requires additional resources, costs go up. Thus, to fully understand the impact of the risks facing a particular project, you may need to assign a dollar value to (that is, monetize) the potential impact of each risk. Monetizing risks gives outcomes “real economic value when the effects might otherwise be ignored” (Viscusi 2005). Once you’ve monetized a project’s risks, you can rank them and make decisions about which deserves your most urgent attention. Every industry has its own calculations for monetizing risks. For example, this article includes a formula for monetizing risks to networks and data: http://www.csoonline.com/article/2903740/metrics-budgets/a-guide-to-monetizing-risks-for-security-spending-decisions.html.

Keep in mind that monetizing certain risks is controversial. In some instances, it is acceptable or even required. One example is the value of a statistical life, which is “an estimate of the amount of money the public is willing to spend to reduce risk enough to save one life.” The law requires U.S. government agencies to use this concept in “a cost-benefit analysis for every regulation expected to cost $100 million or more in a year” (Craven McGinty 2016).

This article describes the varying ways society directly or indirectly values human lives:
http://www.nytimes.com/2007/09/09/weekinreview/09marsh.html

In other circumstances, most notably in product safety, it is clearly unethical to make a decision based strictly on monetary values. An example of this is the famous decision by Ford Motor Company in the early 1970’s to forgo a design change that would have required retooling the assembly line to reduce the risk of death and injury from rear impacts to the Ford Pinto car. The company’s managers made this decision based on a cost-benefit analysis that determined it would be cheaper to go ahead and produce the faulty car as originally designed, and then make payments as necessary when the company would, inevitably, be sued by the families of people killed and injured in the cars. Public outrage over this decision and the 900 deaths and injuries caused by the Pinto’s faulty fuel tank clearly demonstrated the need for product safety design decisions to be based on broader considerations than a simple tradeoff analysis based on the cost of improved design versus an assigned value for the value of lives saved.

8.4 Reporting on Risks

Every well-run organization has its own process for reporting on threats as a project unfolds. In some projects, a weekly status report with lists of threats color-coded by significance is useful. In others, a daily update might be necessary. In complicated projects, a project dashboard, as described in Lesson 11, is essential for making vital data visible for all concerned.

The type of contract binding stakeholders can affect everyone’s willingness to share their concerns about risk. In capital projects, the traditional design/bid/build arrangement tends to create an adversarial relationship among stakeholders. As David Thomack, Chief Operating Officer at Suffolk Construction, explained in a lecture on Lean and project delivery, this type of arrangement forces stakeholders to take on adversarial roles to protect themselves from blame if something goes wrong (2018). This limits the possibilities for sharing information, making it hard to take a proactive approach to project threats, which would in turn minimize risk throughout the project. Instead, stakeholders are forced to react to threats as they arise, an approach that results in higher costs and delayed schedules. By contrast, a more Lean-oriented contractual arrangement like Integrated Project Delivery, which emphasizes collaboration among all participants from the very earliest stages of the project, encourages participants to help solve each other’s problems, taking a proactive approach to risk (2018). In this environment, it’s in everyone’s best interests to openly acknowledge risks and look for ways to mitigate them before they can affect the project’s outcome.

Whatever process your organization and contract arrangement requires, keep in mind that informing stakeholders or upper management about a threat is meaningless if you do it in a way they can’t understand, or if you don’t clarify exactly how urgent you perceive the risk to be. When deciding what to include in a report, think about what you expect your audience to be able to do with the information you provide. And remember to follow up, making sure your warning has been attended to.

As a project manager, you should focus on 1) clearly identifying risks, taking care not to confuse project issues with risks, and 2) clearly reporting the status of those risks to all stakeholders. If you are reporting on risks that can affect the health and safety of others, you have an extra duty to make sure those risks are understood and mitigated when necessary.

Here are two helpful articles with advice on managing and reporting project risks:

- https://www.pmi.org/learning/library/methods-managing-project-risks-issues-8233

- https://www.girlsguidetopm.com/tips-for-risk-and-issue-reporting/

8.5 The Big Picture is Bigger than You Think

If, as a risk manager, you spend all your time on a small circle of potential risks, you will fail to identify threats that could, in the long run, present much greater risks. And then there’s the challenge of calculating the cost of multiple risks materializing at the same time, i.e., a perfect storm of multiple, critical risks materializing simultaneously. In such a situation, calculating risks is rarely as simple as summing up the total cost of all the risks. In other words, you need to keep the big picture in mind. And when it comes to risk, the big picture is nearly always bigger than you think it is.

Nassim Nicholas Taleb has written extensively about the challenges of living and working in a world where we don’t know—indeed can’t ever know—all the facts. In his book Black Swan: The Impact of the Highly Improbable, he introduces his theory of the most extreme form of externality, which he calls a black swan event. According to Taleb, a black swan event has the following characteristics: First, it is an outlier, as it lies outside the realm of regular expectations, because nothing in the past can convincingly point to its possibility. Second, it carries an extreme impact. Third, in spite of its outlier status, human nature makes us concoct explanations for its occurrence after the fact, making it explainable and predictable (2010, xxii) .

He argues that it is nearly impossible to predict the general trend of history, because history-altering black swan events are impossible to predict:

A small number of Black Swans explain almost everything in our world, from the success of ideas and religions, to the dynamics of historical events, to elements of our own personal lives. Ever since we left the Pleistocene, some ten millennia ago, the effect of these Black Swans has been increasing. It started accelerating during the industrial revolution, as the world started getting more complicated, while ordinary events, the ones we study and discuss and try to predict from reading the newspapers, have become increasingly inconsequential.

Just imagine how little your understanding of the world on the eve of the events of 1914 would have helped you guess what was to happen next. (Don’t cheat by using the explanations drilled into your cranium by your dull high school teacher). How about the rise of Hitler and the subsequent war?… How about the spread of the Internet?… Fads, epidemics, fashion, ideas, the emergence of art genres and schools. All follow these Black Swan dynamics. Literally, just about everything of significance around you might qualify. (2010, xxii)

One of Taleb’s most compelling points is that these supposedly rare events are becoming less rare every day, as our world grows more complicated and interconnected. While you, by definition, can’t expect to foresee black swan events that might affect your projects, you should at least strive to remain aware that the most unlikely event in the world could in fact happen on your watch.

As a thought experiment designed to expand your appreciation for the role of randomness and luck in modern life, Taleb suggests that you examine your own experience:

Count the significant events, the technological changes, and the inventions that have taken place in our environment since you were born and compare them to what was expected before their advent. How many of them came on a schedule? Look into your own personal life, to your choice of profession, say, or meeting your mate … your sudden enrichment or impoverishment. How often did these things occur according to plan? (2010, xiii)

The goal of this line of thinking is not to induce paralysis over the many ways your plans can go awry, but to encourage you to keep your mind open to all the possibilities, both positive and negative, in any situation. In other words, you need to accept the uncertainty inherent in living order. That, in turn, will make you a better risk manager because you will be less inclined to believe in the certainty of your plans.

Keep in mind that engineers, especially early-career engineers, tend to be uncomfortable with uncertainty and ambiguity. They’re trained to seek clarity in all things, which is a good thing. But they also need to accept ambiguity and uncertainty as part of living order. Strive to develop the ability to assess, decide, observe, and adjust constantly throughout the life of a project and your career.

8.6 Contingency Planning and Probabilistic Risk Modeling

Contingency planning is the development of alternative plans that can be deployed if certain threats are realized (e.g., parts from a supplier do not meet quality requirements). Not all types of risk involve unexpected costs. Some are more a matter of having a Plan B in your back pocket to help you deal with a risk that becomes a reality. For example, if you are working with a virtual team scattered across the globe, one risk is that team members will not be able to communicate reliably during weekly status meetings. In that case, the project manager would be wise to have a contingency plan that specifies an alternative mode of communication if, for instance, a Skype connection is not functioning as expected.

However, for most risks, contingency planning comes down to setting aside money—a contingency fund—to cover unexpected costs. As discussed in Lesson 6, on small projects of limited complexity, a contingency fund consisting of a fixed percentage of the overall budget will cover most risks. But if you are working on expensive, complex projects, you will probably be required to use models generated by specialized risk analysis software. Such tools can help you determine what risks you need to or can afford to plan for. They do a lot of the number crunching for you, but still require some expert knowledge and the intelligence to enter appropriate inputs. You need to avoid the trap of accepting the outputs uncritically just because you assume the inputs were valid in the first place.

To analyze risks related to costs, organizations often turn to Monte Carlo simulations, a type of probabilistic modeling that aggregates “a series of distributions of elements into a distribution of the whole” (Merrow 2011, 324). That is, the simulation aggregates a range of high and low values for various costs. For example, when generating a Monte Carlo simulation, a project team might look at the cost of labor, assigning “an amount above and below the estimated value. The distribution might incorporate risk around both changes (increases) in hourly cost and productivity” (Merrow 2011, 324). Keep in mind that Monte Carlo simulations, like other types of probabilistic risk modeling, are only useful if their underlying assumptions are accurate. To learn more about Monte Carlo simulations, see this helpful explanation: http://news.mit.edu/2010/exp-monte-carlo-0517.

No matter what approach you take, the most valuable part of any contingency planning is the thinking that goes into the calculation, rather than any particular number generated by the calculation. Thinking carefully about the risks facing your project, and discussing them with others, is the best way to identify the areas of uncertainty in the project plan. This is why simple percentages or even Monte Carlo calculations may be counter-productive—they might encourage you to defer to a set rule or a program to do the thinking for you.

According to Larry Roth, the fundamental risk calculation—the probability of a threat materializing times the consequences if it does—should guide your thinking about contingency planning. If both the probability and consequences of a particular threat are small, then it’s probably is not worth developing a full-blown contingency plan to deal with it. But if the probability or consequences are high, then a formal contingency plan is a good idea (pers. comm., April 23, 2018).

8.7 Ethics and Risk Management

Engineering and ethics have been in the news a great deal in recent years, in stories about the BP oil spill, the Volkswagen emissions-control software scandal, and the General Motors ignitions switch recall. These stories remind us that decisions about risk inevitably raise ethical questions because the person making the decision is often not the one who will actually suffer the consequences of failure. At the same time, unethical behavior is itself a risk, opening an organization to lawsuits, loss of insurance coverage, poor employee morale (which can lead to more unethical behavior), and diminished market share, just to name a few potentially crippling problems.

An article on the website for the International Risk Management Institute explains the link between risk management and ethics as essentially a matter of respect:

Ethics gives guidelines for appropriate actions between persons and groups in given situations—actions that are appropriate because they show respect for others’ rights and privileges, actions that safeguard others from embarrassment or other harm, or actions that empower others with freedom to act independently. Risk management is based on respect for others’ rights and freedoms: rights to be safe from preventable danger or harm, freedoms to act as they choose without undue restrictions.

Both ethics and risk management foster respect for others, be they neighbors, employees, customers, fellow users of a good or service, or simply fellow occupants of our planet—all sharing the same rights to be safe, independent, and hopefully happy and productive. Respect for others, whoever they may be, inseparably links risk management and ethics. (Head 2005)

Why do people behave unethically? That’s a complicated, interesting question—so interesting, in fact, that it has been the motivation for a great deal of human art over many centuries, from Old Testament stories of errant kings to Shakespeare’s histories to modern TV classics like The Sopranos. In the following sections, we’ll explore some factors that affect the ethical decision-making of the average person.

But first, it’s helpful to remember that not everyone is average. Some people are, at heart, deeply unethical. Scientists estimate that 4% of the human population are psychopaths (also called sociopaths)—meaning they have no empathy and no conscience, have no concept of personal responsibility, and excel at hiding the fact that their “psychological makeup is radically different” from most people (Stout 2005, 1). If you find yourself dealing with someone who constantly confounds your sense of right and wrong, consider the possibility that you are dealing with a psychopath. The books The Sociopath Next Door, by Martha Stout, and Sharks in Suits: When Psychopaths Go to Work, by Paul Babiak, offer ideas on how to deal with people who specialize in bad behavior.

Sometimes, the upper managers of an organization behave, collectively, as if they have no empathy or conscience. They set a tone at the top of the organizational pyramid that makes their underlings think bad behavior is acceptable, or at least that it will not be punished. For example, the CEO of Volkswagen said he didn’t know his company was cheating on diesel engines emission tests. Likewise, the CEO of Wells Fargo said he didn’t know his employees were creating fake accounts in order to meet pressing quotas. One can argue whether or not they should have known, but it’s clear that, at the very least, they created a culture that not only allowed cheating, but rewarded it. Sometimes the answer is to decentralize power, in hopes of developing a more open, more ethical decision-making system. But as Volkswagen is currently discovering as they attempt to decentralize their command-and-control structure, organizations have a way of resisting this kind of change (Cremer 2017).

Still, change begins with the individual. The best way to cultivate ethical behavior is to take some time regularly to think about the nature of ethical behavior and the factors that can thwart it. Let’s start with the question of personal values.

Context and Ethical Decision Making: Values

Since ancient times, philosophers have wrestled with questions about ethics and morality. How should we behave? If people know the right thing to do, can we count on them to do it? Does behaving ethically automatically lead to happiness? Do the consequences of an action determine if it was ethical, or can an action be ethical or unethical in its own right?

Culture and Ethics

As you learned in Lesson 5, people from different cultures can have completely different interpretations of the same phenomenon. This is definitely true about ethical judgements. What might be considered bribery in one culture could be considered a perfectly acceptable attempt at building a relationship in another. To learn how to navigate such situations, see Riding the Waves of Culture: Understanding Diversity in Global Business a book by Fons Trompenaars and Charles Hampden-Turner. It includes excellent case studies and quizzes on cultural perceptions.

One of the most important philosophical questions is this: How can we tell if an action is ethical? We all like to think we have a reliable inner compass that points us in the direction of good behavior—or that at least tells us when something we are determined to do is bad. But research has shown that the average person’s sense of right and wrong is often determined more by context than principle and reason.

For example, one study looked at the factors that might cause people to report on their colleagues’ behavior, as Edward Snowden did when he released top secret documents regarding National Security Agency surveillance practices. Is whistle-blowing an act of heroism or betrayal? According to researchers Adam Waytz, James Dungan, and Liane Young, your answer to that question depends on whether you value loyalty more than fairness, or fairness more than loyalty. And which you value more depends at least in part on context. In the study, people who were asked to write about the importance of fairness were then more likely to act as whistle-blowers when faced with evidence of unethical behavior. Meanwhile, people who were asked to write about the importance of loyalty were less likely to act as whistle-blowers, presumably because they had been primed by the writing exercise to value loyalty to the group above all else. In a New York Times article about their study, the researchers conclude,

This does not mean that a five-minute writing task will cause government contractors to leak confidential information. But our studies suggest that if, for instance, you want to encourage whistle-blowing, you might emphasize fairness in mission statements, codes of ethics, honor codes or even ad campaigns. And to sway those who prize loyalty at all costs, you could reframe whistle-blowing, as many have done in discussing Mr. Snowden’s case, as an act of “larger loyalty” to the greater good. In this way, our moral values need not conflict. (Waytz, Dungan and Young 2013)

Other examples of our perceptions of right and wrong that will continue to challenge us for the foreseeable future include:

- Liberal versus conservative

- Big government versus big business

- Immigration policies

- Culture, faith and religion

- Security and safety

- Fair pay

- Work ethic

- Perceptions about power and authority

At some point, you might find that your personal values conflict with the goals of your organization or project. In that case, you should discuss the situation with colleagues who have experience with similar situations. You should also consult the Code of Ethics for Engineers, published by the National Society of Professional Engineers, which is available here: https://www.nspe.org/sites/default/files/resources/pdfs/Ethics/CodeofEthics/Code-2007-July.pdf.

Context and Ethical Decision-Making: Organizational Structure

The structure of an organization can also affect ethical decision-making, often in profound ways. In Team of Teams: New Rules of Engagement for a Complex World, General Stanley McChrystal and his coauthors describe the case of the faulty ignition switch General Motors used in the Chevy Cobalt and Pontiac G5. The failure of these switches killed thirteen people, most of them teenagers whose parents had bought the cars because they thought the Cobalt and G5 were safe though inexpensive vehicles. “What the public found most shocking, however, was not the existence of the ignition switch issue or even the age of its victims, but the time it had taken GM to address the problem” (2015, 188). Ten years elapsed between the first customer complaint and GM’s first attempt to solve the deadly problem. In the public imagination, GM emerged as negligent at best. However, according to McChrystal et al., the reality “was more complex. What seemed like a cold calculation to privilege profits over young lives was also an example of institutional ignorance that had as much to do with management as it did with values. It was a perfect and tragic case study of the consequences of information silos and internal mistrust” (2015, 188).

The company was “riddled with a lack of contextual awareness and trust” that prevented individuals from recognizing and acting on the failed ignition switch. The problem, for which there was an easy and inexpensive solution, floated from committee to committee at GM, because the segregated information silos prevented people from grasping its true nature. “It would take a decade of demonstrated road failures and tragedies before the organization connected the dots” (2015, 192). McChrystal and his coauthors conclude that “GM’s byzantine organizational structure meant that nobody—venal or kindly—had the information” required to make the calculations that would have revealed the flaws in the ignition switch (2015, 193).

Managing Risk through Ethical Behavior

As the GM example and countless others demonstrate, the consequences of unethical behavior can be catastrophic to customers and the general public. It can also pose an enormous risk to the company itself, with overwhelming financial implications. In the long run, being ethical is simply good business practice and the responsibility of professional engineers.

Because context can more powerfully motivate personal behavior than reason and principle, every organization should

- Develop, actively promote, and reinforce a set of clearly stated organizational values

- Encourage leaders to model ethical behavior and explicitly tie decisions and behaviors to the organization’s values

- Create a general climate in which discussions about ethics and related decisions are the norm

- Create systems that motivate ethical behavior

Ultimately, ethical behavior is not just a matter of individual choices, but an ongoing process of discussion and engagement with questions of right and wrong.

~Practical Tips

- Work as a team: When you identify risks, a team approach is very helpful. Get multiple sets of eyes looking at the same project, but perhaps from different perspectives.

- Use a project dashboard to keep all important metrics where everyone can see them: By practicing good visual management, you’ll make it easy to see if a project is on or off schedule. You’ll learn more about dashboards in Lesson 11.

- Remember that you probably know less than you think you do: When analyzing risk, keep in mind that people usually underestimate their uncertainty and over-estimate the precision of their own knowledge and judgment. For example, on capital projects, we tend to be overly optimistic in terms of cost and schedule, and we tend to underestimate many other factors that might have a significant impact. Consider asking experts with no direct interest in the project to help with identifying risks that may not be obvious to those more closely involved.

- Stay informed: To improve your ability to manage risk, stay informed about world events, politics, scientific and technological developments, market conditions, and finance, which can in turn affect the availability of capital required to complete your project. You never know where the next risk to your project will come from. Your goal is not to foresee every possibility, but to stay attuned to the ever-changing currents of modern life, which may in turn affect your work in unexpected ways.

- Don’t be inordinately risk adverse: You have to assess the risks facing a project realistically, and confront them head-on, so that you can make fully informed decisions about how to proceed. You might decide to take some risks when the potential reward justifies it, and when the worst-case outcome is survivable. Further, some risks may create new opportunities to expand the services your organization offers to affected markets.

- Keep in mind that externalities can change everything: In our interconnected global economy, externalities loom ever larger. The disruptions Toyota factories around the world experienced as a result of the 2014 earthquake and tsunami are just one example of how a company’s faith in its supposedly impregnable supply chain can prove to be “an illusion,” as a Toyota executive told Supply Chain Digest (2012).

- Make sure everyone’s speaking the same language: To manage risk effectively, you need to make sure all stakeholders have the same understanding of what constitutes a high risk, a medium risk, and a low risk. This is especially important when considering inputs from several different project managers across a portfolio of projects. Each project manager might have a different tolerance for risk, and so assign varying risk values for the same real risk. It’s helpful to have a defined set of risk definitions that specify your organization’s thresholds for high, medium, and low risks, taking into account the probability and level of consequences for each.

- Quantify risk: Quantifying risk is not always possible, but it does enforce some objectivity. According to Larry Roth, “a key reason for quantifying risk is to be able to understand the impact of risk mitigation. If you are faced with a threat, you should be looking at ways to reduce that threat. For example, you might be able to reduce its probability of occurring. In the case of flooding, for instance, you could build taller levees. Or, you could reduce the consequences of flooding by moving people out of the flood path. A real benefit of risk analysis is the ability to compare the cost of reducing risk to the cost of living with the risk”(pers. comm., November 30, 2018). For example, you could quantify risk in terms of percent behind schedule or over budget, as follows:

- High is +/- 20% budget

- Medium is +/- 10% budget

- Low is +/- 5% budget

- Be on the lookout for ways to mitigate risk: Mitigating a risk means you “limit the impact of a risk, so that if it does occur, the problem it creates is smaller and easier to fix” (DBP Management 2014). For example, if one risk facing a new water treatment project on public land is that people in the neighborhood will object, you could mitigate that risk by holding multiple events to educate people on the sustainability benefits the new facility will provide to the community.

- Listen to your intuition: While quantifying risk is very helpful, you shouldn’t make any risk assessment decisions by focusing purely on numbers. The latest research on decision-making suggests the best decisions are a mix of head and intuition, or gut feelings. In an interview with the Harvard Business Review, Gerd Gigerenzer explains, “Gut feelings are tools for an uncertain world. They’re not caprice. They are not a sixth sense or God’s voice. They are based on lots of experience, an unconscious form of intelligence”(Fox 2014). Sometimes informed intuition—an understanding of a situation drawn from education and experience—can tell you more than all the data in the world.

- In a complex situation, or when you don’t have access to all the data you’d like, don’t discount the value of a tried and true rule of thumb: Gerd Gigerenzer has documented the importance of simple rules, or heuristics, drawn from the experience of many people, in making decisions in a chaotic world. For example, in investing, the rule of thumb that says “divide your money equally among several different types of investments” usually produces better results than the most complicated investment calculations (Fox 2014).

- Also, don’t discount the value of performing even a very crude risk analysis: According to Larry Roth, “the answers to a crude risk analysis may be helpful, in particular if you make a good faith attempt to understand the uncertainties in your analysis, and you vary the input in a sensitivity analysis. A crude analysis should not replace judgment but can help improve your judgment” (pers. comm., November 30, 2018).

- Be mindful of the relationship between scope and risk management: Managing risk is closely tied to managing project scope. To ensure that scope, and therefore risk, remains manageable, you need to define scope clearly and constrain it to those elements that can be directly controlled or influenced by the project team.

- Understand the consequences: In order to complete a project successfully, stakeholders need to understand the broader implications of the project. The better stakeholders understand the project context, the more likely they are to make decisions that will ensure that the entire life cycle of the project (from the using phase on through retirement and reuse) proceeds as planned, long after the execution phase has concluded.

- Assign responsibilities correctly in a RACI chart: A responsibility assignment matrix (RACI) chart must specify one and only one ‘R’ for each task/activity/risk. A common error is a task having no defined owner, or two or more owners. This results in confused delivery at best, or more likely, no delivery ownership.

- Beware of cognitive biases: As explained in Lesson 2, cognitive biases such as groupthink and confirmation bias can prevent you from assessing a situation accurately. These mental shortcuts can make it hard to perceive risks, and can cause you to make choices that you may only perceive as unethical in hindsight.

- Talk to your supervisor if you think your organization is doing something unethical or illegal: It’s sometimes helpful to raise an issue as a question—e.g., “Is what we are doing here consistent with our values and policies?” For additional guidance, consult the Code of Ethics for Engineers, published by the National Society of Professional Engineers, which is available here: https://www.nspe.org/sites/default/files/resources/pdfs/Ethics/CodeofEthics/Code-2007-July.pdf.

- Look for a new job: If your efforts to reform poor risk management or unethical practices in your organization fail, consider looking for a different job. A résumé that includes a stint at a company widely known for cheating or causing harm through poor risk management can be a liability throughout your career.

~Summary

- Risk can be a good thing, signaling new opportunity and innovation. To manage risk, you need to identify the risks you face, taking care to distinguish risks from issues. Risks are caused by external factors (such as the price of commodities) that the project team cannot control, whereas issues are known concerns (such as the accuracy of an estimate) that the project team will definitely have to address. Modern organizations face many types of risks, including risks associated with human capital, marketing, compliance, sustainability, and project complexity. A team member’s perception of risk will vary, depending on his or her role and current circumstances.

- Successful project managers manage the differing perceptions of risk, and the widespread confusion about its very nature, by engaging in systematic risk management. However, risk management tools can overestimate the accuracy of estimates. In traditional risk management, stakeholders take on as little risk as possible, passing it off to other shareholders whenever they can. A living order approach to risk seeks a more equitable form of risk-sharing that understands some risks emerge over the life of the project.

- Different industries face different risks. For example, product development risks are often related to schedules, whereas IT risks are typically related to the complexity of IT projects. One way to manage risks in many industries is to monetize them—that is, assign dollar values to them. Once you’ve monetized a project’s risks, you can rank them and make decisions about which deserves your most urgent attention.

- The biggest mistake is failing to perceive risks because you are too narrowly focused on technical issues, and risks you can’t foresee because they involve an extreme event that lies outside normal experience.

- The most valuable part of any contingency planning is the thinking that goes into it. Thinking carefully about the risks facing your project, and discussing them with others, is the best way to identify the areas of uncertainty in the project plan.

- Decisions about risk inevitably raise ethical questions because the person making the decision is often not the one who will actually suffer the consequences of failure, and because unethical behavior is itself a risk.

~Glossary

- black swan event—Term used by Nassim Nicholas Taleb in his book Black Swan: The Impact of the Highly Improbable to refer to the most extreme form of externality. According to Taleb, a black swan event has the following characteristics: it is an outlier, unlike anything that has happened in the past; it has an extreme impact; and, after it occurs, people are inclined to generate a rationale for it that makes it seem predictable after all (2010, xxii).

- contingency planning—The development of alternative plans that can be deployed if certain risks are realized (e.g., parts from a supplier do not meet quality requirements).

- ethics— According to Merriam-Webster, a “set of moral principles: a theory or system of moral values.”

- Integrated Project Delivery—A Lean-oriented contractual arrangement that emphasizes collaboration among all participants from the very earliest stages of the project, and that encourages participants to help solve each other’s problems, taking a proactive approach to risk (Thomack 2018).

- issue—A known concern, something a team will definitely have to address. Compare to a risk, which is caused by external factors that the project team cannot fully identify.

- monetize risk—To assign a dollar value to the potential impact of risks facing a project. Monetizing risks gives outcomes “real economic value when the effects might otherwise be ignored” (Viscusi 2005). Once you’ve monetized a project’s risks, you can rank them and make decisions about which deserves your most urgent attention. You can also evaluate the cost-effectiveness of steps required to reduce risk. Every industry has its own calculations for monetizing risks, although it is unethical in some industries, especially where public safety is concerned.

- Monte Carlo simulation—”A mathematical technique that generates random variables for modelling risk or uncertainty of a certain system. The random variables or inputs are modeled on the basis of probability distributions such as normal, log normal, etc. Different iterations or simulations are run for generating paths and the outcome is arrived at by using suitable numerical computations” (The Economic Times n.d.).

- proactive concurrency—Intentionally developing an awareness of options that can be employed in case you run into problems with your original plan.

- risk—The probability that something bad will happen times the consequences if it does. The likelihood of a risk being realized is typically represented as a probability value from 0 to 1, with 0 indicating that the risk does not exist, and 1 indicating that the risk is absolutely certain to occur.

- risk management—“The process of identifying, quantifying, and managing the risks that an organization faces” (Financial Times).

- risk matrix—A risk management tool in which the probability of the risk is multiplied by the severity of consequences if the risk does indeed materialize.

- tolerable risk—The risk you are willing to live with in order to enjoy certain benefits.

- threat—A potential hazard that could affect a project. A threat is not, in itself, a risk. A risk is the probability that the threat will be realized, multiplied times the consequences.

- value of a statistical life—An “estimate of the amount of money the public is willing to spend to reduce risk enough to save one life” (Craven McGinty 2016).

~References

Allen, Jonathan. 2007. “One Big Idea for Construction Delivery: Risk Realignment, Implementing New Tools for Process Change and Big Financial Rewards.” Tradeline. https://www.tradelineinc.com/reports/2007-9/one-big-idea-construction-delivery-risk-realignment.

Amundsen, Roald. 1913. The South Pole: An Account of the Norwegian Antarctic Expedition in the “Fram,” 1910-1912. Translated by A.G. Chater. Vol. 1. 2 vols. New York: Lee Keedick. Accessed July 12, 2016. https://books.google.com/books?id=XDYNAAAAIAAJ.

Barstow, David, Laura Dodd, James Glanz, Stephanie Saul, and Ian Urbina. 2010. “Regulators Failed to Address Risks in Oil Rig Fail-Safe Device.” The New York Times, June 20. http://www.nytimes.com/2010/06/21/us/21blowout.html?pagewanted=all.

Beckers, Frank, and Uwe Stegemann. 2013. “A risk-management approach to a successful infrastructure project.” McKinsey & Company. November. https://www.mckinsey.com/industries/capital-projects-and-infrastructure/our-insights/a-risk-management-approach-to-a-successful-infrastructure-project.

Brill, Steven. 2014. “Code Red.” Time, February: 26-36. http://content.time.com/time/subscriber/article/0,33009,2166770-1,00.html. .

Broadleaf. 2016. “Complexity and project risk.” Broadleaf. January. http://broadleaf.com.au/resource-material/complexity-and-project-risk/.

Chamary, JV. 2016. “Apple Didn’t Learn From The iPhone Antennagate Scandal.” Forbes, October 31. https://www.forbes.com/sites/jvchamary/2016/10/31/iphone-antenna-performance/#454ef19e604d.

Chen, Brian X. 2017. “The Biggest Tech Failures and Successes of 2017.” The New York Times, December 13. https://www.nytimes.com/2017/12/13/technology/personaltech/the-biggest-tech-failures-and-successes-of-2017.html.

Craven McGinty, Jo. 2016. “Why the Government Puts a Dollar Value on Life.” The Wall Street Journal, March 25.

Cremer, Andreas. 2017. “CEO says changing VW culture proving tougher than expected.” Reuters. May 22. https://www.reuters.com/article/us-volkswagen-emissions-culture/ceo-says-changing-vw-culture-proving-tougher-than-expected-idUSKBN18I2V3.

Danziger, Pamela N. 2017. “Growth in Store Brands and Private Label: It’s not about Price but Experience.” Forbes, July 28. https://www.forbes.com/sites/pamdanziger/2017/07/28/growth-in-store-brands-and-private-label-its-not-about-price-but-experience/#3f53504a505f.

DBP Management. 2014. “5 Ways to Manage Risk.” DBP Management. July 4. http://www.dbpmanagement.com/15/5-ways-to-manage-risk.

Financial Times. n.d. “Risk Management.” Financial Times Lexicon. Accessed July 15, 2018. http://lexicon.ft.com.

Florentine, Sharon. 2016. “More than Half of IT Projects Still Failing.” CIO, May 11. https://www.cio.com/article/3068502/project-management/more-than-half-of-it-projects-still-failing.html.

Fowler, Geoffrey A., Ian Sherr, and Niraj Sheth. 2010. “A Defiant Steve Jobs Confronts ‘Antennagate’.” Wall Street Journal, July 16. https://www.wsj.com/articles/SB10001424052748704913304575371131458273498.

Fox, Justin. 2014. “Instinct Can Beat Analytical Thinking.” Harvard Business Review, June 20. https://hbr.org/2014/06/instinct-can-beat-analytical-thinking.

Goldstein, Amy. 2016. “HHS failed to heed many warnings that HealthCare.gov was in trouble.” Washington Post, February 23. https://www.washingtonpost.com/national/health-science/hhs-failed-to-heed-many-warnings-that-healthcaregov-was-in-trouble/2016/02/22/dd344e7c-d67e-11e5-9823-02b905009f99_story.html?utm_term=.c2c2cd91ee68.

Head, George L. 2005. “Expert Commentary: Why Link Risk Management and Ethics?” IRMI. February 4. http://www.irmi.com/articles/expert-commentary/why-link-risk-management-and-ethics.

Hillson, David. 2009. Managing Risk in Projects. Burlington: Gower Publishing Limited.

Klein , Gary. 2009. Streetlights and Shadows: Searching for the Keys to Adaptive Decision Making. Cambridge, MA: MIT Press.

Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects. New York: Palgrave Macmillan.

Lee, Se Young. 2016. “Samsung scraps Galaxy Note 7 over fire concerns.” Reuters, October 10. https://www.reuters.com/article/us-samsung-elec-smartphones/samsung-scraps-galaxy-note-7-over-fire-concerns-idUSKCN12A2JH.

Lowers & Associates. 2013. “The Risk Management Blog.” Lowers Risk. August 8. http://blog.lowersrisk.com/human-capital-risk/.

Marshall, Aarian. 2018. “Ford Finally Makes Its Move Into Electric Cars.” Wired, January 17. https://www.wired.com/story/ford-electric-cars-plan-mach-1-suv/.

Martinez, Michael. 2016. “Ford unveils10-year plan to transform Dearborn campus.” The Detroit News, April 12. https://www.detroitnews.com/story/business/autos/ford/2016/04/12/ford-transform-campus/82935594/.

McChrystal, General Stanley, Tantum Collins, David Silverman, and Chris Fussell. 2015. Team of Teams: New Rules of Engagement for a Complex World. New York: Penguin Publishing Group.

Merrow, Edward W. 2011. Industrial Megaprojects: Concepts, Strategies, and Practices for Success. Hoboken, New Jersey: John Wiley & Sons, Inc.

Muirhead, Brian and William L. Simon. 1999. High Velocity Leadership: The Mars Pathfinder Approach to Faster, Better, Cheaper. New York, NY: Harper Business.

Pritchard, Carl, and Cesar Abeid. 2013. “006 Risk Management and the Secret Sauce of Carl Pritchard, podcast audio.” PM for the Masses. August 15. http://pmforthemasses.com/risk-management-carl-pritchard/.

Ram, Jiwat. 2016. “Compliance Projects: Fragile, Please Handle with Care!” projectmanagement.com. November 7. https://www.projectmanagement.com/articles/351236/Compliance-Projects–Fragile–Please-Handle-with-Care-.

SCDigest Editorial Staff. 2012. “Global Supply Chain News: Toyota Taking Massive Effort to Reduce Its Supply Chain Risk in Japan.” Supply Chain Digest. http://www.scdigest.com/ontarget/12-03-07-2.php?cid=5576.

Sfeir, Robert. 2015. “Agile is About Risk Mitigation.” Leading Agile. March 12. https://www.leadingagile.com/2015/03/agile-is-risk-mitigation/.

Shapira, Zur. 1995. Risk Taking: A Managerial Perspective. New York, NY: Russell Sage Foundation.

Smith, Preston G. 1999. “Managing Risk as Product Development Schedules Shrink.” Strategy2market.com. September-October. http://www.strategy2market.com/wp-content/uploads/2014/05/Managing-Risk-As-Product-Development-Schedules-Shrink.pdf.

Smith, Preston G., and Guy M. Merritt. 2002. Proactive Risk Management. New York: Productivity Press. http://www.petronet.ir/documents/10180/2323250/proactive_risk_management.

Stout, Martha. 2005. The Sociopath Next Door. New York: Broadway Books.

Taleb, Nassim Nicholas. 2010. The Black Swan: The Impact of the Highly Improbable. New York: Random House.

The Economic Times. n.d. “Definition of ‘Monte Carlo Simulation’.” The Economic Times Glossary. Accessed 15 2018, July. https://economictimes.indiatimes.com/definition/monte-carlo-simulation.

Thomack, David. 2018. “Introduction to Lean and Project Delivery.” Video Lecture for CEE 498: Construction Management. University of Wisconsin-Madison, College of Engineering, April 20.

Viscusi, W. Kip. 2005. “Monetizing the Benefits of Risk and Environmental Regulation.” Fordham Urban Law Journal 33 (4): 101-142. http://ir.lawnet.fordham.edu/cgi/viewcontent.cgi?article=2199&context=ulj.

Waytz, Adam, James Dungan, and Liane Young. 2013. “The Whistle-Blower’s Quandary.” New York Times, August 2. Accessed October 5, 2015. http://www.nytimes.com/2013/08/04/opinion/sunday/the-whistle-blowers-quandary.html.

Wilbury Stratton. 2012. “Sustainability Risks and Opportunities Report.” January. https://www2.deloitte.com/content/dam/Deloitte/in/Documents/risk/Board%20of%20Directors/in-gc-sustainability-risks-and-opportunities-report-noexp.pdf.

9

Managing Project Value, Budgets, and Costs

As obvious as it seems, customer value is defined by no one but the customer.
— Mark Rosenthal (2009)

Objectives

After reading this lesson, you will be able to

- Define basic terms such as budget, estimate, price, cost, and value

- Discuss the relationship between scope changes and cost and budget overruns

- Explain basic concepts related to budgeting

- Identify different types of costs, and discuss issues related to contingency funds, profit, and cost estimating

- Explain the benefits of target-value design

The Big Ideas in this Lesson

- The project manager’s biggest job is delivering value as defined by the customer. A more geometric order focus on the project’s budget is also important, but never as important as delivering value as defined by the customer.

- Managing value and cost requires constant engagement with the customer, and a mutual understanding of basic terminology like budget and estimate.

- When creating an estimate, don’t confuse precision with accuracy.

9.1 Talking the Talk

Nearly all projects require money to pay for the required resources—labor, services, and supplies. Project success requires that project managers accurately identify the money needed for a project, acquire the commitment of those funds through a budgeting process, and then successfully manage the expenditure of those funds to achieve the desired outcomes. Your ability to manage stakeholder expectations and commitment related to project funds, combined with your ability to effectively manage the use of those funds to deliver results, will form the basis of your reputation as a reliable project manager.

An important step in ensuring that a project unfolds smoothly is to make sure everyone is using similar terminology. Terminology is important in any technical endeavor, but when it comes to a project’s overall value, miscommunications resulting from incorrectly used terms can result in misaligned expectations and erode trust among project participants. Unfortunately, this type of miscommunication is extremely common. So, let’s start with some basic terms:

- budget: The funds that have been allocated for a project.

- estimate: An assessment of the likely budget for a project. An estimate involves counting and costing and is based on ranges and probabilities. Throughout a project, managers and team members are asked to estimate remaining work, cost at completion, and required remaining time. An estimate is a forward projection, using what is known, to identify, as best as possible, the required effort, time, and/or cost for part or all of a project.

- price: “A value that will purchase a finite quantity, weight, or other measure of a good or service” (Business Dictionary). The price of a purchased unit is determined by the market.

- cost: “An expenditure, usually of money, for the purchase of goods or services” (Law 2016). Practically speaking, project cost (and its relationship to revenue or approved expenditures) is the thing management cares about most. Note that, like all terms, the meaning of “cost” varies somewhat from industry to industry. For example, in product development, the term has three specific meanings: 1) cost to create the product or project; 2) cost to establish a manufacturing cell capable of producing the product; and 3) cost of the final good or service to the market.

- value: “The inherent worth of a product as judged by the customer and reflected in its selling price and market demand” (Lean Enterprise Institute 2014). Project managers have to think about two kinds of value—target value, or the value the stakeholders hope to achieve, and delivered value, the value actually generated by the project. You’ll learn more about target value later in this lesson.

The following scenario illustrates use of these related concepts. Suppose you set $100 as your monthly gas budget at the beginning of the year. However, because the current price of gas is $5.50 a gallon, which is higher than normal, you estimate that you will actually spend $130 on gas this month. You won’t know your cost for gas until you make your final purchase of the month and add up all the money you spent on fuel. If you wind up having to take an unexpected out-of-town trip, then your cost could be quite a bit higher than your estimate. Or, if the price of gas drops suddenly, say to $1.60 per gallon, your cost will turn out to be lower. In any case, the cost is a simple summation you can do looking backwards. But the value of your month of travel is something only you can define. If your unexpected out-of-town trip results in some compelling new business opportunities, then you would likely value the trip very highly. But if the weather prevents you from reaching your destination, and then you get lost on the way home, you would probably assign a low value, as experienced, to your misbegotten adventure. Much like in a project, the delivered value may fall short of the target value.

A Word on Price

Note that the precise meaning of the term “price” varies from one industry to the next. In a capital project, the term “price” may refer to total price the customer will pay. In a product development project, the term typically refers to the market price for the good or service, and will often fluctuate based on the volume purchased by a particular customer.

In the real world, these terms do not always mean the same thing to everyone. Worse, people sometimes use them interchangeably or use them to mean different things in different situations. In particular, the terms budget and estimate are often incorrectly used as synonyms, as are the terms cost and price. The end result of this confusion can be a lack of clarity among project partners regarding project goals and constraints. It helps to keep in mind that a budget, an estimate, a target value, and a price are tools to help guide the project team, whereas cost and delivered value are project outcomes that help determine project success. Budgeting and estimating are tools we use to try gauge cost and create value. But they don’t cause cost. Project cost is driven by scope, required resources to accomplish the scope, and related prices.

Delivering value is your primary job as a project manager. But of all the terms related to budgeting a project, the meaning of “value” can be most difficult to grasp. The important thing to remember is that value is determined by the customer, and then flows back to all participants, shaping all project activities. As a project manager, you need to engage with the customer to identify the project’s real value. At the same time, you might also need to take a longer view of value. For example, your organization might be better able to offer value to future customers by carefully studying all projects at completion to capture lessons learned—information that can then be used to improve future projects. The value of this investment of resources may not be apparent to customers, who are only focused on their particular projects, as it mainly benefits future projects. But the overall process benefits all customers in the long run.

As you work on the project’s budget, and perhaps face difficult decisions, you need to focus on tasks that create value. According to the Lean Lexicon, a good test for identifying a value-creating task “is to ask if this task could be left out without affecting the product. For example, rework and queue time are unlikely to be judged of any value by customers, while actual design and fabrication steps are” (Lean Enterprise Institute 2014). This article walks through an example of a home construction project that could have turned out much better for the home owners—who were forced to live in a trailer with no running water during the project—if the builder had focused on providing “chunks” of immediately usable value, such as a working bathroom (Lloyd 2015): http://project-management.com/understanding-lean-project-management/. As you’ve learned in earlier lessons, that’s exactly what Agile project management does in the world of IT. At the end of each sprint, the customer is in possession of a piece of working software.

Throughout any project, you need to do all you can to get stakeholders to focus on the success of the whole project, and not just their individual parts. One way to do this is to make sure everyone understands what the project value is, and then encourage them to optimize the flow of the project. As the project evolves, the project team should continue to refine its understanding of project value; refine its estimate of required resources; and, if necessary, modify the approved budget or adjust scope so that costs do not exceed the budget.

In product development, it is helpful to think of value as an attribute or feature for which customers will pay a premium. Customers may pay more for smaller size, longer life, better aesthetics, or more durable products. Depending on the use of the product being created, these may be more or less important. Susan Ottmann, program director for Engineering Professional Development at the University of Wisconsin-Madison, points out that “Schneider Electric produces two types of load centers for the U.S. market. (A load center is the box in your home that houses circuit breakers.) The QO brand is differentiated from the Homeline brand by a higher level of durability and quality. Although both perform the same function, the technology inside the breakers is slightly different. Presumably, QO has made the calculation that some customers will be willing to pay more for a higher quality product” (pers. comm., June 6, 2018).

9.2 Keeping an Eye on Scope

A project’s budget, estimate, and cost are all affected by the project’s scope. Anyone who has ever remodeled a bathroom in an old house is familiar with the way scope can change throughout the course of a project. The fact is, you can’t really know how much the project is going to cost until you tear up the floor and get a look at the state of the old plumbing. Boston’s Big Dig—which was estimated to cost $2.8 billion, but ultimately cost $14.6 billion—is a more extreme example of the same principle at work: It is difficult to precisely predict the cost of any endeavor at its outset.

A good rule of thumb is to assume that whatever can go wrong probably will go wrong. For example, to return to the remodeling example—rather than naively hoping for the best, you’d be wise to assume that everything old will have to be replaced when you begin pulling up the floor in a fifty-year-old bathroom. Overly optimistic assumptions about risk and scope are a leading cause of unrealistic estimates. Assuming everything will have to be replaced would help set an estimate for the upper bound of a likely range of costs for the project. Estimates should include a range, which can be narrowed as more is learned about actual project conditions.

Examples of cost and time overruns are easy to find. Here are just a few sources to give you a sense of the magnitude of the problem, which is especially acute in massive megaprojects:

- A report on overruns in the energy industry: http://globalsustain.org/files/EY-spotlight-on-oil-and-gas-megaprojects.pdf

- A Forbes article describing the vast costs of hosting the Olympic games: http://www.forbes.com/sites/niallmccarthy/2016/08/04/the-massive-cost-of-hosting-the-olympic-games-infographic/#66c9ad79ddf7

- A slide collection from MSN.com documenting budget-busting megaprojects in a variety of industries: https://www.msn.com/en-us/money/companies/mismanaged-megaprojects-that-wasted-billions/ss-BB16xME1

When asked to defend mounting costs, project managers will sometimes argue that the cost increased because the scope evolved, when in fact the real culprit is scope creep. As discussed in Lesson 4, scope evolution, or managed change, is a natural and rational result of the kind of learning that goes on throughout the course of a project. It is a conscious, managed choice caused by externalities that forces you to reconsider project essentials in order to achieve the intended project value.

Scope creep, by contrast, is caused by unmanaged changes to the project scope. It might add value from the customer’s perspective, but the time, money, and resources consumed by the change of scope lead to additional overruns. Scope creep tends to happen when no one is paying attention to the project’s scope.

The key to managing scope changes is a process for early identification, review, and approval of requested changes to project scope. A Scope Change Request—or a Project Variation Request (PVR) as it is sometimes called— is a form that must be signed by all affected stakeholders prior to implementation. This article by Tom Mochal provides some helpful guidelines for managing scope changes: http://www.techrepublic.com/article/follow-this-simple-scope-change-management-process/. You can download a sample change request form here: “Change Request Form“.

9.3 Understanding Budgets

Precision versus Accuracy

Can a price be precise but not accurate? Yes. You might calculate a price down to the penny, but if you’re wrong, you’re not accurate. Engineers tend to focus on precision at the expense of accuracy. But accuracy is far more useful. And remember, you can never be more precise than the least precise line item (Nelson 2017).

Budgeting is an exercise in refining your focus. You start with a wide-angle estimate, in which the details are necessarily fuzzy, and bit by bit zero in on a sharper picture of project costs. You might be temperamentally inclined to try to nail down every figure in an early draft of a budget, but in fact you should only develop a budget at the precision needed for current decisions. Your overall precision can and should advance as the project advances.

This is especially important in the earliest stages of the budgeting process, when you are working out rough estimates. Take care to estimate at the appropriate level of precision: Don’t make the mistake of thinking you can estimate costs to the exact penny or dollar. $378,333.27 is not a realistic or intelligent estimate. Ultimately, overly precise budgets represent a communication failure. By proposing a budget to the customer that contains overly precise figures, you risk giving a false sense of accuracy regarding your understanding of and knowledge about the project.

In the early stages of the budgeting process, when you are still working out estimates, it’s helpful to include an uncertainty percentage. A typical approach is to include a +/- percentage, such as $400,000 +/- 10%. The percentage may initially be large but should gradually decrease as the project progresses and the level of uncertainty declines. For IT projects, which are notoriously difficult to estimate, consider going a step further and adding an uncertainty percentage to every line item. Some items, such as hardware, might be easy to estimate. But other items, such as labor to create new technology, can be extremely difficult to estimate. These line item variances can influence the total estimate variance by a significant amount in many projects.

But even when you have a final budget in hand, you need to prepare for uncertainty by including an official contingency fund, which is a percentage of the budget set aside for unforeseen costs. Contingency funds are described in more detail later in this lesson.

Successful project managers use the budgeting process as a way to create stakeholder buy-in regarding the use of available resources to achieve the intended outcome. By being as transparent as possible about costs and resource availability, you’ll help build trust among stakeholders. By taking care to use the right kinds of contracts—for example, contracts that don’t penalize stakeholders for escalating prices caused by a changing economy—you can create incentives that keep all stakeholders focused on delivering the project value, rather than merely trying to protect their own interests. The relationship between costs and contracts is discussed in more detail later in this lesson.

This blog post by Tim Clark includes some helpful tips on creating a project budget: https://www.liquidplanner.com/blog/7-ways-create-budget-project/.

9.4 Understanding Cost

Ultimately cost, the number management typically cares about most in a for-profit organization, is determined by price. For many projects, it’s impossible to know the exact cost of an endeavor until it is completed. Stakeholders can agree on an intended value of a project at the beginning, and that value has an expected cost associated with it. But you may not be able to pin down the cost more precisely until you’ve done some work on the project and learned more about it.

To estimate and manage costs effectively, you need to understand the different types of costs:

- direct costs: “An expense that can be traced directly to (or identified with) a specific cost center or cost object such as a department, process, or product” (Business Dictionary n.d.). Examples of direct costs include labor, materials, and equipment. A direct cost changes proportionately as more work is accomplished.

- direct project overhead costs: Costs that are directly tied to specific resources in the organization that are being used in the project. Examples include the cost of lighting, heating, and cleaning the space where the project team works. Overhead does not vary with project work, so it is often considered a fixed cost.

- general and administrative (G&A) overhead costs: The “indirect costs of running a business,” such as IT support, accounting, and marketing” (Investing Answers n.d.).

The type of contract governing your project can affect your consideration of costs. As explained in Lesson 4, the two main types of contracts are fixed-price and cost-plus. Fixed price is the more predictable of the two with respect to final cost, which can make such contracts appealing to the issuing party. But “this predictability may come with a price. The seller may realize the risk that he is taking by fixing a price and so will charge more than he would for a fluid price, or a price that he could negotiate with the seller on a regular basis to account for the greater risk the seller is taking” (Symes 2018).

Many contracts include both fixed-price and cost-plus features. For example, they might have a fixed price element for those parts of the contract that have low variability and are under the direct control of the project team (e.g., direct labor) but have variable cost elements for those aspects that have a high degree of uncertainty or are outside the direct control of the project team (e.g., fuel costs or market driven consumables).

Contingency Funds

If money is not available from other sources, then cost overruns typically result in a change in the project’s scope or a reduction in overall quality. To prevent this, organizations build contingency funds into their budgets. Technically, a contingency fund is a financial reserve that is allocated for identified risks that are accepted and for which contingent or mitigating responses are developed. The exact amount of a contingency fund will vary, depending on project risks; a typical contingency fund is 10% to 15% of the total budget but depends on the risks associated with the project.

From the Trenches: John Nelson on Cost Planning and Living Order

John Nelson summarizes his thoughts on cost planning, based on his decades of work on capital projects, as follows:

Conceptual planning takes place in living order. Cost management, when done right, starts out in living order, but moves into a very strict geometric order. Unfortunately, it is rarely done right. Between 2/3 and 3/4 of all projects worldwide end up costing more than originally planned. Getting the costs wrong during the planning stage can result in huge consequences for a project, and possibly for your career. Major cost busts can follow you around for the rest of your working life. If you cost something incorrectly, you’ll have to make corresponding downgrades in scope and quality. For example, many college campuses have new buildings with two or three empty floors because the money ran out before they could be finished. You really don’t want to be the project manager responsible for a costing error of that magnitude, which is sometimes referred to as a CLM, or career limiting move.

Even worse, companies that get costs wrong and underbid a project sometimes try to salvage a profit by illegal means—perhaps by using cheap materials or cutting corners on safety. On public projects, such as highways or schools, huge costing errors can result in loss of public trust, making it more difficult for the public agency to do more work in the future. In that case, a cost bust can be an OLM—an organizational limiting move.

Accurately and precisely predicting the cost of a project is very difficult. You need to start with humility and curiosity, expending a great deal of effort to get the numbers right, especially when it comes to parts of the project you don’t understand. This is true for small projects, like a bathroom renovation in an old house, where you simply don’t know what you’re going to find until you start opening up the walls. It’s also proven true for huge undertakings like the Big Dig, Boston’s tunnel megaproject, which ended up with a cost overrun of 190%. (2017)

Contingency funds are often available to pay for an agreed-upon scope change. However, some project managers make a practice of treating a contingency fund as a “Get Out of Jail Free” card that they can use to escape any cost limitations. Some, as a practical matter, will artificially inflate a contingency fund to ensure that they have plenty of resources to draw to manage any unforeseen future risks. But that is never a good idea because if you wind up with a large contingency fund that you ultimately don’t spend, you have essentially held that money hostage (i.e., lost opportunity costs) from the rest of the enterprise. That can be as damaging to your organization’s mission as a cost overrun that prevents you from finishing a project.

This excellent article, published by the Australian firm Broadleaf Capital International, discusses the issues and tradeoffs involved in contingency funds: http://broadleaf.com.au/resource-material/project-cost-contingency/.

As explained in Lesson 8, contingency funds are a form of risk management. They are a necessary tool for dealing with uncertainty. Unfortunately, as necessary as they are, it’s not always possible to build them into your approved budget. For example, if you are competitively bidding on a contract that will be awarded on the lowest cost, then including a contingency fund in your estimate will almost certainly guarantee that your company won’t win the contract. It is simply not practical to include a contingency fund in a lump sum contract.

In the living order approach to this problem, the owner maintains a shared contingency fund instead and makes it available, upon justification, for all project stakeholders. This approach helps ensure that project participants will work collaboratively with the project sponsor to solve any problems they might notice, confident that there is money available to address problems that threaten project value or to leverage opportunities that will provide greater project value. For example, in a lecture on Lean and integrated project delivery, David Thomack, a long-time veteran of the construction industry, explained how the Boldt Company and other stakeholders involved in a $2 billion healthcare project protected millions of dollars in contingency funding, which was then ultimately shared among all stakeholders (Thomack 2018). Such shared contingency funds are typically spelled out in the project contract and are an effective tool to manage risk and uncertainty. Although some organizations only manage out-of-pocket project costs, best practice is to manage total cost, including costs associated with staff (engineering, purchasing, testing, etc.) working on the project.

Profit

In private enterprise, cost management is directed toward maximizing profit. A private or publicly-traded organization cannot stay in business unless they are profitable. But that doesn’t mean that every project is primarily a profit-maximizing undertaking. Certainly, individual projects (such as developing a new product or completing a design for a client) may have a goal of generating profit. However, some projects (such as deploying an enterprise software system or meeting a regulatory compliance requirement) may not in themselves generate profit, but rather support the broader organization in generating profits. Within governmental and non-profit organizations, projects are not designed to generate profits but might be launched to reduce costs or generate net revenues that can be used to cover other costs within the organization.

As a project manager, you need to understand the financial expectations for your projects. Make sure you know how the financial performance of your project affects the financial performance of the associated project portfolio and the overall organization. This understanding will help you advocate for your proposed project. It will also enable you to better justify changes to the project’s scope and budget, based on the project’s proposed value.

As a general rule, chasing profits at the expense of both your organization’s larger mission and the value your organization wants to offer to customers is not sustainable. A relentless focus on profit alone can wreak havoc on a project as project managers are forced to reduce quality or slow the schedule to meet a carved-in-stone budget that will supposedly ensure profitability. In such situations, however, profitability is nearly always defined in the short-term. A fixation on short-term profits can, paradoxically, lead to spiraling losses in the long term—perhaps because unsatisfied customers take their business elsewhere. Likewise, chasing excessive quality or accelerated schedules can be equally elusive.

Ideally, some kind of financial metric is associated with the success of any project and is spelled out in the contract. A collaborative approach to contracts and procurement helps keep all stakeholders focused on the project’s intended value rather than simply on short-term profits.

Cost Estimating

Estimating costs accurately is essential to any organization’s success. In fact, in many industries, the knowledge involved in cost estimating is actually a valuable form of intellectual property. The ability to estimate costs is part of a company’s overall competitive advantage and a skill required in most industries. There are two basic types of estimating:

- More on Estimating

For clarification on the difference between top-down and bottom-up estimating, see this blog post, by Andy Makar: “Top-Down vs. Bottom-Up Project Management Strategies.”

For a complete discussion of cost estimating, see Chapter 5 of Project Management: The Managerial Process, by Erik W. Larson and Clifford F. Gray.

top-down estimates: Estimates that “usually are derived from someone who uses experience and or information to determine the project duration and total cost. However, these estimates are sometimes made by top managers who have very little knowledge of the component activities used to complete the project” (Larson and Gray 2011, 134). A top-down estimator generates an expected total for the entire project and then divides up that total among the various project tasks.

- bottom-up estimate: “A detailed cost estimate for a project, computed by estimating the cost of every activity in a work breakdown structure, summing these estimates, and adding appropriate overheads” (Business Dictionary n.d.). A bottom-up estimator divides the project into elements and tasks, estimates a cost for each, and then sums all estimated costs to create a total for the project. A common problem with simple bottom-up estimates is that they often overestimate costs that cannot be justified by market conditions. Total projected costs need to be compared with market realities, and task estimates of planned work and associated costs may have to be adjusted to reach a feasible budget for the overall project. Note that pressure to make such adjustment can encourage the sponsor to try to make the numbers work any way possible, perhaps by overstating the benefits of the project (e.g., higher sales volume than the market forecast predicts) or planning for the project team to do more work faster than is realistic. Ultimately, this is an ethical issue and could end up costing your reputation. It’s essential that you remain truthful about the realities of your projects as you estimate their costs.

A third type, iterative estimating, combines the best of top-down and bottom-up estimating. Iterative estimating is a process of refining an estimate by taking into account information typically used in a top-down estimate (such as past history of similar projects) and detailed information generated by bottom-up estimating. Iterative estimating takes place in living order and relies on negotiation and coordination among the project stakeholders. It only works if past work is representative of future work, which you can really only determine if you are producing small batches. One type of iterative estimating, phase estimating, is “used when the project is large or lengthy or is developing something new or untried for the organization. In phased estimates, the near-term work is estimated with a high level of accuracy, ±5 – 15%, whereas future work is estimated at a high level with ±35% accuracy” (Goodrich n.d.). As the project advances through major phases, the budget for subsequent phases is intentionally reviewed and refined in light of knowledge gained to date.

According to David Pagenkopf, IT project managers use yet another type of estimating called parametric estimating, which is a way to “use experience from parts of other projects to come up with estimates for work packages that are similar to past work, but not the same.” For example, he explains that “if a ½ ton Ford pick-up gets 20 mpg on the highway then I can estimate that a ½ ton GMC pick-up may get 20 mpg on the highway. That information may be helpful in determining the entire cost of a trip that involves the use of multiple rented trucks. Actual mileage will vary, but without testing the GMC truck and collecting data, I can reasonably estimate mpg for it” (pers. comm. June 1, 2018).

9.5 Target-Value Design

Despite all the effort organizations put into cost management, cost overruns remain a fact of life. For example, in a study of 1,471 IT projects, Flyvbjerg and Budzier found

The Chaos Report

An interesting source of data on the general health of projects is the annual Chaos Report from the Standish Group. Although aimed at the IT industry, it can be extrapolated to other types of projects to show general performance on projects in other industries. The most recent version of the report requires paid access, but you can find earlier versions online for free, such as this copy of the 2014 report: https://www.projectsmart.co.uk/white-papers/chaos-report.pdf.

The average overrun was 27%—but that figure masks a far more alarming one. Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied…[had] a cost overrun of 200%, on average, and a schedule overrun of almost 70%. This highlights the true pitfall of IT change initiatives: It’s not that they’re particularly prone to high cost overruns on average, as management consultants and academic studies have previously suggested. It’s that an unusually large proportion of them incur massive overages. (2011)

Cost overruns occur for many reasons, including lack of sufficient knowledge about the project, inability to obtain funding for the full scope of the desired work, uncertainty about the feasibility of the project, and conflicting priorities. Using only the traditional, geometric approach to cost management fails to encourage broad on-going stakeholder engagement and collaboration that can prevent these problems. You will get far better results by incorporating the living order principle of target-value design, a cornerstone of Lean project delivery in the construction field which has applications in nearly all areas of project management. A target value is the output stakeholders want the project to generate. Target-value design focuses on creating the best possible target value for the customer without exceeding the project’s target costs. It requires a fundamental shift in thinking from “expected costs” to “target cost.” The target-value design process is collaborative and iterative, typically requiring frequent refinement and conversation among project stakeholders.

For a quick, thirty-second introduction to target-value design, see this video:

A YouTube element has been excluded from this version of the text. You can view it online here: https://wisc.pb.unizin.org/technicalpm/?p=194

In the traditional budget process, the estimate is based on a detailed design and project plan. In target-value design, you start with the intended value of the project, and then design and plan a project that will deliver the intended value for the targeted cost. In other words, the project’s value and associated budget determines the project’s design, and not the other way around. This is nothing new for product development teams, who nearly always have to design their products for particular price points. But the degree of engagement with the customers required in target value design to find out what customers really want is not something most product development teams are used to. In any industry, the goal of target-value design is hitting the sweet spot of what you can get for the right price, schedule, and quality. For example, the whole point of Agile software development is continually refocusing the project in an attempt to achieve the desired target-value.

Thinking About Value

According to John Nelson, you can’t get the costs right on a project until you understand what the customer values. To do that, you need to understand what value really means:

We make value-based decisions all the time. But different people value different things. For instance, in Wisconsin, you might choose to drive an inexpensive car, so you don’t have to worry about it getting damaged on icy winter roads. A realtor, who has to drive clients around in her car, might choose a more comfortable, expensive vehicle. There’s no right or wrong in these decisions. You’re both right.

Keep in mind that a moral value is different from a project value. Moral values are about right and wrong. Project value is concerned with the worth of something—and the only person who can determine that is the customer. The only time an engineer can object to the customer’s definition of project value is when the customer asks for something that is a threat to human safety or is illegal.

When costing a project, you need to figure out what your customer’s value threshold is. You don’t want to build the best thing ever built if that’s not what they want. So, the first step in the target value process is to get the customer to explain her definition of value. To do that, you need to have open conversations in which you keep asking questions, all the while making it clear you are eager to learn what the customer wants. At this stage, it’s essential to resist the temptation to over-promise what you can deliver. One way to avoid this is to continually engage with the customer about value, budget, and schedule. (2017)

According to John Nelson, in capital projects, a target value cost model is “a framework of estimates and budgets that changes over time” (2017). The process entails “many conversations about price, cost, budget, and estimate, and at the same time discussions with the customer about what they really value.” When done right, it transforms “cost management from a calculation performed in isolation by professional estimators, to a process of ongoing, collaborative learning about the project in which team members and the customers all have a role. It avoids the pitfall of having one person responsible for calculating a total cost, and another person responsible for delivering the project at that number” (2017).

The ultimate goal of target-value design is to reduce the waste and rework that normally arises in the design/estimate/redesign cycle. It necessarily involves cross-functional teams because no one party in isolation has the necessary knowledge to define project value and develop a project plan that most efficiently delivers that value. Target-value design integrates the definition of the project’s product/deliverables with the process used to deliver the project and with the associated project costs.

To help you implement target-value design in your organization, the Lean Construction Institute recommends nine “foundational practices.” These principles apply to all types of projects:

1. Engage deeply with the client to establish the target-value. Both designers and clients share the responsibility for revealing and refining concerns, for making new assessments of what is value, and for selecting how that value is produced. Continue engaging with the client throughout the design process to uncover client concerns.

2. Lead the design effort for learning and innovation. Expect the team will learn and produce something surprising. Establish routines to reveal what is learned and innovated in real-time. Also expect surprise will upset the current plan and require more replanning.

3. Design to a detailed estimate. Use a mechanism for evaluating design against the budget and the target values of the client. Review how well you are achieving the targets in the midst of design. When budget matters, stick to the budget.

4. Collaboratively plan and re-plan the project. Use planning to refine practices of coordinating action. This will avoid delay, rework, and out-of-sequence design.

5. Concurrently design the product and the process in design sets. Develop details in small batches (lot size of one) in tandem with the customers (engineer, builders, owner, users, architect) of the design detail. Adopt a practice of accepting (approving) completed work as you design.

6. Design and detail in the sequence of the customer who will use it. This maintains attention to what is valued by the customer. Rather than doing what you can do at this time, do what others need you to do next. This leads to a reduction in negative iterations.

7. Work in small and diverse groups. Learning and innovation arises socially. The group dynamics of small groups—8 people or less—is more conducive to learning and innovating: trust and care for one another establish faster; and communication and coordination are easier.

8. Work in a big room. Co-locating design team members is usually the best option. Design is messy. Impromptu sessions among design team members are a necessary part of the process. So are regular short co-design sessions among various specialists working in pairs.

9. Conduct retrospectives throughout the process. Make a habit of finishing each design cycle with a conversation for reflection and learning. Err on the side of having more retrospectives not fewer. Use plus|deltas at the end of meetings. Use more formal retrospectives that include the client at the end of integration events. Instruct all team members to ask for a retrospective at any time even if they just have a hunch that it might uncover an opportunity for improvement. (Macomber and Barberio 2007)

Costs in Practice

John Nelson’s work on the Discovery Building at the University of Wisconsin-Madison included an interesting example of the kind of value trade-off that occurs in target value design:

It turned out that the owner expected extremely high-quality lighting in the building, which put pressure on the target value for electrical. To that, we said, “Ok, we can increase the target value for electrical, but we can’t increase the project budget. So what system will we offset that with?” In the end, we used a flat slab concrete structure system that allowed us to take four feet out of the height of the building. We also used digital-integrated design, designing the entire building in AutoCAD, working out all the interferences before we went in the field. Taking four feet out of the height of the building allowed the skin price to come down, which offset the cost of the higher quality lighting. This is an example of the kind of give-and-take required to manage costs.

Value is at the heart of target-value design and is ultimately defined by the client. However, as a project manager, it’s sometimes your job to expand the client’s notion of what constitutes a project’s overall value, perhaps by encouraging the client to think about the project’s entire life cycle, from planning, to construction/manufacturing/implementation, to operation and support, and to product or facility retirement/ decommissioning.

So, what does target-value design look like in practice? Appendix A in The Design Manager’s Handbook (which is available online here: http://onlinelibrary.wiley.com/doi/10.1002/9781118486184.app1/pdf) includes some helpful examples (Mossman, Ballard and Pasquire 2013). Figure 9-1, created by The Boldt Company, provides a graphical representation of key milestones in a target-value design project.

Figure 9-1: Key milestones in a target-value design project (Source: The Boldt Company)

This diagram shows that:

- The target cost was set at $13,100,000 by board approval.

- The initial estimated costs, exclusive of contingencies, were slightly above the target cost.

- The design was modified to enable estimated costs, including contingencies, to approach the target cost.

- The final design included owner-initiated changes that were covered by contingency allowances. As the project advanced, contingency funds were used as needed, although they were reduced as the team managed actual costs to align with estimates, with the goal of keeping total costs within the target budget.

- Unused contingency funds were available at the end to share among project partners.

- Throughout the project, participants took care to check in on the project’s scope, cost, and schedule. In any project, it’s essential to have some process for defining the project scope, identifying potential scope changes, and identifying the cost and schedule tradeoffs necessary to make those changes possible.

~Practical Tips

- When it comes to project costs, don’t try to be all things for all customers: Some organizations do better on low-cost projects, others on high-cost projects. Few can do both. If discussions about value during the planning stage tell you that the customer has a Mercedes appetite with a Chevrolet wallet, then you probably don’t want to work for that customer because you won’t be able to please them.

- Be prepared to learn: Throughout a project, you move along on a continuum of living order to geometric order, where things get more predictable as you proceed. But you never know the total cost of a project until it’s finished.

- Engage stakeholders throughout the budgeting process: It’s essential to keep the conversation going with stakeholders as you make trade-offs, so the stakeholders own all the value decisions

- Don’t shrug off a costing mistake by saying I could only estimate what I knew: To the customer, that means I didn’t know enough. Or worse, I didn’t take the time to learn enough. Be honest and humble about what you do and do not know about costs at any given point, avoid giving the impression that you know more than you do, and never be more precise than is justified.

- Avoid the jargon guaranteed maximum price with qualifications: This phrase, which is very common in the construction industry, is an oxymoron. Something can’t be both guaranteed and qualified.

- Cultivate informed intuition: Developed through experience, informed intuition can be a huge help in estimating. Your informed intuition will improve as you repeat similar projects. In the early stages of your career, seek out mentors who can help speed up your acquisition of informed intuition.

- Don’t make the mistake of waiting to look at costs, budgets, and estimates until you reach a milestone: At that point it’s usually too late. To avoid surprises, check in with the numbers throughout the project. Strive to get the big things right at the beginning, using informed intuition for unknowns. Throughout the project, be prepared to adjust, reset, or stop proactively if a budget bust or estimate overrun seems likely.

- Remember that production/construction costs are not the end of the story: You also need to be upfront about the difference between the production/construction costs, and the total cost of ownership. For example, the total cost of ownership for an engine would include maintenance and replacement parts. In capital projects, this includes fees, furniture, and contingency funds, which can add 30% to 40%. In IT, the life-cycle cost includes maintenance, which is typically 20% of the purchase price.

- Understand the difference between costs in public and private domains: Sometimes, in the public domain, in a very rigid design-bid-build situation, you are given a number for the amount of money you are able to spend. In that case, you simply have to design the project to meet that number. That’s not target valuing. That’s reverse engineering to meet a specific cost at a minimum level of quality.

- Be realistic about your level of uncertainty: At all times, avoid misleading stakeholders into thinking your current level of accuracy is higher than it actually is. Be honest about the fact that the project team’s ability to be accurate will improve over time, as the team gains more information about the project.

- Learn about the financial environment in which your project will unfold: Make sure you understand the financial planning methods of your business. In some companies, costs of test facilities are considered overhead and are part of general and administrative fixed costs. In other companies, the same internal costs are charged directly to each individual project on a “per use” basis. This can drastically affect final project cost viability. Understanding how your company allocates costs and what needs to be included in the project budget is essential for good planning. A best practice way to do this is to have your project plans and budgets audited by a project manager experienced in the company processes.

- Manage contingency funds at a project level: In the same way that a gas expands to fill the available space, spending expands to match the available budget. For this reason, contingency is best managed at a project level, not a task level.

- Create a shared contingency fund: Whenever possible, create a shared contingency fund for the project, so that all stakeholders benefit from staying on budget or are hurt by cost overruns.

- Remember that, in product development, a lower-than-expected volume can affect profitability: In product development, the cost of a product at launch is often higher than expected due to lower volumes. This may impact profitability. Make sure your team understands the path to reaching the target cost at the target volume with contingencies if anticipated volumes are not attained. This is especially true in industries with high fixed costs and low manufacturing costs, such as the pharmaceutical industry.

- Think about possible tradeoffs: Scope, costs, and schedule will typically change as a project advances. As project circumstances evolve, keep asking yourself, “What trade-offs can my team make that are in the project’s best interests?”

- Be prepared to work with a predefined budget: A budget negotiation process in which the team is free to discuss the project and make suggestions is ideal, but sometimes an organization’s leader creates a budget for a project, and the assigned team is charged with making it work one way or the other. In that case, you will need to assess the feasibility of achieving the project’s goals with the assigned budget and either: 1) lead the team in developing an appropriate project strategy and plan; or 2) negotiate with the project sponsor to modify the scope and/or budget to enable your team to confidently commit to delivering the project’s value.

~Summary

- Terminology is important in any technical endeavor, but when it comes to a project’s overall value, miscommunications resulting from incorrectly used terms can result in misaligned expectations and erode trust among project participants. Make sure you understand the difference between budgets and estimates, and the difference between price and cost. Of all the terms related to budgeting a project, the meaning of “value” can be especially difficult to grasp. The most important thing to remember is that value is determined by the customer and then flows back to all participants, shaping all project activities. Delivering value is your primary job as a project manager.

- A project’s budget, estimate, and cost are all affected by the project’s scope. When asked to defend mounting costs, project managers will sometimes argue that the cost increased because the scope evolved, when in fact the real culprit is scope creep. The key to managing scope changes is a Scope Change Request—or a Project Variation Request (PVR) as it is sometimes called—which is a form that must be signed by all affected stakeholders prior to implementation.

- Budgeting is an exercise in refining your focus. You start with a wide-angle estimate, in which the details are necessarily fuzzy, and bit by bit zero in on a sharper picture of project costs. Take care to estimate at the appropriate level of precision: Don’t make the mistake of thinking you can estimate costs to the exact penny or dollar. Successful project managers use the budgeting process as a way to create stakeholder buy-in regarding the use of available resources to achieve the intended outcome. By being as transparent as possible about costs and resource availability, you’ll help build trust among stakeholders.

- To estimate and manage costs effectively, you need to understand the different types of costs, including direct costs, direct project overhead costs, and general and administrative (G&A) overhead costs. The type of contract (for example, fixed-price versus cost-plus) governing your project can affect your consideration of costs. If money is not available from other sources, then cost overruns typically result in a change in the project’s scope or a reduction in overall quality. To prevent this, organizations build contingency funds into their budgets. The exact amount of a contingency fund will vary, depending on project risks; a typical contingency fund is 10% to 15% of the total budget but depends on the risks associated with the project. Shared contingency funds can encourage stakeholders to focus on the well-being of the project as a whole rather than their individual stakes in the project.

- As a project manager, you need to understand the financial expectations for your projects. In private enterprise, cost management is directed toward maximizing profit. But that doesn’t mean that every project is primarily a profit-maximizing undertaking. Within governmental and non-profit organizations, projects are not designed to generate profits but might be launched to reduce costs or generate net revenues that can be used to cover other costs within the organization. A collaborative approach to contracts and procurement helps keep all stakeholders focused on the project’s intended value, rather than simply on short-term profits. Estimating costs accurately is also essential to any organization’s success, and you should be familiar with the two basic types of estimates—top-down estimates and bottom-up estimates—as well as iterative estimates, which combine the best features of top-down and bottom-up estimates.

- Target-value design, a cornerstone of Lean project delivery in the construction field, has applications in nearly all areas of project management. Target-value design focuses on creating the best possible value for the customer without exceeding the project’s target costs. It requires a fundamental shift in thinking from “expected costs” to “target cost.” The target-value design process is collaborative and iterative, typically requiring frequent refinement and conversation among project stakeholders. The ultimate goal of target-value design is to reduce the waste and rework that normally arises in the design/estimate/redesign cycle.

~Glossary

- bottom-up estimate—“Detailed cost estimate for a project, computed by estimating the cost of every activity in a work breakdown structure, summing these estimates, and adding appropriate overheads” (Business Dictionary n.d.). A bottom-up estimator starts by dividing the project up into tasks, then estimates a cost for each task, and sums the total costs for all the project tasks.

- budget—The funds that have been allocated for a project.

- contingency fund—A financial reserve that is allocated for identified risks that are accepted and for which contingent or mitigating responses are developed. Contingency funds are also often available to pay for an agreed-upon scope change.

- cost—“An expenditure, usually of money, for the purchase of goods or services” (Law 2016). Note that, like all terms, the meaning of “cost” varies somewhat from industry to industry. For example, in product development, the term has three specific meanings: 1) cost to create the product or project; 2) cost to establish a manufacturing cell capable of producing the product; and 3) cost of the final good or service to the market.

- direct costs—“An expense that can be traced directly to (or identified with) a specific cost center or cost object such as a department, process, or product” (Business Dictionary n.d.). Examples of direct costs include labor, materials, and equipment. A direct cost changes proportionately as more work is accomplished.

- direct project overhead costs— Costs that are directly tied to specific resources in the organization that are being used in the project. Examples include the cost of lighting, heating, and cleaning the space where the project team works. Overhead does not vary with project work, so it is often considered a fixed cost.

- estimate—An assessment of the likely budget for a project. An estimate involves counting and costing and is based on ranges and probabilities. Throughout a project, managers and team members are asked to estimate remaining work, cost at completion, and required remaining time. An estimate is a forward projection, using what is known, to identify, as best as possible, the required effort, time, and/or cost for part or all of a project.

- general and administrative (G&A) overhead costs—The “indirect costs of running a business, such as IT support, accounting, and marketing” (Investing Answers n.d.).

- iterative estimating—A combination of top-down and bottom-up estimating, which involves constant refinement of the original estimate by taking into account information typically used in a top-down estimate (such as past history of similar projects) and increasingly detailed information generated by bottom-up estimating.

- parametric estimating—A way to use experience from parts of other projects to come up with estimates for work packages that are similar to past work but not the same.

- phase estimating—A type of iterative estimating that is “used when the project is large or lengthy or is developing something new or untried for the organization. In phased estimates, the near-term work is estimated with a high level of accuracy ±5 – 15% whereas future work is estimated at a high level with ±35% accuracy” (Goodrich n.d.). As the project advances through major phases, the budget for subsequent phases is intentionally reviewed and refined in light of knowledge gained to date.

- price—“A value that will purchase a finite quantity, weight, or other measure of a good or service” (Business Dictionary).

- Project Variation Request (PVR)—See Scope Change Request.

- Scope Change Request—A document that describes a proposed scope change, including its potential benefits and the consequences of not implementing the change. A Scope Change Request must be signed by all affected stakeholders prior to implementing a scope change. Also known as a Project Variation Request (PVR).

- scope creep—Changes to a project’s scope without any corresponding changes to the schedule or cost. The term is typically applied to changes that were unapproved or lacked sufficient knowledge about the project and potential assessment of risks and costs when they were approved. Simply put, scope creep is unmanaged change.

- scope evolution— An alteration to the project scope that occurs as the project participants learn more about the project. Scope evolution results in an official change in the project scope, and therefore to the project budget or schedule, as agreed to by all project participants. In other words, scope evolution is managed change.

- target value—The output stakeholders want the project to generate.

- target-value design—A design process that focuses on value as defined by the customer, with the project’s overall design involving stakeholder engagement and collaboration.

- top-down estimates—Estimates that “usually are derived from someone who uses experience and or information to determine the project duration and total cost. However, these estimates are sometimes made by top managers who have very little knowledge of the component activities used to complete the project” (Larson and Gray, 134). A top-down estimator generates a total for the entire project and then divides up that total among the various project tasks.

- value—“The inherent worth of a product as judged by the customer and reflected in its selling price and market demand” (Lean Enterprise Institute 2014).

~References

Business Dictionary. n.d. “Direct cost.” Business Dictionary. Accessed May 2, 2018. http://www.businessdictionary.com/definition/direct-cost.html.

—. n.d. “Engineering cost estimate.” Business Dictionary. Accessed July 15, 2018. http://www.businessdictionary.com/definition/engineering-cost-estimate.html.

—. n.d. “Price.” BusinessDictionary.com. Accessed July 15, 2018. http://www.businessdictionary.com.

Flyvbjerg, Bent, and Alexander Budzier. 2011. “Why Your IT Project May Be Riskier Than You Think.” Harvard Business Review. https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/.

Goodrich, Belinda. n.d. “Budgetary Estimate vs Phased Estimate.” PM Learning Solutions. Accessed May 1, 2018. https://www.pmlearningsolutions.com/blog/budgetary-estimate-versus-phased-estimate-pmp-concept-20.

Investing Answers. n.d. “General and Administrative Expense (G&A).” Investing Answers. Accessed May 1, 2018. http://www.investinganswers.com/financial-dictionary/businesses-corporations/general-and-administrative-expense-ga-6674.

Larson, Erik W., and Clifford F. Gray. 2011. Project Management: The Managerial Process, Sixth Edition. New York: McGraw-Hill Education.

Law, Jonathan, ed. 2016. A Dictionary of Business and Management. Oxford: Oxford University Press. https://books.google.com/books?id=w3owCwAAQBAJ&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false.

Lean Enterprise Institute. 2014. Lean Lexicon, Fifth Edition. Edited by Chet Marchwinski. Cambridge, MA: Lean Enterprise Institute.

Lloyd, Gary. 2015. “Understanding Lean Project Management.” Project-Management.com. May 7. http://project-management.com/understanding-lean-project-management/.

Macomber, Hal, and John Barberio. 2007. “Target-Value Design: Nine Foundational Practices for Delivering Surprising Client Value.” Lean Construction Institute. http://www.leanconstruction.org/media/docs/3-Target-Value-Design-LPC.pdf.

Mossman, Alan, Glenn Ballard, and Christine Pasquire. 2013. “Appendix A: Lean Project Delivery–Innovation in Integrated Design & Delivery.” In Design Manager’s Handbook, by John Eynon, 165-190. http://onlinelibrary.wiley.com/doi/10.1002/9781118486184.app1/pdf.

Nelson, John. 2017. “Conceptual Planning and Cost Management, Parts 1 and 2.” Lecture for CEE 498, Construction Project Management, University of Wisconsin-Madison. February 1.

Rosenthal, Mark. 2009. “First: Define Value.” The Lean Thinker. August 20. http://theleanthinker.com/2009/08/20/first-define-value/.

Symes, Steven. 2018. “Advantages & Disadvantages of a Fixed-Price Contract.” Chron. April 13. http://smallbusiness.chron.com/advantages-disadvantages-fixedprice-contract-21066.html.

Thomack, David. 2018. “Introduction to Lean and Project Delivery.” Video Lecture for CEE 498: Construction Management. University of Wisconsin-Madison, College of Engineering, April 20.

10

Allocating and Managing Constrained Resources

Limitless material resources are not only unavailable most of the time, they may actually be a hindrance. And remaining lean and mean can often be a blessing.

—Michael Gibbert, Martin Hoegl, and Liisa Välikangas (In Praise of Resource Constraints 2007)

Objectives

After reading this lesson, you will be able to

- Discuss basic concepts related to resource management, including over-commitment and over-allocation

- Explain some geometric-order resource optimization techniques, including resource leveling, resource smoothing, and the critical chain approach

- Describe challenges related to resource allocation in Agile

- Discuss ideas related to sustainability and the triple bottom line

- Identify issues affecting resource management at the portfolio level

- List some advantages of resources constraints

The Big Ideas in this Lesson

- You have to have the right resources at the right time. This involves staying flexible and making changes as necessary, rather than hewing to a predefined structure that might not be useful as conditions change.

- Constraints on resources are inevitable, but by combining geometric-order techniques such as resource leveling and resource smoothing with an adaptive, living order approach, you can prevent project crises.

- Project managers have to look outside their projects to find the resources they need. Somehow, within their organizations, they have to secure the resources they need. Meanwhile, on the portfolio-level, executives have to manage resources to ensure that they are available for many projects over the long term.

10.1 Managing Resources in Living Order

The most detailed schedules and budgets in the world are useless if you don’t have the people, equipment, facilities, and other resources you need, when you need them. In reality, the schedule is only determined after the resources have been assigned. In other words, until you have assigned and committed resources, your project schedule and budget are not fully realized. They are based on assumptions, which are a huge source of uncertainty. This is especially true in the IT world, where productivity can vary so much from one person to another. You can’t really have a clear idea of how fast your team can work until you know who’s on the team.

Acquiring project resources usually involves looking outside the boundaries of the project itself to find what you need. In the early stages, that includes finding the right people for your project team. Inevitably, you will face restrictions on the resources available to you. And yet, to complete a project successfully, you have to figure out how to get the resources you need—people, office space, Internet bandwidth, computer, copper wire, shingles, 3-D modeling equipment, concrete, and so on—when you need them.

That’s why understanding the principles of resource allocation is so essential to successful project management. Most definitions of “resource allocation” describe it as something that takes place on the organization level, as in the following: “Resource allocation is the process of assigning and managing assets in a manner that supports an organization’s strategic goals” (Rouse n.d.). On the project level, resource allocation still involves making choices that support the organization’s strategic goals, but you also have to factor in your project’s more specific goals. In all cases, resource allocation (or resource management as it is sometimes called) includes “managing tangible assets such as hardware to make the best use of softer assets such as human capital. Resource allocation involves balancing competing needs and priorities and determining the most effective course of action in order to maximize the effective use of limited resources and gain the best return on investment” (Rouse n.d.).

Resource management is about making sure you have the resources you need at the right time, but it’s also about avoiding stockpiling resources unnecessarily (and therefore wasting them) and about “making sure that people are assigned to tasks that will keep them busy and not have too much downtime” (Business Dictionary n.d.).

The essence of resource allocation is resource loading, or the process of assigning resources (most often people) to each and every project activity. In resource loading, we look at the tasks involved in the project, and then, using past experience and some judgment, determine how much work (typically measured in person hours) to assign to each resource in order to achieve the desired schedule. In the early stages of a project, resource loading provides a quick check on resource demand and supply. Any indication that demand is tight for a particular resource should serve as a warning that you will have to carefully monitor that resource throughout the project. In any resource loading decision, you need to distinguish between fixed resources (which remain “unchanged as output increases”) and variable resources (which change “in tandem with output”) (Reference n.d.).

The Screwdriver Rule

Investing in resources you might need, but don’t necessarily need immediately, is similar to keeping screwdrivers of varying sizes available in your tool drawer at home. You would never want to have to go out and buy a screw driver just to complete a quick task like tightening the legs on a chair. Most people would agree that the cost of buying and storing a set of screw drivers is less than the inconvenience of not having them on hand when you need them. In the same vein, a project manager might make a similar value judgement about resource availability to ensure that the project as a whole progresses smoothly. But of course you don’t ever want to unnecessarily stockpile resources that could be used elsewhere in your organization.

The geometric order approach to resource allocation presumes a systematic process, in which you know well in advance which resources you’ll need at any one time and have a clear path to acquiring those resources. This is the ideal situation and is usually the result of years of experience that allow managers to foresee needs way down the road. For example, mature project management organizations know to hire staff in anticipation of upcoming project needs and provide developmental opportunities to challenge and retain their best employees. By contrast, less experienced project management organizations identify project teams on a “just in time” basis that can compromise a project from the beginning.

While having everything you want when you need it is the ideal, it’s rarely the norm in the permanent whitewater of the living order. In a changeable environment, resource allocation is all about adaptation. You might start by planning the necessary resources in a geometric way. However, altering circumstances could mean you need to revise your plan day-to-day. In other words, in living order, you need to actively manage the resources required for your project tasks. You can’t assume that because you’ve made a plan, every person and everything you need will show up on time, according to your plan.

For example, in manufacturing, when installing a new piece of automation, a company absolutely must have maintenance, manufacturing engineers, and control staff available to jump in when they are needed. The schedule might spell out detailed dates, but everyone still has to remain flexible because their piece of the work will affect the overall timeline. Adding to the complexity of the situation, the personnel working on your project may have to be available to staff the rest of the plant. They might suddenly need to postpone work on your automation project in order to work on a crisis affecting a particular customer order.

And keep in mind that from one project to the next, your control over day-to-day assignment of resources could vary considerably. In most situations, project managers need to coordinate, negotiating and contracting with others to get resources when they need them. What’s more, there’s often a time lag between identifying the need for a resource and getting it deployed. This is especially true for research-oriented tasks, in which resolving unknowns sets the pace of progress.

Getting Creative with Resource Management

Successful project managers aren’t afraid to get creative in their approach to resource management. An interesting example of resource control in highway construction requires contractors to rent lanes per day until they finish working on them. This method is described here: http://www.dot.state.mn.us/const/tools/documents/Lanerentalonly.pdf.

In some situations, you shouldn’t even assume that you know what resources you will need in the first place. It can be hard to accept this fact, even in organizations that have fully embraced living order. In their article “Managing Resources in an Uncertain World,” John Hagel, John Seely Brown, and Lang Davison argue that even the most well-conceived pull plan—a plan informed by the best precepts of Lean—can be limited by the assumption that the planners know exactly what resources they need in the first place. To overcome this challenge, they argue for an even more flexible version of pull planning:

In a world of accelerating change, we no longer can be certain we know what to seek. What happens when we don’t even know that a product or person exists, yet that product or person is highly relevant to our needs of the moment? Lean manufacturing systems at least assume that we know what we need at any point in time…. Increasingly, we need pull platforms that can bring us relevant resources that we did not know existed but are useful to us. They must do this in a scalable fashion as well since the resources may be in a remote part of the world or developed by individuals who are just beginning to become visible with newly acquired skills. In other words, these pull platforms must offer serendipity as well as robust search capability. (Hagel III, Brown and Davison 2009)

Seeing the Big Picture

Resource allocation occurs within a broader organizational context, subject to pressures that go beyond an individual project. That means that getting and using the resources you need, when you need them, is rarely as simple as it might seem when spelled out in a project schedule. As discussed in Lesson 2, in a well-run organization, project selection is guided by the organization’s overall strategy. The same is true of resource allocation; decisions about what resources will be available to which projects are, ideally, made in alignment with the organizational strategy. For project managers, it’s important to keep this in mind. It might be better for you and your project to have access to a certain resource on a certain day, but that might not necessarily be the best option for the organization as a whole.

Other realities can affect your ability to gain access to and pay for a resource. In the case of a scarce piece of equipment, you might try to reserve it for more time than is strictly necessary, so you can use it when you need it. This allows you to purchase flexibility, but that flexibility might be more expensive than you can afford. However, if you let a critical resource go, you might not get it back when you need it, or you might need to pay a charge for reactivating the resource. In other situations, you may be forced to pay for more than you need. For example, in projects involving union labor, you might have to pay for a half-day of labor for someone to operate equipment that you actually only need for two hours. All of these factors affect the reality of getting a resource, how much it costs, and when it is available.

Another important factor affecting the allocation of resources is the often intense competition for resources within an organization. In an article describing how the pharmaceutical company SmithKline Beecham (SB) improved its resource-allocation process, Paul Sharpe and Tom Keelin acknowledge the realities of intra-organizational competitiveness:

How do you make good decisions in a high-risk, technically complex business when the information you need to make those decisions comes largely from the project champions who are competing against one another for resources? A critical company process can become politicized when strong-willed, charismatic project leaders beat out their less competitive colleagues for resources. That in turn leads to the cynical view that your project is as good as the performance you can put on at funding time…. One of the major weaknesses of most resource-allocation processes is that project advocates tend to take an all-or-nothing approach to budget requests. At SB, that meant that project leaders would develop a single plan of action and present it as the only viable approach. Project teams rarely took the time to consider meaningful alternatives—especially if they suspected that doing so might mean a cutback in funding. (1998)

The improved resource allocation process that Sharpe and Keelin developed was systematic and value-driven, but the key to their approach came down to one thing: better communication among project managers and other stakeholders. This, in turn, allowed them to trust each other, so they could turn their attention to the company’s overall strategic goals rather than skirmishing over available resources. Sharpe and Keelin found that “by tackling the soft issues around resource allocation, such as information quality, credibility, and trust, we had also addressed the hard ones: How much should we invest and where should we invest it?”

In other words, resource allocation is yet another area of project management in which good communication can help smooth the way to project success.

Over-Commitment, Over-Allocation, and Risk Management

Resource allocation is inextricably tied up with risk management. If you fail to secure the resources you need, when you need them, you risk delays, mounting costs, and even project failure. Two of the most common ways that a needed resource can suddenly become unavailable to your project are

- over-commitment: A resource allocation error that occurs when a task takes longer than expected, tying up the resource longer than originally scheduled.

- over-allocation: A resource allocation error that occurs when a resource is allocated to multiple projects with conflicting schedules, making it impossible for the resource to complete the assigned work on one or more of the projects as scheduled.

In an article for TechRepublic.com, Donna Fitzgerald explains the distinction:

An individual can theoretically be over-allocated to many projects; an individual can be overcommitted only to a specific body of work.

The reason for this distinction is that over-commitment and over-allocation really are two separate problems. If an individual is assigned a task and the work on that task turns out to be twice the effort originally estimated—and the project duration isn’t moved out—the individual is overcommitted. If a person is allocated to multiple projects, then it’s an issue of over-allocation. I believe that problems arise because of a failure to admit that a single person can’t be in two places at the same time. (Fitzgerald 2003)

Fitzgerald argues that over-commitment is a problem that a project manager can typically resolve within the confines of individual projects. Over-allocation, by contrast, is something that can only be fully solved “at the organizational level…by establishing clear project priorities and a clear process for mediating the inevitable conflict in priorities” (Fitzgerald 2003). The unfortunate fact is that if you face an organization-wide over-allocation problem, you may have no option but to deal with it as best you can. Successful project managers learn to ride the waves of over-allocation whitewater, making do with the resources made available to them:

In the final analysis, resource overallocation is a failure of prioritization, a failure of planning, and a failure to accept that reality always imposes constraints. The nimble project manager understands that things will always change and that even in the best of systems there will be times when multiple projects are competing for the same resource. The only way to really solve this problem is by eliminating unnecessary conflicts in the initial planning stages through prioritization and project timing and by establishing the discipline to make conscious decisions about which projects slip and which stay on track when Murphy’s Law comes into play. (Fitzgerald 2003)

But is there something individual project managers can do to prevent over-allocation from causing havoc with their projects? Fitzgerald suggests that you start by learning more about how resources are allocated in your organization. A good way to do this is to recruit “other project managers into a Community of Practice” as she explains in this helpful article: http://www.techrepublic.com/article/with-a-little-help-from-my-friends-exploring-communities-of-practice-in-project-management/. Fitzgerald argues that such groups can go a long way towards resolving all sorts of project team rivalries, including rivalries involving resource allocation:

The key is to get a group of PMs together and to establish a planning committee that would work to keep PMs from stepping all over one another. Simply making the decision to avoid letting the situation reach the crisis point and to open up the communication channels will begin to reduce the probability that resources are mythically overallocated. (Fitzgerald 2003)

Fitzgerald also suggests applying risk management techniques to critical resources from the earliest days of project planning:

As a general practice, I begin every project by identifying my critical resources and developing a contingency plan for replacement or substitution of those resources in the event of an emergency…. By establishing nothing more than the most minimal practice of risk management, you can ensure that resource problems are brought to light early in the project life cycle rather than later when the solutions are more limited and more expensive. (Fitzgerald 2003)

10.2 Geometric Resource-Optimization Techniques

So far, we’ve focused on several ways living order can disrupt your best-laid resource allocation plans. But that’s not to say that, when thinking about resources, you should dispense with careful, geometric-order planning. Far from it. In the next two sections, we look at some helpful resource-optimization techniques.

Resource Leveling and Resource Smoothing

Two important resource allocation tools available to a project manager are resource leveling and resource smoothing. These techniques make use of slack (also called float) which, as you learned in Lesson 7, is the amount of time that a task can be delayed without causing a delay to subsequent tasks or the project’s completion date. Understanding the distinction between the resource leveling and resource smoothing can be tricky, so let’s start with basic definitions:

- resource leveling: An “approach to project scheduling whereby task start and end dates are determined by the availability of internal and external resources…. Resource leveling will resolve over-allocations by moving task start and end dates, or extending task durations in order to suit resource availability” (ITtoolkit n.d.). Resource leveling may modify the critical path or extend the duration of the project, depending on the availability of critical resources, and the ability to accomplish required leveling using available slack/float.

- resource smoothing: “A scheduling calculation that involves utilizing float or increasing or decreasing the resources required for specific activities, such that any peaks and troughs of resource usage are smoothed out. This does not affect the overall duration” (Association for Project Management n.d.).

Because of the complexities involved, both resource leveling and resource smoothing are typically done using project management software such as Microsoft Project. A blog post for the Association for Project Management distinguishes between resource leveling and resource smoothing as follows:

Resource smoothing is used when the time constraint takes priority. The objective is to complete the work by the required date while avoiding peaks and troughs of resource demand. Resource leveling is used when limits on the availability of resources are paramount. It simply answers the question “With the resources available, when will the work be finished?” (Association for Project Management n.d.)

In resource leveling, the project manager moves resources around in the schedule in order to level off some of the peaks and valleys of resource requirements. Task start dates are modified as necessary to use slack wherever possible to reduce resource conflicts. If necessary, activity start dates are shifted further to eliminate resource constraints; these shifts beyond initial slack constraints extend the duration of the project. You can see some examples of resource leveling here: http://www.mpug.com/articles/resource-leveling-best-practices/.

Even after judicious resource leveling, you may still find that demand for one or more resources exceeds existing constraints in order to meet a schedule requirement. For example, you might find that you simply don’t have enough experienced electricians on-staff to complete a task by a fixed milestone date. In that case, you will need to consider adding resources to the project—for example, perhaps by hiring some electricians from another firm. But remember that bringing on new resources may temporarily slow the project due to the time it takes for both the project team and the new resource to adjust. When facing insurmountable resource constraints, you might find that you simply have to extend the schedule or modify the project’s scope.

Note that resource leveling, as described here, is rarely appropriate in the world of software development projects. Unless the people on the project have experience that is relevant to the tasks to be accomplished and have worked on similar projects with well-defined scope, then resource leveling may not prove useful. However, resource leveling can be useful in software consulting firms that perform system upgrades for clients and have established a repeatable process for doing the upgrade.

Reducing Resource Use Through Schedule Compression: Yes and No

Managers often assume that the schedule compression techniques discussed in Lesson 7 can have the side benefit of reducing indirect costs for resources like maintenance personnel, administrative staff, or office space. This is true in some fields, making it a very useful option. But it doesn’t typically work in the IT world, as documented by Steve McConnell in his book Rapid Development: Taming Wild Software Schedules. He explains that focusing too much on schedules at the expense of other resource-intensive work such as planning and design will almost always result in a late project:

You can use the strongest schedule-oriented practices, but if you make the classic mistake of shortchanging product quality early in the project, you’ll waste time correcting defects when it’s most expensive to do so. Your project will be late. If you skip the development fundamental of creating a good design before you begin coding, your program can fall apart when the product concept changes partway through development, and your project will be late. And if you don’t manage risks, you can find out just before your release date that a key subcontractor is three months behind schedule. You’ll be late again. (1996, 9)

Critical Chain Approach

In Lesson 7 you learned about the critical path method of schedule management, which helps identify the minimum total time required to complete a project—that is, the critical path. This way of thinking about a project focuses on finding the right order for tasks within the schedule. By contrast, a related scheduling method, the critical chain method (CCM), focuses on the resources required to complete a project, adding “time buffers to account for limited resources” (Goodrich 2018). Critical chain management was first introduced by Eliyahu M. Goldratt in his 2002 book Critical Chain. To learn more about this important topic, start by reviewing this summary: https://www.simplilearn.com/what-is-critical-chain-project-management-rar68-article. This helpful video explains the basic concepts related to the critical chain method: https://www.youtube.com/watch?v=mpc_FdAt75A.

10.3 Estimating Resource Capacity in Agile

In theory, resource management in Agile should be simple. After all, in Agile, resources and time are usually fixed. The team has a fixed budget, a fixed number of programmers, and a fixed amount of time to create working software. The variable in all this is the software itself. Throughout the cycle of sprints—as the customer tries out new software, and requests alterations—the software features can change dramatically. When the budget is exhausted, the project ends. But because Agile developers create working software bit-by-bit, the customer is assured of having at least some usable features by that point.

So again, resource management in Agile should be simple—in theory. But in reality, the key resource in software development is the people who create the software. And as you learned in the discussion on teams in Lesson 5, where people are concerned, things rarely go as planned. Some programmers work faster than others, and individuals can vary tremendously in their output from one week to the next, especially when dealing with personal problems, like illness or family conflict. Robert Merrill, a Senior Business Analyst at the University of Wisconsin-Madison, and an Agile coach, puts it like this:

Agile is more about people than computers. People are not interchangeable, they have good days and bad days. They get along or they don’t. Cognitive abilities vary tremendously. If you aren’t successful in helping teams gel and stay focused, you’re going to spend lots of extra money, or the project may blow up. You need to get the teams right. (Merrill 2017)

As Gareth Saunders explains in a thoughtful blog post on the topic, this is all complicated by the amount of “business as usual” tasks that developers typically have to fit into their schedules on top of their work on specific Agile projects. This includes tasks like “admin, team communications, support, mentoring, meetings, and consultancy—offering our input on projects managed by other teams” (Saunders 2015). As a result, as a project manager, Saunders struggles to answer the following questions:

1. How do we know how much time each team member has to work on projects?

2. When we’re planning the next sprint, how do we track how much work has been assigned to a team member, so that they have neither too little nor too much work? (Saunders 2015)

Again, in theory, this should not be difficult. If you have, for instance, “five developers, each with 6 hours available for work each day. That gives us 30 hours per day, and assuming 9 days of project work (with one full day set aside for retrospective and planning) then within each two-week sprint we should be able to dedicate 270 hours to development work” (Saunders 2015). In reality, however, business as usual tasks can eat up 40% of a programmer’s working week, with that percentage varying from week to week or month to month.

Difficulties in estimating a team member’s capacity for work on a project is something every project manager faces. But in Agile, estimating capacity can be especially difficult. As you learned in Lesson 5, in Agile, project managers (or Scrum masters) ideally exert minimal direct influence on day-to-day work, because teams are supposedly self-organizing—that is, free to manage their work as a group, and pull work when they are ready for it. This means Agile project managers need to take the long view on resource management by practicing good resource capacity management, which involves “planning your workforce and building a skill inventory in exact proportion to the demand you foresee. It lets you optimize productivity and as a concept perfectly complements the Agile methodology” (Gupta 2017).

Interested in learning more about managing resources in Agile? Start with these links:

- You can read more about resource capacity management here: https://project-management.com/resource-capacity-planning-for-agile-teams/.

- Gareth Saunders’ blog post, and the accompanying comments, walk you through some of the challenges of Agile resource management: http://digitalcommunications.wp.st-andrews.ac.uk/2015/11/09/the-challenges-of-resource-management-in-our-agile-team/

10.4 Resources and the Triple Bottom Line

When making decisions about resources, you may naturally focus on what will allow your team to finish a project as quickly and efficiently as possible. As a result, you might be tempted to make decisions that use more fuel than is strictly necessary, exploit cheap labor, or pollute a local lake. But that approach fails to take into account the longer view on personal and organizational responsibility that lies at the core of the sustainability movement.

John Elkington introduced the term triple bottom line (TBL) as a way to broaden corporate thinking about the cost of doing business to include social and environmental responsibilities. Rather than focusing solely on profit and loss, Elkington argued that organizations should pay attention to three separate bottom lines:

One is the traditional measure of corporate profit—the “bottom line” of the profit and loss account. The second is the bottom line of a company’s “people account”—a measure in some shape or form of how socially responsible an organization has been throughout its operations. The third is the bottom line of the company’s “planet” account—a measure of how environmentally responsible it has been. The triple bottom line (TBL) thus consists of three Ps: profit, people, and planet. It aims to measure the financial, social, and environmental performance of the corporation over a period of time. Only a company that produces a TBL is taking account of the full cost involved in doing business. (The Economist 2009)

More and more, organizations are incorporating sustainability concerns into their long-term strategies, in part because their customers demand it, and in part because the sustainable choice often turns out to be the profitable choice. If you are lucky enough to work for an organization that is fully invested in its triple bottom line, you will be encouraged to make resource allocation decisions that reflect sustainability concerns. If your organization isn’t there yet, consider staking out a position as an agent of change, educating colleagues about the benefits of the triple bottom line. You can start by educating yourself. The following resources are a good first step:

- Cannibals with Forks: The Triple Bottom Line of 21st Century Business: In this 1999 book, John Elkington first introduced the idea of the triple bottom line. (Note that it was originally titled Cannibals with Food Rakes, and often shows up with that title in web searches.)

- This brief introduction summarizes the basic issues related to the triple bottom line: https://www.economist.com/node/14301663.

10.5 From the Trenches: John Nelson on Resources at the Portfolio Level

As an executive concerned with the well-being of an entire organization, John Nelson has to look at resource management on a portfolio level. Whereas individual project managers naturally focus on short-term resource availability for their projects, an executive’s goal is ensuring that resources are available for many projects over the long term. In a recent lecture, he offered some thoughts on managing resources at the portfolio level:

Whether you’re deploying capital resources, outside resources, or your own internal staffing resources, it’s almost axiomatic that you will face resource constraints in living order. When considering how a particular project fits within a larger portfolio, you need to keep in mind the organization’s resource elasticity, and the organization’s ratio of percentage of creative personnel.

Let’s start with resource elasticity. Organizations can be whipsawed by projects that are so large they consume a disproportionate amount of the organization’s resources. If a project like that ends abruptly, for an unexpected reason, the organization will struggle to get project resources redeployed. To avoid this, it’s a good idea to make sure no project exceeds one-third (or in some cases one-fourth) of the organization’s total capacity.

Now let’s consider the critical ratio of creative people to people who excel at execution. Some projects require a lot of creativity and thinking. Some just require execution. If you have a portfolio of highly creative assignments, but a resource base that’s largely execution-oriented, you’re going to struggle. The opposite is also true: if you have lots of execution-oriented projects with only highly creative people on staff, you might complete the project successfully, but you’ll probably burn through resources faster than you want, because creative people aren’t as efficient and effective at execution. It almost goes without saying, though, that you do have to have creative people in your organization. In living order, it’s rare that I come across a project that doesn’t involve any creative people. My rule of thumb is to have about 30% of my staff to be highly creative. This has worked well for me, although sometimes 40% or even 50% is best.

You have to keep these kinds of concerns in mind as you look at projects in portfolios, at the organizational level, to make sure that over the long term you have a reasonable chance of meeting the value proposition, meeting the customer’s expectations, and maintaining the health of your organization. (Nelson 2017)

10.6 Externalities and Looking to the Future

A project manager with a serious appreciation for living order understands that external factors may fluctuate during project execution, making previously widely available resources impossible to obtain. For example, there may be a run on certain materials, or a certain type of expertise might suddenly be consumed by an emergency somewhere in the world. Any development like this can force you to rethink your original expectations. You need to be prepared to adapt your budget, scope, and schedule to the realities that evolve during project execution.

Keep in mind that resources can become suddenly scarce. For example, right now materials engineers are a hot commodity, because more engineers are retiring than entering this field. Compounding the problem, new designs and manufacturing techniques have expanded the need for materials engineers. A 2018 check of Indeed.com turned up over 47,000 openings for materials engineers. As you might expect, new engineering students are responding to the call. At the UW-Madison, enrollment in this area of engineering has grown dramatically. But it will still be a while until there is enough materials expertise to go around.

And keep in mind that a constraint on the availability of resources is not necessarily the worst thing that can happen to an organization or to an individual project. In fact, the origins of Lean and the Toyota Production System can be traced back to resource constraints in Japan at the end of World War II. In an article for MIT Sloan Management Review, Michael Gibbert, Martin Hoegl, and Liisa Välikangas argue that abundant resources can sometimes stifle innovation:

Resource constraints fuel innovation in two ways. In a 1990 article in Strategic Management Journal, J.A. Starr and I.C. MacMillan suggested that resource constraints can lead to “entrepreneurial” approaches to securing the missing funds or the required personnel. For example, the Game Changer innovation program of Royal Dutch Shell Plc long operated on the shoulders of its social network, which allowed innovators to find technically qualified peers willing to contribute to their efforts on a complimentary basis. In other words, individuals innovate despite the lack of funding by using social rather than purely economic strategies. Thus tin-cupping, horse trading, boot strapping, and currying personal favors partly or wholly substitute for economic transactions in which non-entrepreneurial innovators (or those less socially connected) would pay the full price.

Such efforts speak for “resource parsimony”—deploying the fewest resources necessary to achieve the desired results. For instance, new product development teams might use testing equipment on weekends, when it is readily available and free. Likewise, team members might know engineers or other professionals—say, from supplier firms involved in past projects—who would be glad to give informal design reviews in anticipation of future remunerative work.

Resource constraints can also fuel innovative team performance directly. In the spirit of the proverb “necessity is the mother of invention,” teams may produce better results because of resource constraints. Cognitive psychology provides experimental support for the “less is more” hypothesis. For example, scholars in creative cognition find in laboratory tests that subjects are most innovative when given fewer rather than more resources for solving a problem.

The reason seems to be that the human mind is most productive when restricted. Limited—or better focused—by specific rules and constraints, we are more likely to recognize an unexpected idea. (Gibbert, Hoegl and Välikangas 2007)

Gibbert et al. argue that managers with access to all the resources they could possibly want tend to fall into the trap of throwing money at problems, rather than sitting down to think of effective solutions to the kinds of problems that arise in the permanent whitewater of the modern business world. Then, when projects fail, “rationalizations often start with excuses such as ‘We ran out of money’ or ‘If only we had more time.’ In such cases, the resource-driven mindset may well have backfired. Resource adequacy is in the eye of the beholder, and if a team has the perception of inadequate resources, it may easily be stifled.”

Gibbert et al. describe several projects in which resource constraints turned out to be a blessing, not a curse. For example:

In the post–World War II era, several American teams under General Electric Co., and several German teams under Bayerische Motoren Werke AG were competing against each other in a race to resolve the jet engine performance dilemma. The stakes were high, given that the Cold War had started and the West was eager to come up with reliable jet technology before the Soviet Union did. The German team eventually won by proposing a radical departure from the status quo, an innovation that is in fact is still used today. It developed a “bypass” technology in which the rotor blades and other engine parts most exposed to high temperatures were hollowed out so that air could flow through them, thereby cooling them off.

Whence this idea? The American team had a virtual blank check to buy whatever costly raw materials it needed to create the most heat resistant alloys (the Cold War jet propulsion development program cost the U.S. government nearly twice as much as the Manhattan Project). The German team, by contrast, was forced to rely on cheaper alloys, as it had significantly less funding at its disposal and simply couldn’t afford the more expensive metals. (Gibbert, Hoegl and Välikangas 2007)

Don’t underestimate the management hours required to keep track of a high number of resources. For example, an experienced manager of engine-related projects reported that more than 50 core team members was too many for one project manager to keep track of. With over 50 team members, the burden of coordination and communication often outweighed the benefit of extra resources.

Resource Management and Proactive Resilience

In their book Becoming a Project Leader, Alexander Laufer, Terry Little, Jeffrey Russell, and Bruce Maas discuss the benefits of proactive resilience—taking timely action to prevent a crisis, often by introducing a change that upends the usual way of doing things. In living order, where resource availability is never a given, proactive resilience is an essential component of good resource management.

As an example of proactive resilience in action, Laufer et al. describe the work of Don Margolies, a project manager in charge of NASA’s Advanced Composition Explorer, a robotic spacecraft launched into orbit in 1997 to collect data on solar storms. At one point, facing a $22 million cost overrun related to the development of nine scientific instruments, his dramatic intervention ultimately saved the project:

Don concluded that unless he embarked on an uncommon and quite radical change, the project would continue down the same bumpy road, with the likely result that cost, and time objectives would not be met. To prevent this, he made an extremely unpopular decision: He stopped the development of the instruments, calling on every science team to revisit its original technical requirements to see how they could be reduced. In every area—instruments, spacecraft, ground operation, integration and testing—scientists had to go back and ask basic questions, such as “How much can I save if I take out a circuit board?” and “How much performance will I lose if I do take it out?”

At the same time, Don negotiated a new agreement with NASA headquarters to secure stable funding, detached from the budget of the other six projects affiliated with the Explorers program. To seal the agreement, he assured them that by reducing his project’s scope, it would not go over budget. With the reduced technical scope and the stable budget, the ACE project gradually overcame both its technical and organizational problems. Eventually, it was completed below budget, and the spacecraft has provided excellent scientific data ever since. (Laufer, et al. 2018, 57)

Resource parsimony is not the answer to every resource allocation problem, but it can definitely stimulate new and effective approaches that might otherwise go undiscovered. In the same way, the many living order challenges facing today’s organizations can encourage managers to develop new ways to manage resources.

~Practical Tips

- Similar does not mean equal: Similar resources are not necessarily interchangeable. For instance, two people might work under the title “Senior Designer.” However, because of education and experience, one of them might be far more suited to your project. The problem is, computerized resource allocation methods often fail to distinguish differences among similar resources. Whenever possible, take the time to evaluate the people and other resources that are key to your project to ensure that you have allocated the appropriate resources. Plan projects based on an average capability resource. That way, across all projects, the estimates should even out to be about right. If it takes a good designer three days to design a part and a less capable designer five days, you should plan on four days for designer time.

- Economic downturns and upturns can affect resource availability: Economic conditions influence the cost and availability of high-demand resources. You might need some expertise that changing economic conditions or changing technical requirements make it difficult for you to get when you need it. The same may be true in reverse. Sometimes, because the economy is in a downturn, certain resources become more available. These factors may influence the cost and availability of resources needed for your project.

- Share resource allocation decisions to gain buy-in: If possible, try to make resource allocation decisions available to your entire organization. This will encourage people outside your specific project to buy in to your project’s goals. It can also help minimize the kind of resentment that arises when project managers are competing for scarce resources. This phenomenon is explained in the blog post “5 Ways Top Project Managers Allocate Their Resources”:

Resourcing isn’t just for your team—it applies to the rest of your company too. Think beyond project life cycle planning; when allocations are visible to everyone, the entire agency can see how pieces fit together and where their “quick tweaks” or internal projects align with the grand scheme of things. This can significantly cut down on emails, facilitate conversations that would otherwise require rounds of meetings, and serve as a precursor to monthly budget reviews or executive presentations. A resourcing system visible to key parties and departments, and sortable by tasks and skills, can help tremendously while preparing budgets and schedules. Top project managers make sure the bigger picture is always in perspective. (MICA 2014)

- Keep marginal costs in mind: Economies of scale prevail in resource management, but only to a certain point. You need to keep in mind the marginal cost of a resource. For example, the hourly cost of labor may be fixed to a point, but once you move from regular hours to overtime hours, the marginal cost increases significantly. So always look at the marginal cost of existing personnel or equipment hours, versus the new marginal cost of adding personnel or equipment hours.

- Think strategically about who should control a particular resource: As you have more control over a resource at the project level, you typically have more cost for carrying that resource through the project. That does give you more flexibility, but what is best at the project level may not be best for the overall organization. It’s possible that having a resource controlled at the organizational level may give greater flexibility for the organization overall.

- Understand minimum units of allocation: It’s rarely helpful to allocate 3.8 people to a task. Instead, it is almost always more realistic to allocate 4 people full-time. Similarly, most facilities can only be realistically hired by the day/week and not by the hour/minute. Understanding minimum units of allocation is important in realistic planning.

- Plan for shared resources: In an ideal world, all resources are dedicated solely to your project. However, it is more common to have shared resources. If you are working on a project with shared resources, you’ll need to schedule your use of those resources even more carefully than if they were dedicated solely to your project.

- Be prepared to wait for resources: Some equipment or facilities have to be booked in advance. Once you book them, you may not have flexibility to change your dates. This is a good opportunity to practice contingency planning: what other work can continue while you wait for a resource to become available?

- Beware personnel turnover: In long-running projects, highly skilled people retiring or moving on to new jobs can be a major issue, and something you should beware of as you allocate human resources to your project. Any transition of key leadership can have an impact on a project’s progress and directly affect its overall success. Do all you can to proactively manage transitions throughout a project. Managing Transitions: Making the Most of Change, by William Bridges, is a classic resource on managing change in the workplace. It includes practical assessments that the readers can use to improve their own transition management skills.

- Allocate resources by name when necessary: If a specific resource—such as a particular test cell or person—is essential to project success, then take care to allocate that resource on a named basis, rather than as a general category of resource—for example, “Anita Gomez,” rather than “Designer.” However, you should avoid this specificity in all but the most critical cases, as it reduces flexibility and hinders developmental opportunities (increasing general bench strength).

- Do all you can to prevent burnout: Be careful of overextending the people on your team. Stretching to the point of strain can cause unnecessary turnover, with no extra hours available for pitching in at crunch times. A good rule of thumb is to allocate a person 85%; this leaves time for vacation, development, and company projects.

~Summary

- Resource management is about making sure you have the resources you need at the right time, but it’s also about avoiding stockpiling resources unnecessarily (and therefore wasting them). The most detailed schedules and budgets in the world are useless if you don’t have the people, equipment, facilities, and other resources you need, when you need them. Until you have assigned and committed resources, you don’t have a project schedule and your budget has no real meaning.

- The essence of resource allocation is resource loading, or the process of assigning resources (most often people) to each and every project activity. While having everything you want when you need it is the ideal, it’s rarely the norm in the permanent whitewater of living order. In a changeable environment, resource allocation is all about adaptation and seeing the big picture.

- Resource allocation is inextricably tied up with risk management. If you fail to secure the resources you need when you need them, you risk delays, mounting costs, and even project failure. Two of the most common ways that a needed resource can suddenly become unavailable to your project are over-commitment (which occurs when a task takes longer than expected, typing up a resource longer than expected) and over-allocation (which occurs when a resource is allocated to multiple projects with conflicting schedules).

- For resource allocation, two important geometric-order tools are resource leveling and resource smoothing. Another helpful option is a scheduling method known as the critical chain method (CCM), which focuses on the resources required to complete a project.

- In Agile, where time and money are typically fixed, managing resources is theoretically a simple matter. However, the self-organizing nature of Agile teams presents special resource allocation challenges which can be overcome through resource capacity management.

- John Elkington introduced the term triple bottom line (TBL) as a way to broaden corporate thinking about the cost of doing business to include social and environmental responsibilities. Elkington argued that rather than focusing solely on profit and loss, organizations should pay attention to three separate bottom lines: profit, people, and the health of the planet.

- Whereas individual project managers naturally focus on short-term resource availability for their projects, an executive’s goal is ensuring that resources are available for many projects over the long term. When looking at resources from the portfolio level, try to make sure no project exceeds one-third to one-fourth of the organization’s total capacity. Also keep in mind that some projects require a healthy contingent of highly creative people, but too many creative people on a project can hamper execution. A good rule of thumb is to have about 30% of staff be highly creative.

- You need to be prepared to adapt your budget, scope, and schedule to the externalities that evolve during project execution. And keep in mind that a constraint on the availability of resources is not necessarily the worst thing that can happen to an organization or to an individual project. You can forestall crises related to resources by practicing proactive resilience—that is, by taking timely action to prevent a crisis, often by introducing a change that upends the usual way of doing things. In living order, where resource availability is never a given, proactive resilience is an essential component of good resource management.

~Glossary

- fixed resource—A resource that “remains unchanged as output increases” (Reference n.d.).

- over-allocation—A resource allocation error that occurs when more work is assigned to a resource than can be completed within a particular time period, given that resource’s availability.

- over-commitment—A resource allocation error that occurs when a task takes longer than expected, tying up the resource longer than originally scheduled.

- proactive resilience—Taking timely action to prevent a crisis, often by introducing a change that upends the usual way of doing things at an organization (Laufer, et al. 2018, 56).

- resource allocation—The “process of assigning and managing assets in a manner that supports an organization’s strategic goals” (Rouse n.d.). On the project level, resource allocation still involves making choices that support the organization’s strategic goals, but you also have to factor in your project’s more specific goals.

- resource capacity management—The practice of “planning your workforce and building a skill inventory in exact proportion to the demand you foresee. It lets you optimize productivity and as a concept perfectly complements the Agile methodology” (Gupta 2017).

- resource leveling— An approach to project scheduling that aims to avoid over-allocation of resources by setting start and end dates according to the “availability of internal and external resources” (ITtoolkit n.d.).

- resource management—See resource allocation.

- resource parsimony—“Deploying the fewest resources necessary to achieve the desired results” (Gibbert, Hoegl and Välikangas 2007).

- resource smoothing—“A scheduling calculation that involves utilizing float or increasing or decreasing the resources required for specific activities, such that any peaks and troughs of resource usage are smoothed out. This does not affect the overall duration” (Association for Project Management n.d.).

- triple bottom line (TBL)— Term introduced by John Elkington as a way to broaden corporate thinking about the cost of doing business to include social and environmental responsibilities. He argued that rather than focusing solely on profit and loss, organizations should pay attention to three separate bottom lines: profit, people, and the planet. “It aims to measure the financial, social and environmental performance of the corporation over a period of time. Only a company that produces a TBL is taking account of the full cost involved in doing business” (The Economist 2009).

- variable resource—A resource that changes “in tandem with output” (Reference n.d.).

~References

Association for Project Management. n.d. “Difference Between “Resource Smoothing” and “Resource Leveling”.” apm.org. Accessed July 15, 2018. https://www.apm.org.uk/content/resource-smoothing.

Business Dictionary. n.d. “Resource Management.” Business Dictionary. Accessed July 15, 2018. http://www.businessdictionary.com/definition/resource-management.html.

Fitzgerald, Donna. 2003. “The Keys to Resource Allocation.” Tech Republic, April 21. http://www.techrepublic.com/article/the-keys-to-resource-allocation/.

Gibbert, Michael, Martin Hoegl, and Liisa Välikangas. 2007. “In Praise of Resource Constraints.” MIT Sloan Management Review (Spring). http://sloanreview.mit.edu/article/in-praise-of-resource-constraints/.

Goodrich, Belinda. 2018. “Critical Path vs Critical Chain.” PM Learning Solutions. PM Learning Solutions. https://www.pmlearningsolutions.com/blog/critical-path-versus-critical-chain-pmp-concept-17.

Gupta, Aakash. 2017. “Resource Capacity Planning For Agile Teams.” PM. September 19. https://project-management.com/resource-capacity-planning-for-agile-teams/.

Hagel III, John, John Seely Brown, and Lang Davison. 2009. “Managing Resources in an Uncertain World.” Harvard Business Review. https://hbr.org/2009/02/the-potential-of-pull.

ITtoolkit. n.d. “How to Use Resource Leveling for Project Planning and Scheduling.” IT Toolkit. Right Track Associates, Inc. Accessed July 15, 2018. https://www.ittoolkit.com/articles/resource-leveling.

Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects. New York: Palgrave Macmillan.

McConnell, Steve. 1996. Rapid Development: Taming Wild Software Schedules. Redmond, WA: Microsoft Press.

Merrill, Robert, interview by Ann Shaffer. 2017. Senior Business Analyst, University of Wisconsin-Madison (October 2).

MICA. 2014. “5 Ways Top Project Managers Allocate Their Resources.” ResourceGuru Blog. December 11. https://blog.resourceguruapp.com/5-ways-top-project-managers-allocate-their-resources/.

Nelson, John. 2017. “Strategies for Ensuring Critical Resouces are Available When Needed.” Lecture for EPD612: Technical Project Management, University of Wisconsin-Madison,. November 8.

Reference. n.d. “What is a fixed resource and a variable resource?” Reference.com. IAC Publishing, LLC. Accessed July 15, 2018. https://www.reference.com/world-view/fixed-resource-variable-resource-697cdbe590688ff.

Rouse, Margaret. n.d. “Definition: resource allocation.” TechTarget. Accessed July 15, 2018. http://searchcio.techtarget.com/definition/resource-allocation.

Saunders, Gareth. 2015. “The challenges of resource management in our Agile team.” Digital Communciations. November 9. http://digitalcommunications.wp.st-andrews.ac.uk/2015/11/09/the-challenges-of-resource-management-in-our-agile-team/.

Sharpe, Paul, and Tom Keelin. 1998. “How SmithKline Beecham Makes Better Resource-Allocation Decisions.” Harvard Business Review. https://hbr.org/1998/03/how-smithkline-beecham-makes-better-resource-allocation-decisions.

The Economist. 2009. “Triple bottom line.” The Economist, November 17. https://www.economist.com/node/14301663.

11

Project Monitoring, Analytics, and Control

Information is a source of learning. But unless it is organized, processed, and available to the right people in a format for decision making, it is a burden not a benefit.

—William Pollard

Learning Objectives

After reading this lesson, you will be able to

- Explain the importance of designing good monitoring practices

- Describe elements of effective project monitoring and controlling

- Understand how to decide what to monitor and when, and list some useful items to monitor

- Distill monitoring information into reports that are useful to different stakeholders

- Describe features of a good project dashboard

- Compare pure, instinctual intuition to informed intuition

- Explain how linearity bias can mislead assessment of project progress

The Big Ideas in this Lesson

- As a project manager, you have to balance looking through the front window to see where the project is headed with well-timed glances at the dashboard, while occasionally checking your rearview mirror to see if you might have missed something important.

- Different types of projects require different approaches to monitoring, analytics, and control. But any technique is only useful if it enables you to learn and respond. An excessive focus on measurement, without any attempt to learn from the measurements, is not useful.

- When reporting on the health of their projects, successful project managers tailor the amount of detail, the perspective, and the format of information to the specific stakeholders who will be consuming it.

- Gut instinct, or pure intuition, can make you vulnerable to the errors caused by cognitive biases. Instead, aspire to informed intuition, a combination of information and instinctive understanding acquired through learning and experience.

11.1 Monitoring for Active Control

Cannon Balls Versus Guided Missiles

Launching a project with no expectation of having to make changes to the plan as it unfolds is like firing a cannonball. Before you do, you make ballistic calculations, using assumptions about cross winds and other conditions. After the cannonball leaves the cannon, you can monitor its progress, but not control for changes. The cannonball might hit its target if your assumptions are correct and the target doesn’t move. But if any of your assumptions turn out to be incorrect, you will miss your target.

In contrast, you can correct the course of a guided missile during flight to account for changing conditions, such as a gust of wind or a moving target. A guided missile requires sophisticated monitoring and control capabilities, but is more likely to hit the target, especially under dynamic conditions.

Successful project managers take the guided missile approach, correcting course as a project unfolds to account for the unexpected.

The best project managers succeed through an artful combination of leadership and teamwork, focusing on people, and using their emotional intelligence to keep everyone on task and moving forward. But successful project managers also know how to gather data on the health of their projects, analyze that data, and then, based on that analysis, make adjustments to keep their projects on track. In other words, they practice project monitoring, analytics, and control.

Note that most project management publications emphasize the term monitoring and control to refer to this important phase of project management, with no mention of the analysis that allows a project manager to use monitoring data to make decisions. But of course, there’s no point in collecting data on a project unless you plan to analyze it for trends that tell you about the current state of the project. For simple, brief projects, that analysis can be a simple matter—you’re clearly on schedule, you’re clearly under budget—but for complex projects you’ll need to take advantage of finely calibrated data analytics tools. In this lesson, we’ll focus on tasks related to monitoring and control, and also investigate the kind of thinking required to properly analyze and act on monitoring data.

Generally speaking, project monitoring and control involves reconciling “projected performance stated in your planning documentation with your team’s actual performance” and making changes where necessary to get your project back on track (Peterman 2016). It occurs simultaneously with project execution, because the whole point of monitoring and controlling is making changes as team members perform their tasks. The monitoring part of the equation consists of collecting progress data and sharing it with the people who need to see it in a way that allows them to understand and respond to it. The controlling part consists of making changes in response to that data to avoid missing major milestones. If done right, monitoring and controlling enables project managers to translate information gleaned by monitoring into the action required to control the project’s outcome. A good monitoring and control system is like a neural network that sends signals from the senses to the brain about what’s going on in the world. The same neural network allows the brain to send signals to the muscles, allowing the body to respond to changing conditions.

Because monitoring and controlling is inextricably tied to accountability, government web sites are a good source of suggestions for best practices. According to the state of California, monitoring and controlling involves overseeing

all the tasks and metrics necessary to ensure that the approved and authorized project is within scope, on time, and on budget so that the project proceeds with minimal risk. This process involves comparing actual performance with planned performance and taking corrective action to yield the desired outcome when significant differences exist. The monitoring and controlling process is continuously performed throughout the life of the project. (California Office of Systems Integration n.d.)

In other words, monitoring is about collecting data. Controlling is about analyzing that data and making decisions about corrective action. Taken as a whole, monitoring and controlling is about gathering intelligence and using it in an effective manner to make changes as necessary. Precise data are worthless unless they are analyzed intelligently and used to improve project execution. At the same time, project execution uninformed by the latest data on changing currents in the project can lead to disaster.

Earned Value Management (EVM) is an effective method of measuring past project performance and predicting future performance by calculating variances between the planned value of a project at a particular point and the actual value. If you aren’t familiar with EVM, you should take some time to learn about it. The blog post provides a helpful summary:  https://www.projectsmart.co.uk/earned-value-management-explained.php.

The geometric order approach to monitoring and controlling focuses on gathering data about the past, and then using that information to estimate the future. This approach can be very helpful in some situations, but it is most effective when combined with a living order monitoring and controlling system, which does the following:

- Looks at today and the immediate future.

- Uses reliable promising to ensure that stakeholders commit to what needs to happen next.

- Focuses on the project’s target value, modifying the path ahead as necessary to achieve the agreed-on target value.

- Assumes a collaborative approach, in which stakeholders work together to decide how to adjust the project to deliver it at the target value.

A living order monitoring and controlling system provides team members with the information they need to make changes in time to affect the project’s outcome. Such a system is forward-facing, looking toward the future, always scanning for potential hazards, making it an essential component of any risk management strategy. While it is essential to hold team members accountable for their performance, a monitoring and controlling system should focus on the past only in so far as understanding the past makes it possible to forecast the future and adjust course as necessary. Ideally, it should allow for rapid processing of information, which can in turn enable quick adjustments to the project plan. In other words, the best monitoring and controlling system encourages active control.

Active control takes a two-pronged approach:

- Controlling what you can by making sure you understand what’s important, taking meaningful measurements, and building an effective team focused on project success.

- Adapting to what you can’t control through early detection and proactive intervention.

The first step in active control is ensuring that the monitoring information is distributed in the proper form and to the right people so that they can respond as necessary. In this way, you need to function as the project’s nervous system, sending the right signals to the project’s muscles (activity managers, senior managers, clients, and other stakeholders), so they can take action. These actions can take the form of minor adjustments to day-to-day tasks, or of major adjustments, such as changes to project resources, budget, schedule, or scope.

Notes from an Expert: Gary Whited

Gary Whited, an engineer with 35 years of experience providing technical oversight of engineering projects for the Wisconsin Department of Transportation, and currently the program manager at the University of Wisconsin-Madison’s Construction and Materials Support Center, has thought a lot about project management throughout his career. The following, which is adapted from a lecture of his in 2014, summarizes his ideas on the four main steps involved in monitoring and control:

1. Measuring and tracking progress: This is the major step, one that requires a significant investment of time. Everything that follows depends on gathering accurate data.

2. Identifying areas where changes are required: This is where we put the information we’ve gathered into the context in which it is needed.

3. Initiating the needed changes: Here we take action, making any necessary changes in response to the monitoring data.

4. Closing the loop: In this step, we go back and evaluate any changes to verify that they had the intended effect, and to check for any unintended consequences. For example, if you made a change to one component (say the schedule), you need to ask what effect that change might have had on other components (such as the budget).

These four steps look deceptively simple. But they add real complexity to any project. This is especially true of the last three steps, which involve things like change management and document control. Everyone takes measurements at the end of a project, but that’s not all that helpful, except to serve as lessons learned for future projects. By contrast, a well-implemented monitoring and control process gives stakeholders the power to make essential changes as a project unfolds (Whited 2014).

11.2 What to Monitor and When to Do It

When setting up monitoring and controlling systems for a new project, it’s essential to keep in mind that not all projects are the same. What works for one project might not work for another, even if both projects seem similar. Also, the amount of monitoring and controlling required might vary with your personal experience. If you’ve never worked on a particular type of project before, the work involved in setting up a reliable monitoring and controlling system will typically be much greater than the up-front work required for a project that you’ve done many times before. For projects you repeat regularly, you’ll typically have standard processes in place that will make it easy for you to keep an eye on the project’s overall performance.

Learning-Based Project Reviews

Sometimes upper management owns the schedule of the project and requires ongoing assessment and monitoring in the form of project reviews, which typically have members of a board “sitting at a horseshoe-shaped table” while “a team member stands in front of them and launches a presentation.” The problem with such reviews is two-fold: 1) they can be somewhat severe and punitive, and 2) they can tear team members away from working on the project itself.

In their book Becoming a Project Leader, Laufer et al. describe a learning-based project review, which makes reviews about troubleshooting problems rather than assessing performance. Laufer et al. describe the experience of Marty Davis, a project manager at NASA’s Goddard Space Flight Center, who “developed a review process that provided feedback from independent, supportive experts and encouraged joint problem solving”:

The first thing Marty Davis did was to unilaterally specify the composition of the review panel to fit the unique needs of his project, making sure that the panel members agreed with his concept of an effective review process. The second thing he did was change the structure of the sessions, devoting the first day to his team’s presentations and the second day to one-on-one, in-depth discussions between the panel and the team members to come up with possible solutions to the problems identified on the first day. This modified process enabled Marty Davis to create a working climate based on trust and respect, in which his team members could safely share their doubts and concerns. The independent experts identified areas of concern, many of which, after one-on-one meetings with the specialized project staff and the review team’s technical specialists, were resolved. The issues that remained open were assigned a Request for Action (RFA). Eventually, Marty Davis was left with just five RFAs.

This kind of approach to project reviews ensured a supportive, failure-tolerant environment, and with its emphasis on continuous learning, had long-term benefits for each team member.

Exactly which items you need to monitor will vary from project to project, and from one industry to another. But in any industry, you usually only need to monitor a handful of metrics. There’s no need to over-complicate things. For example, when managing major construction projects for the Wisconsin Department of Transportation, Gary Whited, focused on these major items:

- Schedule

- Cost/budget

- Issues specific to the project

- Risk

He also recommends monitoring the following:

- Quality

- Safety

- Production rates

- Quantities (Whited 2014)

In other kinds of projects, you will probably need to monitor different issues. But it’s always a good idea to focus on information that can serve as early warnings, allowing you to change course if necessary. This typically includes the following:

- Current status of schedule and budget

- Expected cost to complete

- Expected date(s) of completion

- Current/expected problems, impacts, and urgency

- Causes for schedule/cost overruns

As Whited explains, the bottom line is this: “If it’s important to the success of your project, you should be monitoring it” (2014).

Note that measuring the percent complete on individual tasks is useful in some industries, where tasks play out over a long period of time. But according to Dave Pagenkopf, in the IT world the percent complete of individual tasks is meaningless: “The task is either complete or not complete. At the project level, percent complete may mean something. You really do need to know which tasks/features are 100% complete. But sloppy progress reports can generate confusion on this point. 100% of the functions in a software product 80% complete is not the same as having 80% of the features 100% complete. A poorly designed progress report can make these can look the same, when they most definitely are not” (pers. comm., November 13, 2017).

In addition to deciding what to monitor, you need to decide how often to take a particular measurement. As a general rule, you should measure as often as you need to make meaningful course corrections. For some items, you’ll need to monitor continuously; for others, a regular check-in is appropriate. Most projects include major milestones or phases that serve as a prime opportunity for monitoring important indicators. As Gary Whited notes, “The most important thing is to monitor your project while there is still time to react. That’s the reason for taking measurements in the first place” (2014).

11.3 Avoiding Information Overload

As Chad Wellmon explains in his interesting essay, “Why Google Isn’t Making Us Stupid…or Smart,” the history of human civilization is the history of people trying to make sense of too much information (2012). As far back as biblical times, the writer of Ecclesiastes complained, “Of making books there is no end” (12:12). In the modern business world, we could update that famous quotation to read, “Of writing reports and sending emails there is no end.” Indeed, according to an article by Paul Hemp in the Harvard Business Review , many researchers argue that information overload is one of the chief problems facing today’s organizations, resulting in stressed out, demoralized workers who lose the ability to focus efficiently and think clearly because their attention is constantly being redirected; lost productivity and reduced creativity due to constant interruptions; and delayed decision-making caused by people sharing information and then waiting for a reply before they can decide how to proceed. According to Hemp, one study that focused on unnecessary email at Intel set the cost of “information interruptions” at “nearly $1 billion” (Hemp 2009).

So if you feel like you are drowning in a sea of information, you’re not alone. But as a project manager, you have the ability to shape all that data into something useful, whether by creating electronic, at-a-glance dashboards that collate vital statistics about a project, or by creating reports that contain only the information your audience needs. By doing so, according to Wellmon, you’ll be engaging in one of humanity’s great achievements—using technology to filter vast amounts of information, leaving only what we really need to know. As Wellmon puts it: “Knowledge is hard won; it is crafted, created, and organized by humans and their technologies.”

When reporting on the health of their projects, successful project managers tailor the amount of detail, the perspective, and the format of information to the specific stakeholders who will be consuming it. Talking to your company’s CEO about your project is one thing. Talking to a group of suppliers and vendors is another. You need to assesss the needs of your audience and provide only the information that is useful or appropriate to them. For example, in a report to upper management on a software development project, you might include data reporting costs to date, projected cost at completion, schedule status, and any unresolved problems. The report is unlikely to include details regarding programming issues unless a supervising manager has the technical ability and interest to be involved in such details. Dashboards for the coding team, however, would need to highlight progress on key unresolved coding issues and planned follow-up actions.

Brian Price, the former chief power train engineer for Harley-Davidson, and an adjunct professor in the UW Master of Engineering in Engine Systems program, says it’s helpful to think in terms of providing layers of information to stakeholders. At the very top layer is the customer, who typically only needs to see data on basic issues, such as cost and schedule. The next layer down targets senior management, who mostly need to see dashboards with key indicators for all the projects in a portfolio. Meanwhile, at the lowest layer, the core project team needs the most detailed information in the form of progress reports on individual tasks. This approach keeps people from being overwhelmed with information they don’t really need. At the same time, it does not preclude any stakeholder from seeing the most detailed information, especially if it’s available through a virtual project portal (pers. comm., August 17, 2016).

The decisions you make about what monitoring and controlling information to share with a particular audience are similar to the decisions you make about sharing schedules. In both cases, you need to keep in mind that your stakeholders’ attention is valuable. To put it in Lean terminology, attention is a wasteable resource (Huber and Reiser 2003). You don’t want to waste it by forcing stakeholders to wade through unnecessary data. Remember that the goal of monitoring and controlling information is to prompt stakeholders to respond to potential problems. In other words, you want to make it easy for stakeholders to translate the information you provide into action.

11.4 A Note About Dashboards

A well-designed dashboard can be extremely useful, greatly minimizing the time required to put reports together. If the data is live—that is, updated continually—stakeholders can get updates instantaneously, instead of waiting for monthly project review meetings. Even a dashboard that is merely updated daily, or even weekly, can prevent the waste and delays that arise when people are working with outdated information.

In his book Project Management Metrics, KPIs, and Dashboards: A Guide to Measuring and Monitoring Project Performance, Harold Kerzner discusses the importance of presenting monitoring information in a way that allows stakeholders to make timely decisions:

The ultimate purpose of metrics and dashboards is not to provide more information but to provide the right information to the right person at the right time, using the correct media and in a cost-effective manner…. Today, everyone seems concerned about information overload. Unfortunately, the real issue is non-information overload. In other words, there are too many useless reports that cannot easily be read and that provide readers with too much information, much of which may have no relevance. It simply distracts us from the real issues…. Insufficient or ineffective metrics prevent us from understanding what decisions really need to be made. (2013, vii)

A well-designed dashboard is an excellent tool for presenting just the right amount of information about project performance. The key to effective dashboards is identifying which dashboard elements are most helpful to your particular audience. Start by thinking about what those people need to focus on. For a given project, the same dashboard might not work for all groups. The dashboard you use to report to high-level managers might not be useful for people actually working on the project. Generally speaking, a dashboard should include only the information the intended audience needs to keep the project on track. A dashboard also helps senior managers evaluate different projects in their portfolio. They can quickly assess what’s working, what’s not working, and where they might provide assistance.

In a two-part series for BrightPoint Consulting, a firm that specializes in data visualization, Tom Gonzalez explains how to create effective dashboards by focusing on key performance indicators (KPI), which are metrics associated with specific targets (Gonzalez). You can download his series on dashboards here: http://www.brightpointinc.com/data-visualization-articles/. To learn more about KPIs, see this extremely helpful white paper, also by Tom Gonzalez: http://www.brightpointinc.com/download/key-performace-indicators/.

Figure 11-1 provides an example of an effective dashboard. It is simple, and easy to read, and focuses on a few KPIs.

Figure 11-1: A simple, easy-to-read dashboard

For a dashboard to be really useful, it’s essential that all stakeholders share the same definitions of common metrics such as “high,” “medium,” and “low.” Likewise, everyone has to understand the specific meaning of the colors used in any color coded system.

To learn more about designing effective dashboards, see Chapter 6 of Kerzner’s book. For some tips on best practices for dashboards, take a look at this web site: https://www.targetdashboard.com/site/kpi-dashboard-best-practice/default.aspx#KPI-Dashboard-Design.

Of course a dashboard is only one part of a monitoring system. It allows you to see what’s going on in the present. As a project manager, you have to balance looking at the dashboard with looking through the front window to see where the project is headed, while occasionally checking your rearview mirror to see if you might have missed something important.

Beyond the Status Report

According to Dave Pagenkopf, Applications Development and Integration Director for DoIT at the UW-Madison, one effective form of monitoring in IT projects is asking team members to demonstrate their work:

For software projects where I am the sponsor or a key decision maker, I ask for product demonstrations before going through status reports. Demonstration of working software or the lack thereof tells me more about progress than any status report could. I have been known to take a quick tour of a data center when a team says they have finished installing servers. I have a large monitor in my office, so people can show me working software during meetings. As a general rule, in IT, the best performers always want to show what they have done. The poor performers want to talk about what they have done.

Another form of monitoring IT projects is simply taking a close look at the programmers. During marathon projects, when everyone is working nonstop, I look for signs of unspoken exhaustion that will inevitably lead to problems. Those usually show up first as changes in grooming habits, which I notice as I walk through the office. (pers. comm. November 22, 2017)

That last suggestion is an example of managing by walking around (MBWA)—a management style that emphasizes unplanned encounters with team members, and spontaneous, informal reviews of equipment and ongoing work. Sometimes a two-minute conversation with a team member will tell you more about the health of a project than piles of status reports. MBWA was first popularized in the 1980’s by Tom Peters and Robert H. Waterman in their book In Search of Excellence. You can read more about MBWA here: https://www.cleverism.com/management-by-walking-around-mbwa/.

11.5 Informed Intuition

At some point in your career, you’ll find your intuition telling you one thing, while the monitoring data you have so laboriously collected tells you something else. For example, a recently updated schedule and a newly calculated budget-to-completion total might tell you a project is humming along as expected and that everything will finish on time and under budget. But still, you get a feeling that something is amiss. Maybe a customer’s tone of voice suggests unhappiness with the scope of the project. Or perhaps a product designer’s third sick day in a week makes you think she’s about to take a job with a different company, leaving you high and dry. Or maybe the sight of unopened light fixtures stacked in a corner at a building site makes you wonder if the electricians really are working as fast as status reports indicate.

Monitoring Quality, Including Compliance

When it comes to monitoring and control, project managers tend to focus on budget and schedule. But it’s also essential to monitor quality. For example, does the concrete used in a building project match the required standards? In an IT project, is the software free of bugs? Sometimes monitoring quality involves ensuring regulatory compliance, including meeting standards on how you conduct your project.

Major corporations spend many millions of dollars each year on compliance programs designed to ensure that they follow the law, including the host of government regulations that apply to a typical organization. The ultimate goal of any compliance program is to prevent employees from breaking the law and, ideally, to encourage ethical behavior.

At times like these, you might be tempted to take action based solely on gut instinct. But as discussed in Lesson 2, that kind of unexamined decision-making leaves you vulnerable to the errors in thinking known as cognitive biases. For instance, suppose you’ve been working with Vendor A for several months, always with good results. Then, at a conference, you hear about Vendor B, a company many of your colleagues seem to like. You might think you’re following a simple gut instinct when you suddenly decide to switch from a Vendor A to Vendor B, when in fact your decision is driven by the groupthink cognitive bias, which causes people to adopt a belief because a significant number of other people already hold that belief.

In an article for the Harvard Business Review, Eric Bonabeau discusses the dangers of relying on pure intuition, or gut instincts:

Intuition has its place in decision making—you should not ignore your instincts any more than you should ignore your conscience—but anyone who thinks that intuition is a substitute for reason is indulging in a risky delusion. Detached from rigorous analysis, intuition is a fickle and undependable guide—it is as likely to lead to disaster as to success. And while some have argued that intuition becomes more valuable in highly complex and changeable environments, the opposite is actually true. The more options you have to evaluate, the more data you have to weigh, and the more unprecedented the challenges you face, the less you should rely on instinct and the more on reason and analysis. (Bonabeau 2003)

As Bonabeau suggests, you don’t want to detach intuition from analysis. Instead, you want your intuition to spur you on to seek more and better information, so you can find out what’s really going on. You can then make a decision based on informed intuition—a combination of information and instinctive understanding. You develop it through experience and by constantly learning about your individual projects, your teammates, your organization, and your industry. It can allow you to spot trouble before less experienced and less informed colleagues.

According to cognitive psychologist Gary Klein, this kind of instinctive understanding is really a matter of using past experience to determine if a particular situation is similar to or different from past situations. This analysis occurs so fast it seems to exist outside of rational thought, but is in fact supremely rational. By studying firefighters in do-or-die situations, Klein developed a new understanding of this form of thought:

Over time, as firefighters accumulate a storehouse of experiences, they subconsciously categorize fires according to how they should react to them. They create one mental catalog for fires that call for a search and rescue and another one for fires that require an interior attack. Then they race through their memories in a hyperdrive search to find a prototypical fire that resembles the fire that they are confronting. As soon as they recognize the right match, they swing into action. Thought of this way, intuition is really a matter of learning how to see—of looking for cues or patterns that ultimately show you what to do. (Breen 2000)

Klein doesn’t use the term informed intuition, but that’s what he’s talking about. Informed intuition is a matter of learning how to see, so you can analyze a situation in an instant and take the necessary action. That’s definitely something to aspire to as you proceed through your project management career.

11.6 The Illusion of Linearity

The best monitoring data in the world is useless if you lack the ability to interpret it correctly. One of the most common interpretation errors is assuming the relationship between two things is linear when it is in fact nonlinear. Numerous studies in cognitive psychology have shown that humans have a hard time grasping nonlinear systems, where the relationship between cause and effect is uncertain. A cognitive bias in favor of linearity makes us naturally predisposed to perceive simple, direct relationships between things, when in reality more complex forces are at play.

Bart de Langhe, Stefano Puntoni, and Richard Larrick explain the perils of linear thinking in a nonlinear world in this classic article for the Harvard Business Review: https://hbr.org/2017/05/linear-thinking-in-a-nonlinear-world.

For example, marketing forecasts often assume a linear relationship between consumer attitudes and behavior, when in fact things are much more complicated. One study focused on the relationship between consumers’ stated preference for organic products and the same consumers’ actual behavior. You might think that someone with a strong preference for organic products would buy more organic vegetables than someone with a less strong preference for organic products. You might be surprised to learn that this is not the case, because the relationship between consumer attitudes and behavior is nonlinear (van Doorn, Verhoef and Bijmolt 2007).

Project managers fall prey to the linearity bias frequently, especially when it comes to the relationship between time and the many elements of a project. Because time is shown on the x-axis in Microsoft Project, we make the mistake of thinking that individual tasks will be completed in one linear stream of accomplishment. In reality, however, the relationship graph may take the form of a curve or a step function. Failure to grasp this means that any attempts to monitor and control a project are founded on incorrect assumptions, and therefore doomed to failure.

In addition to muddying your understanding of cause and effect, the linearity bias can cause you to confuse activity with accomplishment. But just because people are bustling around the office does not mean they are actually getting anything done. Think of the kind of unfocused activity that often occurs as you’re getting ready to move from one home to the next. You might spend some time sorting kitchen utensils until you get distracted by alphabetizing your CD collection before you pack it away in boxes. Then, suddenly, the movers show up, and you kick into gear. In one hour, you might accomplish more than in the previous three days. A graph of your accomplishments during the move might look like the step function shown in Figure 11-2, with very little of importance actually being accomplished, followed by a great deal being accomplished.

Figure 11-2: Productivity often takes the form of a step function; here, the process of packing up to move begins with very little being accomplished, followed by the movers showing up, at which point a great deal is accomplished

As a project manager, you need to make your monitoring measures factor in the nonlinearity of resource use. Resource expenditures are often low at first. As a result, an inexperienced project manager might be lulled into thinking she is working with a linear system, in which resource expenditures will continue at the same rate throughout the project. In most projects, however, most of the resources are used up near the end of the project. Suddenly, the slope of the graph illustrating resource use over time takes a vertical turn, as in Figure 11-3.

Figure 11-3: Resource consumption can seem linear and then change dramatically; here, resources are consumed at a linear rate of 1% per week through week 10, followed by a sudden uptick in weeks 10-13

Note that the step function model of productivity applies to most Agile projects. Productivity is zero until the team can demonstrate that they have created a working feature, at which point the productivity graph takes a step up. Ideally, each sprint causes another step up, but if the client is not satisfied with the outcome of a particular sprint, productivity stays flat until the end of the next sprint.

~Practical Tips

Here are a few practical tips related to monitoring and controlling:

- Keep your audience in mind: When presenting monitoring information to stakeholders, always keep the audience in mind. When you are communicating with executives, a high-level summary is most useful. When communicating with the people who are actually implementing the project, more detail will be required.

- Make sure stakeholders can deal with bad news: A monitoring system is only useful if team members are willing and able to respond to the news it provides about project performance, especially when it suggests the existence of serious problems. Make sure everyone on the project team is willing to identify bad news and deal with it as early as possible.

- Look at the bigger picture: Vital monitoring information sometimes comes from beyond the immediate project. Weather, personnel issues, and the economy can all affect what you hope to accomplish. Take care not to get so focused on the details of incoming monitoring information that you miss the big bigger picture. If that’s not your strong suit, remember to check in with team members who are good at seeing the big picture. Understanding what’s happening in the regional, national, and global economy, for instance, might help you manage your project.

- Simplify: A few key metrics are better than too many metrics, which may be confusing and contradictory.

- Pay attention to non-quantitative measures: Client satisfaction, changes in market preferences, public perceptions about the project, the physical state of team members (Do they appear rested and groomed as usual?), and other non-quantitative measures can tell you a lot about the health of your project and are worth monitoring.

- Be alert for bias in data collection: Make sure your monitoring systems give you an objective picture of the current state of your project.

- Be mindful of the effect of contracts on monitoring and controlling efforts: The type of contract governing a project can affect the amount and type of monitoring and controlling employed throughout a project. In a time and material contract, where you get paid for what you do, a contractor will carefully monitor effort because that is the basis of payment. They might not be motivated to control effort because the more they use, the more they are paid. With a lump sum contract, the contractor will be highly motivated to monitor and control effort because compensation is fixed and profit depends largely on effective control.

- Be sure to communicate key accomplishments, next steps, and risk items: When reading monitoring reports, managers are often looking for just enough information about the project to allow them to feel connected and to allow them to report to the next level up in management. You can make this easier for them by including in your reports a list of deliverables from the last thirty days, a list of what’s expected in the next thirty days, and risks they need to be mindful of.

Finally, here are additional helpful suggestions from Gary Whited (2014):

- Collect actionable information: Focus monitoring efforts on information that is actionable. That is, the information you collect should allow you to make changes and stay on schedule/budget.

- Keep it simple: Don’t set up monitoring and controlling systems that are so complicated you can’t zero in on what’s important. Simplicity is better. Focus on measures that are key to project performance.

- Collect valuable data, not easy-to-collect data: Don’t fall into the trap of focusing on data that is easy to collect, rather than on data that is tied to an actual benefit or value.

- Avoid unhelpful measures: Avoid measures that have unnecessary precision, that draw on unreliable information, or that cause excessive work without a corresponding benefit.

- Focus on changeable data: Take care not to over-emphasize measures that have little probability of changing between periods.

~Summary

- Project monitoring and controlling, which occurs simultaneously with execution, involves reconciling “projected performance stated in your planning documentation with your team’s actual performance” and making changes where necessary to get your project back on track (Peterman 2016). The best monitoring and controlling system encourages active control, which involves: 1) controlling what you can by making sure you understand what’s important, taking meaningful measurements, and building an effective team focused on project success; and 2) adapting to what you can’t control through early detection and proactive intervention.

- The type of monitoring that works for one project might not work for another, even if if both projects seem similar. Exactly which items you need to monitor will vary from project to project, and from one industry to another. But in any industry, you usually only need to monitor a handful of metrics. As a general rule, you should measure as often as you need to make meaningful course corrections.

- You can prevent information overload by shaping monitoring data into electronic, at-a-glance dashboards that collate vital statistics about a project, and reports that contain only the information your audience needs. Always tailor the amount of detail, the perspective, and the format of information in a report to the specific stakeholders who will be consuming it.

- A well-designed dashboard is an excellent tool for presenting just the right amount of information about project performance. The key to effective dashboards is identifying which dashboard elements are most helpful to your particular audience.

- Gut instinct, or pure intuition, can make you vulnerable to the errors caused by cognitive biases. You’ll get better results by linking intuition to analysis and learning. The result, informed intuition, is a combination of information and instinctive understanding acquired through learning and experience.

- The linearity bias—a cognitive bias that causes people to perceive direct linear relationships between things that actually have more complex connections—can make it hard to interpret monitoring data correctly.

- Compliance programs—which focus on ensuring that organizations and their employees adhere to government regulations, follow all other laws, and behave ethically—require the same kind of careful monitoring and controlling as any organizational endeavor.

~Glossary

active control—A focused form of project control that involves the following: 1) controlling what you can by making sure you understand what’s important, taking meaningful measurements, and building an effective team focused on project success; and 2) adapting to what you can’t control through early detection and proactive intervention.

compliance program—A formalized program designed to ensure that an organization and its employees adhere to government regulations, follow all other laws, and behave ethically.

controlling—In the monitoring and controlling phase of project management, the process of making changes in response to data generated by monitoring tools and methods to avoid missing major milestones.

earned value management (EVM)—An effective method of measuring past project performance and predicting future performance by calculating variances between the planned value of a project at a particular point and the actual value.

informed intuition—A combination of information and instinctive understanding. You develop informed intuition through experience and by constantly learning about your individual projects, your teammates, your organization, and your industry.

key performance indicator (KPI)—A metric associated with a specific target (Gonzalez).

linearity bias—A cognitive bias that causes people to perceive direct, linear relationships between things that actually have more complex connections.

managing by walking around—A management style that emphasizes unplanned encounters with team members, and spontaneous, informal reviews of equipment and ongoing work.

monitoring—In the monitoring and controlling phase of project management, the process of collecting progress data and sharing it with the people who need to see it in a way that allows them to understand and respond to it.

monitoring and controlling—The process of reconciling “projected performance stated in your planning documentation with your team’s actual performance” and making changes where necessary to get your project back on track (Peterman 2016). Monitoring and controlling occurs simultaneously with execution.

~References

Bonabeau, Eric. 2003. “Don’t Trust Your Gut.” Harvard Business Review, May. https://hbr.org/2003/05/dont-trust-your-gut.

Breen, Bill. 2000. “What’s Your Intuition?” Fast Company. August 31. https://www.fastcompany.com/40456/whats-your-intuition.

California Office of Systems Integration. n.d. “Best Practices: Monitoring & Control.” OSI Best Practices. Accessed June 1, 2018. http://www.bestpractices.ca.gov/project_management/monitoring.shtml.

Gonzalez, Tom. n.d. “Dashboard Design: Key Performance Indicators and Metrics.” BrightPointInc.com. Accessed June 1, 2018. http://www.brightpointinc.com/download/key-performace-indicators/.

Hemp, Paul. 2009. “Death by Information Overload.” Harvard Business Review, September. https://hbr.org/2009/09/death-by-information-overload.

Huber, Bob, and Paul Reiser. 2003. “The Marriage of CPM and Lean Construction.”

Kerzner, Harold. 2013. Project Management Metrics, KPIs, and Dashboards: A Guide to Measuring and Monitoring Project Performance, Second Edition. Hoboken: Wiley.

Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects. New York: Palgrave Macmillan.

Peterman, Rebekah. 2016. “Project management Phases: Exploring Phase #4 — Monitoring & Control.” PM. September 12. https://project-management.com/project-management-phases-exploring-phase-4-monitoring-control/.

van Doorn, Jenny, Peter C. Verhoef, and Tammo H.A. Bijmolt. 2007. “The importance of non-linear relationships between attitude and behaviour in policy research.” Journal of Consumer Policy 30 (2): 75-90. https://link.springer.com/article/10.1007/s10603-007-9028-3.

Wellmon, Chad. 2012. “Why Google Isn’t Making Us Stupid…or Smart.” The Hedgehog Review: Critical Reflections on Contemporary Culture 14 (1 (Spring 2012)). http://www.iasc-culture.org/THR/THR_article_2012_Spring_Wellmon.php.

Whited, Gary. 2014. Monitoring and Control. Recorded lecture with PowerPoint Presentation. Madison, September.

12

Critical Project Management Skill: Negotiation

The first duty of a wise advocate is to convince his opponent that he understands their arguments.

—Samuel Taylor Coleridge

Objectives

After reading this lesson, you will be able to

- Explain the importance of negotiation in daily life and on the job

- Describe the advantages of principled negotiation, as described by Roger Fisher and William Ury in their book Getting to Yes

- Explain the role of emotions in negotiations and list some strategies for dealing with them

- Discuss cross-cultural issues related to negotiation

- Provide guidelines on evaluating the ethics of a negotiation

- Define terms related to dispute resolution

The  Big Ideas in this Lesson

- Whether you realize it or not, you engage in negotiations every day. Succeeding at any type of negotiation requires emotional intelligence, preparation, and a willingness to understand the needs of the party on the other side of the negotiating table.

- A negotiation can generate positive emotions, especially if you are able to see the negotiation as a chance to build a relationship, strive to have empathy for the other party, and avoid taking personal offense over the natural give and take of a negotiation.

- A living order negotiation ensures that the parties can continue to work together in the future, in an enduring relationship. By contrast, a geometric order approach to negotiation focuses on immediate results, with little regard to long-term relationships.

- To get the most out of a negotiation, learn all you can about the other parties, use your emotional intelligence to perceive unspoken issues, seek a resolution that works for everyone as much as possible, and avoid an “us versus them” outcome. Most importantly, don’t ever assume you will get everything you want.

12.1 Negotiation 101

The need for negotiation, or settling differences, is a fact of human life. On a typical morning you might negotiate how much longer your teenager gets to sleep, who gets to use the shower first, and whose turn it is to drive for carpool. Once you get to work, you’ll probably encounter even more opportunities for negotiation, some of which could have high-stakes outcomes for your projects, your organization, and your career. Your ability to handle even small-scale negotiations (say, who’s responsible for changing the printer’s toner cartridge) can have a surprisingly large effect on your team’s sense of cohesion and purpose. Some negotiations are informal—the toner cartridge, for instance—while others, such as negotiating with a union, are highly formal, governed by a slew of state and federal laws.

Negotiating Uncertainty

According to Robert Merrill, Senior Business Analyst at the UW-Madison and a longtime project management veteran, one of the most important parts of a negotiation is getting all parties to accept the unknowns of living order: “If we don’t have solid predictability on combinations of scope, timing, and cost, and we’re negotiating commitments about them, isn’t that essentially gambling? We’re saying ‘I’ll bet you $10 that my cards will be better than your cards!’ That’s only going to lead to frustrations and disputes later. How about coming to an agreement on where we’re each best able to accommodate uncertainty?” (pers. comm., June 19, 2018).

You can tell a lot about a person’s negotiation skills from their definition of the term. Short-sighted, ineffective negotiators view a negotiation as a means of getting what they want. Wiser, more practiced negotiators would be more likely to define negotiation as a discussion with the goal of reaching an agreement that is moderately satisfying to both parties. A negotiation is not a competition. There should be no losers. Nobody gets everything they want in a successful negotiation, but everybody gets something. Perhaps most importantly, a wisely conducted negotiation ensures that the parties can continue to work together in the future.

Since negotiation is such an integral part of human life, it is a well-studied art. There are many books on the topic, but they all come down to a few basic ideas: learn all you can about the other parties in the negotiation, use your emotional intelligence to perceive unspoken issues, seek a resolution that works for everyone as much as possible, and avoid an “us versus them” outcome. Most importantly, don’t ever assume that you will get everything you want in a negotiation. For people who tend to think in terms of absolutes, negotiating, which is all about compromise, can feel like foreign territory. The goal of any negotiation is finding a workable solution for all parties and not about one party beating the other.

Project managers must negotiate constantly, and not just when working out contractual arrangements with suppliers or subcontractors. This list summarizes some project management situations that call for good negotiation skills.

- Proposal: Developing a proposal for a project is a negotiated process. Iterations and adjustments are nearly always necessary, based on feedback and the response of the client to the proposal pitch. From the earliest project stages, stakeholders will be setting out their respective positions and negotiating necessary adjustments to accommodate each other’s objectives.

- Scope: In defining scope, tensions between stakeholders regarding what can be delivered are unavoidable. The project scope should reflect a viable delivery plan for the endeavor. It should be realistic, and, if you have already completed similar projects successfully and fully understand what you need to do, it can also be ambitious. Project deliverables for scope, timing, and cost set the expectations for the rest of the project, so it is essential to conduct negotiations regarding these items in a positive way that ensures all stakeholders remain committed to the overall success of the project.

- Dispute resolution: Inevitably, issues will arise during project execution that lead to disputes. These are often the result of poor communication or misunderstandings over the interpretation of deliverables. Resolving disputes is an exercise in negotiating corrective actions and in revising the remaining plan for the project. It is essential that these resolutions occur in a timely manner and to the satisfaction of all parties, to avoid the costs of delay and to avoid the issues becoming a distraction to the project’s primary objectives.

- Acquiring Resources: Projects often unfold in cross-matrix organizations, where resources are being pulled in many directions as the organization strives to utilize them at maximum efficiency. As a project manager, you need to negotiate with resource managers regarding the availability of resources, including quantity, quality, and timing.

- Priorities: Once resources are allocated to a project, the process of managing those resources involves continued negotiation on how and when work tasks are completed. From setting task priorities to ensure dependencies between activities are correctly executed, to working with team members on availability, the project manager is constantly adjusting the project plan to cope with the messy reality of projects in living order.

- Procurement and contracts: The contracts stage of any project typically includes formalized negotiations. When government organizations are involved, these negotiations may be regulated by law. Increasingly, internal relationships between resource and service providers within an enterprise are covered by provision of service contracts, which need to be negotiated like any other contract.

- Risk management: Every project is an exercise in risk management. The project manager is continually involved in negotiating risk trade-offs that might incur additional costs, delays, or changes to project scope. In some cases, the project manager might have to negotiate the transfer of risk between stakeholders. It is essential that these risk negotiations are transparent and consciously accepted by all affected parties.

- Closure: The formal sign-off on project delivery occurs at closeout. This process ensures that contractual deliverables have been formally acknowledged as being complete to the satisfaction of the client and all key stakeholders. At this point, stakeholders review the original scope and any agreed-upon deviations negotiated along the way, to verify that the completed project matches what everyone thought they agreed to. If the client is not satisfied, the termination stage may entail negotiating adjustments to the project and acceptance of final delivery status.

To be an effective negotiator, a project manager must be empowered with the necessary authority. It’s important to be able to make on-the-spot decisions with an understanding of the consequences, which should be worked out beforehand through scenario planning. All parties will be frustrated if a negotiator lacks the authority to negotiate and makes commitments that cannot be honored, or if the negotiator continually needs to seek approvals.

Taking the Middle Path

In his book The New Negotiating Edge: The Behavioral Approach for Results and Relationships, Gavin Kennedy advocates a middle path between hard-nosed, aggressive tactics (which he calls red behavior) and a completely rational, win-win style that seeks to satisfy all parties (blue behavior). This middle path—purple behavior—focuses on the two-way exchange necessary to successfully conclude any negotiation. Everyone has to give up something to get something. In a review of Kennedy’s book, Roger Trapp explains:

Kennedy saw the need for a different approach because the red style, by assuming that negotiation is all about manipulation, tends to harden attitudes, while the blue one is over-trusting of other people.

“The key to solving dilemmas of trust and risk,” he writes, “is not to alternate between non-trusting red and too-trusting blue, but to fuse them into purple conditional behavior.

“This fusion neatly expresses the essence of the negotiation exchange: give me some of what I want (my red results side) and I will give you some of what you want (my blue relationship side). Red is taking behavior, blue is giving behavior and purple is trading behavior, taking while giving.”

The strength of purple behavior, he argues, is that it is a two-way exchange rather than a one-way street and moreover deals with people as they are and not how you assume or want them to be. (1998)

12.2 Focus on Interests Instead of Positions

Resist the Lure of a Midpoint

A preferred method is to be open about what both parties value, and negotiate trade-offs in which each party gives up what they value least. It’s also helpful to be realistic from the start about acceptable figures rather than engaging in positional bargaining, in which each party is forced to give way, bit by bit, over a long period of time.

In their seminal 1981 book, Getting to Yes, Roger Fisher and William Ury describe the most common form of negotiation as the kind of haggling you might engage in when buying a used car. You might start by taking up a position at the low end—say, $4,000. Meanwhile, the car dealer takes up a position on the high end—say, $12,000. Then the two of you proceed to argue the invalidity of the other’s position (“$4,000 isn’t a serious offer!”), while altering your positions bit by bit, until finally you settle on an acceptable mid-point of $8,000. According to Fisher and Ury, this kind of negotiation, known as positional bargaining, forces people to take up positions and defend them:

In positional bargaining you try to improve the chance that any settlement reached is favorable to you by starting with an extreme position, by stubbornly holding to it, by deceiving the other party as to your true views, and by making small concessions only as necessary to keep the negotiation going. The same is true for the other side. Each of those factors tends to interfere with reaching a settlement promptly. The more extreme the opening positions and the smaller the concessions, the more time and effort it will take to discover whether or not agreement is possible. (2011)

The problem with this type of negotiation is that it creates a contest of wills that can permanently damage relationships:

Each negotiator asserts what he will and won’t do. The task of jointly devising an acceptable solution tends to become a battle. Each side tries through sheer willpower to force the other to change its position…. Anger and resentment often result as one side sees itself bending to the rigid will of the other while its own legitimate concerns go unaddressed. Positional bargaining thus strains and sometimes shatters the relationship between the parties. Commercial enterprises that have been doing business together for years may part company. Neighbors may stop speaking to each other. Bitter feelings generated by one such encounter may last a lifetime. (Fisher and Ury)

In as much as time is money, positional bargaining is also expensive because it increases the number of decisions a negotiator has to make, such as “what to offer, what to reject, and how much of a concession to make.” The difficulty involved in making so many decisions makes it easier for parties to delay making any decision at all:

Decision-making is difficult and time-consuming at best. Where each decision not only involves yielding to the other side but will likely produce pressure to yield further, a negotiator has little incentive to move quickly. Dragging one’s feet, threatening to walk out, stone walling, and other such tactics become commonplace. They all increase the time and costs of reach an agreement as well as the risk that no agreement will be reached at all. (Fisher and Ury)

Effective negotiators avoid positional bargaining at all costs. Rather than setting up a “me versus you” situation, negotiators should try what Fisher and Ury call principled negotiation, which is based on four essential points:

- People: Separate the people from the problem.

- Interests: Focus on interests, not positions.

- Options: Generate a variety of possibilities before deciding what to do.

- Criteria: Insist that the result be based on some objective standard. (Fisher and Ury)

The first point, separating the people from the problem, focuses on removing emotion from the negotiating process. The second point focuses on the fact that nothing revs up emotion like taking and defending a position. By abandoning positions and focusing on interests instead, the parties involved in the negotiation will begin to see themselves as collaborators, trying to solve a problem together. This in turn makes it easier to brainstorm a list of possibilities, which you can then evaluate based on objective standards agreed to by all parties.

It’s also helpful to think in terms of what negotiating parties value. If the other party values something highly and you don’t, that is the perfect thing to trade for something else that is valuable to you and not so much to the other side. This constructive approach helps prevent the kind of roadblocks that arise when you assume that giving anything away, even if you didn’t value it, is a loss. Being open about what you value at the start of a negotiation can save a lot of time, helping you achieve a meaningful trade more quickly. Some might argue that you don’t want to “show your cards” too soon, but in a principled negotiation, in which all parties are focused on achieving the best possible outcome instead of simply beating the other party, putting all our cards on the table works very well.

12.3 Information-Based Bargaining

Principled negotiation, as described by Fisher and Ury, is in part an exercise in learning about your negotiating partner. But you also have to be clear about your own motivations and your personal bargaining style. The more you know about yourself and your negotiating partner, the more options you have as the bargaining unfolds. In Bargaining for Advantage: Negotiation Strategies for Reasonable People, G. Richard Shell argues against the existence of any one, all-purpose technique for closing a deal:

Experienced negotiators know that there are too many situational and personal variables for a single strategy to work in all cases. To become more effective, you need to get beyond simple negotiation ideas…. You need to confront your anxieties, accept the fact that no two negotiators and situations are the same, and learn to adapt to these differences realistically and intelligently—while maintaining your ethics and self-respect…. Many people are naturally accommodating and cooperative; others are basically competitive; some are equally effective using either approach. But there is only one truth about a successful bargaining style: To be good, you must learn to be yourself at the bargaining table. Tricks and stratagems that don’t feel comfortable won’t work. Besides, while you are worrying about your next tactic, the other party is giving away vital clues and information that you are missing. To negotiate well, you do not need to be tricky. But it helps to be alert and prudent. The best negotiators play it straight, ask a lot of questions, listen carefully, and concentrate on what they and the other party are trying to accomplish at the bargaining table. (2006, xvii-xviii)

Negotiate Like an FBI Agent

In the high-stakes negotiations conducted by FBI hostage negotiators, techniques that demonstrate an understanding of the emotional needs of hostage-takers can be key to a successful resolution. This article by long-time FBI agent Chris Voss includes some tips that can also be helpful in the more mundane negotiations of the business world: http://time.com/4326364/negotiation-tactics/. Voss recommends tactics like these:

- Repeat words back to the people you are negotiating with, so they feel that you are listening and have a rapport with them.

- Show empathy by saying things like “It sounds like you are concerned about…”

- Create a way for the person to say “no,” which makes a person feel safe, rather than “yes,” which can make someone feel cornered. For example questions, like: “Is now a bad time to talk?” and “Have you given up on this project?”

- Talk in a way that will encourage people to say “Yes, that’s right,” which shows they see that you understand them. (2016)

Once they have clarified their own biases in the negotiation process, effective negotiators turn their focus to learning about their negotiating partners and adapting in response to what they’ve learned. In other words, effective negotiators work in living order, staying flexible and keeping their eyes open to new information that might change their approach in the negotiation room. Shell’s approach to bargaining, which he calls information-based bargaining, capitalizes on this living order understanding of the changeable nature of human interactions. His approach focuses on three main aspects of negotiation:

Solid planning and preparation before you start, careful listening so you can find out what the other side really wants, and attending to the “signals” the other party sends through his or her conduct once bargaining gets under way. As the name suggests, Information-Based Bargaining involves getting as much reliable knowledge about the situation and other party as possible…. Information-Based Bargaining is a “skeptical school” of negotiation. It treats each situation and person you face as unique. It cautions against making overly confident assumptions about what others want or what might be motivating them. And it emphasizes “situational strategies” tailored to the facts of each case rather than a single, one-size-fits-all formula. (2006, xviii-xix)

Information-based bargaining is useful in all kinds of negotiations, helping to calm disputants in even the most contentious situations. The first phase of the process is careful research into the concerns of all parties. Robert L. Zorn explains: “The research becomes the underpinning of information-based bargaining.” For example, in a schoolboard/union negotiation, it’s helpful to start by collecting reliable information on salaries. According to Zorn:

Research should show the historical trends of salary increases as well as how those salaries rank on a comparative basis to similar school districts. This information can be compiled by percentages or dollars, by salaries paid for specific positions or by salaries as a percentage of the budget over the years and by comparability with salaries in other school districts with like fiscal resources and similar demographics….

The idea is to put together enough information that most individuals looking at the information will come to the same or a similar conclusion as to where salaries should or could go in the new agreement. Thus the bargaining is driven by information rather than what one side or the other side wants without regard to what the information shows.

This style of bargaining is predicated on the assumption that educated persons looking at the same information will come to the same or similar conclusions. Obviously, this doesn’t happen every time. In cases where it doesn’t, and matters must go to mediation, all the information compiled is extremely helpful in presenting one’s case to the mediator. The mediator also will use this information to try to get the parties to say yes to an item based on factual data rather than emotion or what one side wants. (n.d.)

12.4 Embrace the Power of Emotion

For many people, the prospect of a negotiation can generate a wave of anxiety and other negative emotions. So, it’s good to keep in mind that working out a deal with another person can also generate positive emotions, especially if you are able to

- See the negotiation as a chance to build a relationship

- Strive to have empathy for the party on the other side of the table

- Avoid taking personal offense over the natural give and take of a negotiation

Indeed, many experienced engineers find that well-conducted negotiations result in deep, trusting relationships that last throughout their careers.

Still, many people struggle with negative emotions—fear, anger, suspicion, jealousy, regret, resentment, and contempt—when involved in negotiations. General Motors took this fact into consideration when it launched its Saturn division in the 1990’s, opening dealerships committed to a strict “no-haggle” policy. That, plus “the absence of a high-pressure sales environment and the high level of customer satisfaction contributed to a sense of brand loyalty among Saturn’s customers” (Wharton School 2009). For the first time in the United States, you could walk into a dealership and buy a car without having to negotiate. For some, that felt like a huge relief.

Of course, negotiation avoidance is not a realistic option in all facets of life. But it is possible to minimize negative emotions by preparing carefully for any negotiation, and by focusing on positive emotions instead. In their book, Beyond Reason: Using Emotions as You Negotiate, Roger Fisher and Daniel Shapiro present a strategy for using positive emotions as a negotiating tool. They argue that it is impossible to evaluate and respond to every single emotion that arises among the various parties in a negotiation. Instead, they recommend focusing on the core concerns that psychologists tell us generate emotions in most people.

According to Fisher and Shapiro, core concerns are “human wants that are important to almost everyone in virtually every negotiation. They are often unspoken but are no less real than our tangible interests. Even experienced negotiators are often unaware of the many ways in which these concerns motivate their decisions” (2005, 14). Fisher and Shapiro focus on the following five core concerns:

- Appreciation—The desire to feel recognized and respected

- Affiliation—The desire to belong and have social intimacy with others

- Autonomy— The desire to make your own decisions

- Status— The desire to maintain a sense of importance relative to others that is appropriate and recognized

- Role—The desire to play a fulfilling and important part in a situation

They describe the five core concerns in Table 12-1.

Table  12-1: Five core concerns that affect everyone in a negotiation (Source: Beyond Reason: Using Emotions as You Negotiate, by Roger Fisher and Daniel Shapiro, Table 3, p. 17.)

Gender and Negotiation

At a Wharton School conference on women in business, a group of seasoned female business professionals discussed gender differences in negotiation strategies and effectiveness. They agreed that because women tend to be better listeners than men, they have a pronounced advantage in many negotiations. However, because they tend to underplay their own value in a situation, they often fail to negotiate successfully on their own behalf. You can read a summary of the conference discussion here: http://knowledge.wharton.upenn.edu/article/women-and-negotiation-are-there-really-gender-differences/. This article discusses differences in the way men and women negotiate, with suggestions on how each gender can learn from the other: http://work.chron.com/can-gender-affect-negotiation-5771.html.

Emotional Intelligence

The higher your level of emotional intelligence, the more success you’ll have at managing emotions during a negotiation. Take a moment to reread the section on emotional intelligence (the ability to recognize your own feelings and the feelings of others) in Lesson 5.

Fisher and Shapiro’s book includes a chapter on each core concern, with plentiful advice on how to use them to stimulate positive emotions such as enthusiasm, happiness, and hopefulness, which in turn can make people more prone to cooperate, more creative, and more inclined to trust each other.

In most cases, focusing on core concerns will keep the conversation moving toward a successful resolution. However, you do have to be prepared for the power of negative emotions which, according to Fisher and Shapiro, can have the following ill effects:

- tunnel vision: An inability to take in the entire situation, in which the “focus of your attention narrows and all you are aware of are your strong emotions” (147).

- behavior controlled entirely by emotion: “As your emotions escalate, you risk acting in ways you will regret…. Strong emotions inform us that a concern is probably not being met, and they rattle us to try to satisfy that concern now”(147-155).

- an equally angry negotiating partner: “Your anger can stimulate the other person’s anger, just as their anger can easily be ‘caught’ by you. Strong negative emotions are like a snowball rolling down a hill. They get bigger as they roll along”(147).

The secret to managing negative emotions is, first and foremost, being aware of them. Fisher and Shapiro recommend taking your emotional temperature throughout a negotiation “to catch your emotions before they overwhelm your ability to act wisely” (147). They offer a number of suggestions for calming yourself, including breathing deeply, temporarily changing the subject, or taking a quick break that allows you to leave the room. After a negotiation is over, try to take time to evaluate how your core concerns, and the core concerns of your negotiating partner, stimulated negative emotions in the first place.

12.5 When Worlds Collide

Cross-cultural issues can add complexity to any negotiation. For example, people from different cultures might have different conversation styles or conflicting ideas on the importance of punctuality. They might even approach a negotiation with totally different understandings of the overall purpose of a negotiation in the first place. “For deal makers from some cultures, the goal of a business negotiation, first and foremost, is a signed contract between the parties. Other cultures tend to consider that the goal of a negotiation is not a signed contract but rather the creation of a relationship between the two sides” (Salacuse 2004).

In many cultures, saving face—or, avoiding humiliation—is an essential concern in any negotiation. In that case, it may be necessary to negotiate a compromise in which one party appears to have agreed to important concessions. In some cultures, there is also a question of status. Parties will only accept negotiating with someone of perceived equal status to themselves. This web page offers some helpful suggestions for face saving in Asian cultures: https://www.tripsavvy.com/saving-face-and-losing-face-1458303.

This helpful article explains ten ways that culture can affect a negotiation: http://iveybusinessjournal.com/publication/negotiating-the-top-ten-ways-that-culture-can-affect-your-negotiation/. This article from the Harvard Business Review provides five rules of thumb for negotiating with someone from a different culture: https://hbr.org/2015/12/getting-to-si-ja-oui-hai-and-da.

Thoughts from an Experienced Negotiator

Brian Price is the former chief power train engineer for Harley-Davidson, a lecturer in the School of Engineering & Applied Science at Aston University, UK, and and an adjunct professor in the University of Wisconsin-Madison Master of Engineering in Engine Systems program. In a conversation with the authors, he shared this example of the kind of misunderstandings that can arise when negotiating across cultures:

My experience negotiating in Korea was enlightening. It is impolite to say “no” in Korea. It is considered very blunt and rude. During negotiations, I might say something like “Can we agree to a delay in delivery by two weeks?” The Korean negotiators would pause and then say “mmm…yes.” I thought we had just negotiated a delay, but we hadn’t. What the Korean negotiators meant was “I hear what you say. I’m not going to say no and be rude, but I don’t agree with your proposal.” At the time, I did not pick up on the subtle cues of the pause and the meaning of a single “yes.” If they did agree to something, it was acknowledged by a double yes, said clearly and without hesitation—“Yes, yes.” It took me several misunderstandings over several months to work this out. Such cultural confusion can be compounded by a linguistic quirk in which Japanese and Koreans answer negative questions with a positive answer, as described in this web page: http://en.rocketnews24.com/2016/01/23/when-yes-means-no-the-japanese-language-quirk-that-trips-every-english-speaker-up/.

12.6 Ethics and Negotiation

As Stan Lee, the creator of Spider Man, so memorably said, “With great power comes great responsibility.” As you hone your negotiating skills, you take on the moral burden of ensuring that you don’t use your skills to force someone into a bad situation. You also need to factor in the greater good—that is, issues that lie beyond your immediate interests or the interests of your organizations—and think about what’s best for society as a whole.

To help evaluate the ethics of any situation, the Harvard Law School’s Program on Negotiation suggests asking yourself five questions:

- Negotiation Principle 1. Reciprocity: Would I want others to treat me or someone close to me this way?

- Negotiation Principle 2. Publicity: Would I be comfortable if my actions were fully and fairly described in the newspaper?

- Negotiation Principle 3. Trusted friend: Would I be comfortable telling my best friend, spouse, or children what I am doing?

- Negotiation Principle 4. Universality: Would I advise anyone else in my situation to act this way?

- Negotiation Principle 5. Legacy: Does this action reflect how I want to be known and remembered? (Wheeler 2017)

If you can answer yes to all five questions, then you can probably assume that you are conducting an ethical and honorable negotiation.

But keep in mind that, in some situations, the ethical solution may not actually be legal. For example, lawyers may perceive the moral superiority of their opponents’ position, but be legally bound to act only in the interests of their clients. One particular challenge is the differing laws and ethical standards around the world. For international companies this can be a tricky area.

Ultimately, you need to follow your own moral compass. You should always stay within the law, but also ensure that your personal ethical standards are not being compromised through a negotiation process. If you find yourself in a situation in which your ethical and legal obligations are murky, seek out advice from a more experienced professional in your field. You should also consult the Code of Ethics for Engineers, published by the National Society of Professional Engineers, which is available here: https://www.nspe.org/sites/default/files/resources/pdfs/Ethics/CodeofEthics/Code-2007-July.pdf.

For a more in-depth discussion of ethics and bargaining, check out Chapter 11 of G. Richard Shell’s book Bargaining for Advantage. Among many helpful ideas, he includes some suggestions on what to do when you face unethical tactics from your negotiating partners.

Negotiating in Good and Bad Faith

Robert Merrill, Senior Business Analyst at the UW-Madison and a seasoned project manager, has spent a lot of time reading and thinking about negotiation tactics. In his project management work this was essential, he says, because “a lot of projects live or die on how they handle conflict, which means negotiation is really the art of handling disagreements” (pers. comm., June 19, 2018).

One essential part of negotiating is remembering that most people negotiate in good faith, but some people routinely negotiate in bad faith. This is especially true of people with dark triad personalities—that is personalities marked by narcissism, a lack of empathy (psychopathy), and Machiavellianism, or a desire to manipulate others (Whitbourne 2013).

Here’s what Merrill has to say on the topic:

Most of the time, negotiation is not a competition, but sometimes, but when you are dealing with a dark-triad personality it absolutely is. Such people are attracted to power, and they tend to climb organizational ladders at least for a while, because they “get things done” and have a way of offloading their failures and avoiding the collateral damage.

On the other hand, just because a small percentage of the population is a psychopath, doesn’t mean everyone is. So don’t react to each aggressive negotiation request with weaponized facts, treating the negotiation like a form of combat. In other words, assume the people across the table are negotiating in good faith.

But when you do verify that you’re sitting across from someone who doesn’t care if you make a promise your team can’t keep, which will burn them up and damage your reputation in the process, you have to behave quite differently. Verify the support of your allies. Marshal your facts. Draw on your deepest well of unconditional positive regard—the other person is a human soul, too, and you have no idea how they got to where they are. Then crank your boundaries and empathy up to 10 and wade in.

To prepare for this kind of situation, I suggest reading Never Split the Difference, by Chris Voss. (pers. comm., June 19, 2018)

12.7 Resolving Disputes

As a project manager, you will often have to marshal your negotiation skills in order to resolve disputes among stakeholders. Most disputes are small affairs that people can work out amongst themselves. On the other end of the spectrum are complicated and highly charged legal disputes that require the work of lawyers specially trained in dispute resolution law. Hopefully your experience will be limited to the former, but as a project manager you should at least be familiar with the following terms:

- dispute resolution: A “process for resolving differences between two or more parties or groups” (Business Dictionary).

- arbitration: A dispute resolution method in which the disputing parties agree to let a neutral third party make a final decision. This article explains the many issues involved in arbitration: http://www.mediate.com/articles/grant.cfm.

- consensus building: A “conflict-resolution process used mainly to settle complex, multiparty disputes” (Burgess and Spangler 2003).

- mediation: A dispute resolution process in which a neutral third party helps “disputants come to consensus on their own” (Program on Negotiation: Harvard Law School 2018).

You can avoid disputes in the first place by doing the following:

- Make sure all contracts, plans, proposals, and other documents are clearly written and easy to understand.

- Make sure your decision-making processes are as transparent as possible. For example, in construction, it’s helpful to have a clear process for change orders, so there’s no uncertainty about why a team member spent so much money or why they thought they had the authority to do so in the first place.

Getting Everyone to Agree

Consensus building, which is widely used to solve complicated environmental and public policy disputes, is “useful whenever multiple parties are involved in a complex dispute or conflict. The process allows various stakeholders (parties with an interest in the problem or issue) to work together to develop a mutually acceptable solution” (Burgess and Spangler 2003). Consensus-building emphasizes working toward a solution that everyone can live with. It is typically time-consuming and doesn’t work for every type of problem, but it can result in satisfying long-term solutions to seemingly intractable problems.

Consensus building is especially effective when

- The problem is not well-defined, or the disputants disagree on the definition

- Disputants have widely varying interests and yet are interconnected in some important way. This is often the case in disputes involving natural resources

- Previous attempts to solve the problem, perhaps by imposing a solution, have proving fruitless

For more on consensus building, see the following:

- An introduction to the topic published by the Conflict Information Consortium at the University of Colorado, Boulder: http://www.beyondintractability.org/essay/consensus-building

- Examples of consensus building around the world, published by the Consensus Building Institute, a nonprofit organization devoted to helping people collaborate to solve complex problems: https://www.cbi.org/resources/

~Practical Tips

- Stay focused: For each negotiation, have clear, specific objectives in mind that keep participants focused on project success.

- Look for ways to turn a competitive negotiation into a shared pursuit of project goals: Focus on options that create a clear, common goal with shared consequences and motivation to work collaboratively. For example, you could set up a shared incentive fund for on-time, on-budget project completion.

- Be the negotiating partner you want to have: Remember that each negotiation is an interaction with a partner with whom you need have a constructive on-going relationship. Putting a project partner in an impossible bind may put the success of the project in jeopardy.

- Use mindfulness exercises to manage negotiation-related anxiety: It’s entirely normal to feel anxious while negotiating. Simply admitting to yourself that you do feel uneasy can go a long way toward lessening the effects of your anxiety. This article describes a few classic calming techniques: https://www.everyday-mindfulness.org/3-quick-mindfulness-practices-to-overcome-worry-anxiety-and-panic/.

- Be sincere and show respect: Many studies underscore the importance of honesty and sincerity in any negotiation. Before and during the negotiation, seek to understand and show respect for the other party’s interests.

- Make sure you know what you want: Before you walk into a negotiation, clarify what is important to you and why it is important.

- Understand the alternatives you would be willing to accept: Instead of thinking in terms of a bottom line, or a “walk away”—that is, the issue that will force you to walk away from the negotiation—think in terms of a best alternative to a negotiated agreement, or BATNA, as explained here: http://www.negotiationtraining.com.au/articles/next-best-option/. Having a clearly defined BATNA helps you understand your options, should your negotiation fail.

- Use your negotiation time wisely: Show respect to the other parties in the negotiation by valuing their time. Make it clear that the goal of the process is to come to an agreement and not to continue negotiating endlessly.

- Don’t let multiple options decrease your effectiveness as a negotiator: You might think that having multiple offers on the negotiation table gives you more leverage, but research suggests otherwise. Why? “In some cases, having several low offers caused people to underestimate the value of what they were selling…inhibiting their ability to hold out for a better deal.” By contrast, “having a single strong offer on the table rather than many undesirable offers can instill feelings of power and confidence and allow for bolder negotiating strategies” (Harvard Business Review 2017).

- Take action to break an impasse: If you find a negotiation grinding to a halt, try some options for getting unstuck, as described here: https://oluchinwaiwu.wordpress.com/2009/10/01/five-ways-of-resolving-an-apparent-deadlock-in-a-negotiation/ and here: https://www.cedr.com/solve/advice/?p=9.

- Don’t be afraid to say nothing: Silence is an amazingly effective negotiation technique. It forces the other party to fill up the empty conversational space, often by making unexpected concessions. Such hard-ball tactics are not usually desirable because they can cause irreparable damage to relationships between the negotiation parties. But depending on the situation and the gravity of the negotiation, sometimes they are necessary.

- Walk a mile in your negotiating partner’s shoes: You’ll always get better results in a negotiation if you can make the effort to understand everyone’s point of view. The easiest way to do this is simply talking to your opposite number in the negotiation about what he or she hopes to achieve. In high-stakes negotiations involving lots of people, consultants will sometimes ask participants to spend a day role-playing—acting out the part of the people across the table from them. This forces all participants to internalize perspectives other than their own.

- Think about what you’ve learned: Reflect on every negotiation experience and use what you learn in future negotiations.

~Summary

- The need for negotiation, or settling differences, is a fact of human life. Negotiation is not a competition. There should be no losers. Nobody gets everything they want in a successful negotiation, but everybody gets something. Perhaps most importantly, a wisely conducted negotiation ensures that the parties can continue to work together in the future.

- In their seminal 1981 book, Getting to Yes, Roger Fisher and William Ury recommend focusing on interests in a negotiation, instead of staking out positions that you then have to defend. Rather than setting up a “me versus you” situation, Fisher and Ury advocate a method called principled negotiation.

- The more you know about yourself and your negotiating partner, the more options you have as the bargaining unfolds. In Bargaining for Advantage: Negotiation Strategies for Reasonable People, G. Richard Shell recommends an approach he calls information-based bargaining, which involves careful preparation and listening, and understanding that every negotiation is unique.

- Well-conducted negotiations can result in long-lasting, trusting relationships that can sustain your career. To avoid negative emotions, prepare for each negotiation carefully, and try to focus on positive emotions. In their book, Beyond Reason: Using Emotions as You Negotiate, Roger Fisher and Daniel Shapiro recommend focusing on the core concerns that psychologists tell us generate emotions in most people.

- Cross-cultural issues can add complexity to any negotiation. For example, in many cultures, saving face—or, avoiding humiliation—is an essential concern in any negotiation. In that case, it may be necessary to negotiate a compromise in which the opposing party appears to have agreed to important concessions.

- As you hone your negotiating skills, you take on the moral burden of ensuring that you don’t use your skills to force someone into a bad situation. You also need to factor in the greater good—that is, issues that lie beyond your immediate interests or the interests of your organizations—and think about what’s best for society as a whole.

- As a project manager, you will often have to marshal your negotiation skills to resolve disputes among stakeholders. Tools for resolving disputes include arbitration, consensus building, dispute resolution, and mediation.

~Glossary

- arbitration—A dispute-resolution method in which the disputing parties agree to let a neutral third party make a final decision.

- consensus building: A “conflict-resolution process used mainly to settle complex, multiparty disputes” (Burgess and Spangler 2003).

- core concerns—According to Roger Fisher and Daniel Shapiro, “human wants that are important to almost everyone in virtually every negotiation. They are often unspoken but are no less real than our tangible interests” (2005, 14). Fisher and Shapiro focus on the following five core concerns: appreciation, affiliation, autonomy, status, and role.

- dispute resolution—A “process for resolving differences between two or more parties or groups” (Business Dictionary n.d.).

- information–based bargaining—An effective type of negotiation described by G. Richard Shell in his book Bargaining for Advantage, which focuses on “three main aspects of negotiation: solid planning and preparation before you start, careful listening so you can find out what the other side really wants, and attending to the ‘signals’ the other party sends through his or her conduct once bargaining gets under way” (Shell 2006, xviii-xix).

- mediation—A dispute resolution process in which a neutral third party helps “disputants come to consensus on their own” (Program on Negotiation: Harvard Law School 2018).

- negotiation—A discussion with the goal of reaching an agreement that is moderately satisfying to both parties. Nobody gets everything they want in a successful negotiation, but everybody gets something. Perhaps most importantly, a wisely conducted negotiation ensures that the parties can continue to work together in the future.

- positional bargaining—An inefficient form of negotiation in which opposing parties take up positions and defend them, making only small concessions when forced to do so.

~References

Burgess, Heidi, and Brad Spangler. 2003. “Consensus Building.” Beyond Intractability. September. http://www.beyondintractability.org/essay/consensus-building.

Business Dictionary. n.d. “Dispute Resolution.” BusinessDictionary. Accessed June 15, 2018. http://www.businessdictionary.com/definition/dispute-resolution.html.

Fisher, Roger, and Daniel Shapiro. 2005. Beyond Reason: Using Emotions as You Negotiate. New York: Penguin Books.

Fisher, Roger, and William Ury. 2011. Getting to Yes: Negotiating Agreement Without Giving In, Updated and Revised Edition. Edited by Bruce Patton. New York: Penguin Books.

Harvard Business Review. 2017. “Negotiation: You Can Have Too Many Options.” Harvard Business Review, September-October: 30.

Program on Negotiation: Harvard Law School. 2018. “What are the Three Basic Types of Dispute Resolution? What to Know About Mediation, Arbitration, and Litigation.” PON. April 19. http://www.pon.harvard.edu/daily/dispute-resolution/what-are-the-three-basic-types-of-dispute-resolution-what-to-know-about-mediation-arbitration-and-litigation/.

Salacuse, Jeswald W. 2004. “Negotiating: The Top Ten Ways that Culture Can Affect Your Negotiation.” Ivey Business Journal, September/October. http://iveybusinessjournal.com/publication/negotiating-the-top-ten-ways-that-culture-can-affect-your-negotiation/.

Shell, G. Richard. 2006. Bargaining for Advantage: Negotiation Strategies for Reasonable People, Revised and Updated Edition. New York: Penguin Books.

Trapp, Roger. 1998. “How to Get What You Really Want.” Independent, April 2. https://www.independent.co.uk/arts-entertainment/how-to-get-what-you-really-want-1153841.html.

Voss, Chris. 2016. “5 Tactics to Win a Negotiation, According to an FBI Agent.” Time, May 25. http://time.com/4326364/negotiation-tactics/.

Wharton School. 2009. “Saturn: A Wealth of Lessons from Failure.” Knowledge@Wharton. October 28. http://knowledge.wharton.upenn.edu/article/saturn-a-wealth-of-lessons-from-failure/.

Wheeler, Michael. 2017. “5 Principles of Negotiation to Boost Your Bargaining Skills in Business Situations: How to Use the Principles Behind Negotiation Ethics to Create Win-Win Agreements for You and Your Bargaining Counterpart.” PON. June 7. http://www.pon.harvard.edu/daily/negotiation-training-daily/questions-of-ethics-in-negotiation/.

Whitbourne, Susan Krauss. 2013. “Shedding Light on Psychology’s Dark Triad.” Psychology Today. January 26. https://www.psychologytoday.com/us/blog/fulfillment-any-age/201301/shedding-light-psychology-s-dark-triad.

Zorn, Robert L. n.d. Information-Based Bargaining for a New Age. Accessed June 15, 2018. http://www.aasa.org/SchoolAdministratorArticle.aspx?id=8034.

13

Project Closure and Audits

Experts often possess more data than judgment.

—Colin Powell, Secretary of State (Harari 2003)

Objectives

After reading this lesson, you will be able to

- Discuss the importance of getting the fundamentals right and keeping them right throughout a project

- Explain the value of project reviews and audits

- Describe issues related to correcting course mid-project and decisions about terminating a project

- Discuss the project closure phase

The Big Ideas in this Lesson

- Many little things can go wrong in a project, but as long as you get the fundamentals right and keep them on target, a project is likely to achieve substantial success. However, just because you have the fundamentals right at the beginning of a project doesn’t mean they’ll stay that way.

- Throughout the life of a project, you need to stop, look, and listen, and adjust course as necessary. Focus more on staying flexible than seeking accountability for every little thing that goes wrong in a project.

- By conducting regular, careful periodic reviews, you increase the chance of detecting strategic inflection points in your projects earlier enough to allow you time to adapt and adjust.

13.1 Getting the Fundamentals Right

The Toyota Way to Stop, Look, and Listen

A key principle of the famously Lean Toyota Production System is genchi genbutsu, which means “go and see for yourself.” In other words, if you really want to know what’s going on in a project, you need to actually go to where your team is working, and then watch and listen. This idea is predicated on the fact that “when information is passed around within organizations it is inevitably simplified and generalized. The only real way to understand a problem is to go and see it on the ground” (The Economist 2009). You can learn how Yuji Yokoya, a Toyota engineer, used genchi genbutsu (in the form of a 53,000-mile drive across North America), to plan a redesign of the Toyota Sienna: https://www.forbes.com/forbes/2003/0217/056a.html#1c660d4575d6.

Many little things can go wrong in a project, but as long as you get the fundamentals right and keep them on target, a project is likely to achieve substantial success. As you’ve learned throughout this book, the best way to get the fundamentals right is to collaborate with stakeholders to create a comprehensive, realistic plan, while also remaining adaptable to the inevitable living order changes that will come your way. But just because you have the big things right at the beginning of a project doesn’t mean they’ll stay that way. Throughout the life of a project, you need to stop, look, and listen. That is, you need to stop periodically to conduct mid-project reviews/audits; look at the data about scope, quality, and schedule; and listen to the words of team members. Regular stop-look-and-listen breaks will provide essential insights into the current state of your project, and its prospects for the future.

Even if you’re working on a project that seems identical to others you’ve worked on in the past, you need to stay alert to the possibility that the ground could suddenly shift beneath your feet. And the only way to know if that’s happening is to regularly stop, look and listen. Or to use the words of Andrew Grove, CEO of Intel from 1997 to 2005, you need to maintain a “guardian attitude” toward all your projects, cultivating a constant level of paranoia about what you might not know about your project (1999, 3). In particular, Grove argues, you need to be paranoid about strategic inflection points, which can upend even the best laid plans. In his book Only the Paranoid Survive, he explains the dangers strategic inflection points pose to entire organizations, although much of what he says can apply equally well to individual projects:

A strategic inflection point is a time in the life of a business when its fundamentals are about to change. That change can mean an opportunity to rise to new heights. But it may just as likely signal the beginning of the end.

Strategic inflection points can be caused by technological change but they are more than technological change. They can be caused by competitors but they are more than just competition. They are full-scale changes in the way business is conducted, so that simply adopting new technology or fighting the competition as you used to may be insufficient. They build up force so insidiously that you may have a hard time even putting a finger on what has changed, yet you know that something has.

Let’s not mince words: A strategic inflection point can be deadly when unattended to. Companies that begin a decline as a result of its changes rarely recover their previous greatness.

But strategic inflection points do not always lead to disaster. When the way business is being conducted changes, it creates opportunities for players who are adept at operating in the new way. This can apply to newcomers or to incumbents, for whom a strategic inflection point may mean an opportunity for a new period of growth. (Grove 1999, 3-4)

Drawing on his many years of experience in the semiconductor business, Grove argues that the people best positioned to detect strategic inflection points are middle managers:

In middle management, you may very well sense the shifting winds on your face before the company as a whole and sometimes before your senior management does. Middle managers—especially those who deal with the outside world, like people in sales—are often the first to realize that what worked before doesn’t quite work anymore; that the rules are changing. They usually don’t have an easy time explaining it to senior management, so the senior management in a company is sometimes late to realize that the world is changing on them—and the leader is often the last of all to know. (Grove 1999, 21-22)

The Power of Checklists

You might occasionally hear people dismiss an audit as a checklist exercise in which project managers work their way through a list of items by rote, with no attempt to make decisions based on experience and judgement. However, a judicious use of checklists can be highly beneficial during any auditing and review process. Atul Gawande, has written extensively on checklists used by skilled professionals, such as surgeons and airline pilots. In his books The Checklist Manifesto and Better, he illustrates the power of this simple tool. This New Yorker article by Gawande is a good introduction to the topic: http://www.newyorker.com/magazine/2007/12/10/the-checklist.

As a project manager, the best way for you to sense those shifting winds is to practice regular stop-look-and-listen breaks. You might detect strategic inflection points in your industry—and if so, you can use what you’ve learned to make your case to upper management. But the fact is you are more likely to detect strategic inflection points in your individual projects, which, taking our inspiration from Grove, we define here as a time in the life of a project when its fundamentals are about to change. Your goal, as a project manager, is to detect strategic inflection points in your projects earlier enough to allow you time to adapt and adjust. The best way to make sure that happens is to conduct regular project audits.

13.2 Auditing: The Good, the Bad, the Ugly

To stay in good health, it’s important to monitor some basics every day, perhaps by checking your weight or wearing a fitness monitor to make sure you get enough exercise. But sometimes you need to schedule a full workup to get external insights from a knowledgeable medical professional. The same is true of technical projects. Even if you have implemented reliable monitoring systems designed to alert you to any serious problems, as recommended in Lesson 11, every now and then you need to dive deeper into your project via an audit so that you can learn everything you need to know—the good, the bad, the ugly, and the unexpected.

So what exactly is a project audit? It is a deep investigation into any or all aspects of a project, with the aim of enabling stakeholders to make fully informed decisions about the project’s future. An audit can provide a focused, objective review of part or all of a project.

Scrum Retrospective

The idea of an audit is built into Scrum, the most popular form of Agile software development. This pause in development, known as a retrospective, “is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint” (Scrum.org n.d.). Like any group critique, retrospectives can be contentious, and are often not handled well. You can learn more about how to engineer a helpful retrospective here: https://www.scrum.org/resources/what-is-a-sprint-retrospective.

Audits can be relatively informal or formal. An informal audit is a relatively quick evaluation of a project, as when a new project manager attempts to take stock of a project by talking to everyone involved, and trying to learn as much as possible about the project objectives. A formal audit is more systematic, and is typically conducted by someone external to the project, or even, depending on the scope of the audit, external to the organization.

The ultimate goal of any audit is to generate actionable intelligence that can be used to improve the project or, when necessary, justify shutting it down. This intelligence is usually presented in the form of an audit report, which typically contains an explanation of the context of the audit, including the overall focus or any important issues; an analysis of data, interviews, and related research compiled during the audit; action-oriented recommendations; and, in some cases, lessons learned and possibly one or more supporting appendices.

In some organizations, audits or formal project reviews are conducted at the end of certain phases to determine if the project is worth continuing or if the project plan requires significant changes before the team moves forward. An audit can be used to

- Review all projects meeting certain criteria (size, risk, client, regulations, etc.)

- Revalidate the business feasibility of a project

- Reassure upper management that a project is viable

- Reconfirm upper management support for the project

- Confirm readiness to move to the next project phase

- Investigate specific problems to determine the next step

- Verify market conditions

Issues that could be addressed in an audit include

- Project rationale: Why was the project selected in the first place? Is that rationale still valid?

- Project’s role in the organization’s priorities: As markets change, requirements for projects also change. Have recent changes lessened or increased the project’s priority? Do you need to end the project entirely or should you add more resources in order to finish it more quickly?

- Team status: Is the project team functioning well and appropriately staffed?

- External factors affecting the project’s direction and importance: Have new regulations, competing products, or technology altered the playing field?

- Budget and schedule: It’s important to get accurate data on the current status of the budget and schedule, and check on the reasonableness of projections at completion. An independent reviewer can sometimes turn up previously unperceived issues regarding these two essential items.

- Performance of contractors: How’s the quality of their work? Are they on schedule? Are their budget projections in line with reality?

Checking in With the Team

In addition to auditing individual projects, it’s a good idea to conduct regular audits of your team. And be sure to include yourself, as the project manager, in the audit. Few people like being formally evaluated in their work, but you can minimize the negative feelings by conducting team audits often and routinely, so people see them as simply part of their job, and not as a targeted attempt to undermine them.

Brian Price (see “From the Trenches,” later in this lesson) has the following suggestions for anyone conducting a team audit:

- Begin by asking the individual to evaluate his or her own performance.

- Avoid drawing comparisons with other team members; rather, assess the individual in terms of established standards and expectations.

- Focus criticism on specific behaviors rather than on the individual personally.

- Be consistent and fair in your treatment of all team members.

- Treat the review as one point in an ongoing process. (2007)

Anonymous surveys of the team are one way to conduct a team audit. This article from Slate describes a survey app that works similar to a dating app, allowing people to swipe left or right to rate their own performance, as well as the performance of team members and their managers: http://www.slate.com/articles/business/the_ladder/2016/06/can_new_app_tinypulse_disrupt_performance_reviews.html.

Whatever survey method you choose, make sure your team sees you use the information obtained from the survey to improve the team’s performance. Otherwise they’ll lose confidence in future team audits, and in you as a project manager. Team audits can address individual “burn-out” issues and help not only individual performance but also team retention.

Different organizations have different auditing procedures, but the heart of any audit is listening to the opinions of the people involved in the project via interviews or surveys. According to Todd C. Williams, author of Rescue the Problem Project,

People are the critical piece in determining a project’s success or failure. They approve the inception, allow scope creep, define the technical solution, and levy constraints. What are the team’s dynamics? Who are the sponsors? What are their expectations? What is the leadership’s strength? What do these people think is wrong with the project? Does the team have the right skills? What would the team do to fix the project? The answers to these questions lead to more questions and eventually point to the root problems…. In other words, team members know the problems and their accompanying resolutions; someone just needs to ask them. Therefore, the people involved in a project are the best place to start an audit. (2011, 35)

The Pull Value of an Audit

Audits provide an excellent opportunity to learn and assess. They also provide a safe opportunity to ask the question: Should we continue this project (with or without modifications) or should we terminate it? When conducted routinely—and always with the guardian attitude recommended by Andrew Grove—they allow for a periodic timeout in which the team steps back to view their progress from a higher perspective, focusing on quality, schedule, cost, resources, and generally viability. An audit should result in some kind of report summarizing the audit findings, but generally speaking, you should avoid viewing an audit as an opportunity for excessive documentation of the past. Instead, think of an audit as an opportunity to pull from the desired ends of the project to the current state, asking some essential questions:

- What has to happen next to best assure success in reaching the desired end state, allowing us to deliver the promised value?

- Is the next phase in the project worth the required investment?

Take the Sensitive Approach

Organizations vary in their approach to audits. Some conduct audits routinely on all major projects. Others reserve audits for projects that appear to be heading for trouble. In other organizations, audits are conducted routinely only for certain types of projects. Whatever approach your organization takes, it’s essential to structure and conduct an audit in a manner appropriate to the project and to the people and organizations involved. In particular, you need to be sensitive to the culture of the project team itself, so as not to alienate the people you will be relying on to give you accurate information about the project.

Organizations that conduct regular, structured assessments of all projects tend to create a safer, more open environment for meaningful, helpful project reviews and associated follow-up action. Sometimes even simply using the term “project review” instead of “audit” can make the activity seem less threatening. Also, if reviews are conducted for all projects, project managers and team members are less likely to feel under attack during a project audit, as they understand this is part of business as usual. This can build a culture that values open, frank review, discussion, and collaborative problem-solving.

Make sure stakeholders see the audit as an attempt to learn about the project, rather than a blame-seeking investigation. A professional, systematic approach, in which you listen carefully and respectfully to all parties, will go a long way toward calming anxious participants. The more informed people are about the planning and delivery of an audit, and the more opportunities they have to offer input, the more helpful the audit results will be.

Characteristics of an Effective Audit Leader

- No direct involvement or direct interest in the project

- Respect (perceived as impartial and fair) of senior management and other project stakeholders

- Willingness to listen

- Independence and authority to report audit results without fear of recriminations from special interests

- Perceived as having the best interests of the organization in making decisions

- Broad-based experience in the organization or industry

A project auditor is the person responsible for leading an audit or review. Ideally, the project auditor is an outsider who is perceived by all stakeholders to be fair and objective. He or she should have excellent listening skills and broad-based knowledge of the organization or industry. It’s helpful to use an audit team consisting of peers from other projects. This can help ensure that the team under review feels that their auditors understand the constraints they face in executing the project; they’ll engage with the auditing team as peers, rather than a critical body. The project teams can return the favor by critiquing the auditors’ project at another stage. If an audit is undertaken by an external party, it is important that the audit team is respected by the team under review. This helps diffuse any feelings of being unfairly criticized.

The Right Person for the Job

An important key to a successful audit is an audit leader who is trusted and respected by all stakeholders, who is believed to have the best interests of the organization at heart, and who has broad-based experience in the industry. In some situations, to avoid the appearance of a conflict of interest, it’s best to choose as the auditor an impartial person, with no direct involvement in the project. As Michael Stanleigh explains, an auditor who is unconnected to the project makes it possible for team members and other stakeholders to be completely candid:

They know that their input will be valued and the final report will not identify individual names, rather it will only include facts. It is common that individuals interviewed during the project audit of a particularly badly managed project will find speaking with an outside facilitator provides them with the opportunity to express their emotions and feelings about their involvement in the project and/or the impact the project has had on them. This “venting” is an important part of the overall audit. (n.d.)

However, to avoid the appearance that the point of the audit is designed to catch the team doing something wrong, sometimes it’s better to allow the team to review itself. This approach can encourage people to step forward to share what they’ve learned about the project, both good and bad. After all, the ultimate point of an audit or project review is to help the organization learn about the project.

Because an audit is primarily a learning experience, the ideal audit leader has the ability to listen to what other people are saying, as well as to what they are not saying, looking beneath the surface for hidden currents that are shaping the project’s performance. The audit leader should then be able to weave all the information obtained in the audit into a coherent picture of the project’s current status and future prospects.

In addition to these formidable personal requirements, an audit leader should be granted the ability to operate independently, with the authority to report audit results without fear of recrimination. He or she has to be willing to deliver bad news if necessary, and must have an appropriate forum to do so—whether in formal reports, presentations, or emails.

Fail Fast

Terminating a project is hard, especially if the team is emotionally and professional invested in the project. Adopting a fast fail methodology, especially for high risk projects, can normalize project termination, making it easier for a project team to pull the plug when necessary. This article discusses the success reaped by business leaders who weren’t afraid to confront their own failures: http://www.newyorker.com/business/currency/fail-fast-fail-often-fail-everywhere.

Todd C. Williams uses the term recovery manager to refer to a consultant who is brought in from the outside to audit a failing project, and, if possible, steer it to a successful conclusion. In his view, selecting the right recovery manager is the essential first step:

Selecting the right recovery manager is critical. Avoid choosing someone currently involved with the project, as people involved in the project are too close to see the issues and may be perceived as biased by the stakeholders. At a minimum, the person doing the audit should be someone outside the extended project and unassociated with the product. An objective view is critical to a proper audit and reducing any preconceptions of a solution. The ideal candidate is a seasoned, objective project manager who is external to the supplier and customer, has recovery experience, and a strong technical background (for the conversations with the technical team). Compare this with hiring a financial auditor. No one would ever recommend engaging someone internal or with no experience, as it would create too high a chance of someone not believing the audit results…. Above all, recovery managers need to be honest brokers—objectivity is paramount. They cannot have allegiance to either side of the project. (17-19)

13.3 Correcting Course or Shutting a Project Down

First, Admit You have a Problem

In his book Rescue the Problem Project, Todd C. Williams shares what he’s learned as a professional “rescue manager” who traveled the world, applying his expertise to help turn around endangered projects in several industries. When he shows up on the scene, his first goal is to get project stakeholders to acknowledge the existence of a problem in the first place: “All afflictions, from everyday ailments to addictions, have one thing in common—if people choose to ignore them, they remain untreated. Therefore, before you start any process, you must admit there is a problem. Without admitting a problem exists and committing to resolve it, the problem will continue. It may morph and manifest itself in a new way, but it still exists” (15).

Based on the audit’s findings, the team could decide to proceed per current plans, revise the plan (i.e., tasks and sequence), revise the schedule, revise the budget, revise the scope, bring in new team members or remove team members, or terminate the project. A project audit can also investigate whether a team is adding or losing members too frequently, causing the project to veer from one goal to another. Sometimes only a few quick, easy-to-implement course corrections are required. But if large-scale changes are necessary, you will need to agree on a change management strategy that will minimize resistance to the necessary alterations “through the involvement of key players and stakeholders” (Business Dictionary n.d.).

Resistance to any kind of change is often driven by fear. And as Vijay Govindarajan and Hylke Faber explain, we are never our best selves when we are afraid:

When we’re in the grip of our fears, we are at least 25 times less intelligent than we are at our best. We don’t think straight. And we’ll most likely reject anything that takes us out of our comfort zone. This reaction is well known today as the “amygdala hijack.” It’s when our more primitive, or “crocodilian” brain wired for survival takes over. When our crocodiles are active, we are resistant to change and are operating from a fear of survival. Our crocodiles are trying to keep us safe, at the cost of innovation and change. (2016)

Govindarajan and Faber argue that the best way to drain fear of its power is to speak in a straightforward and matter-of-fact way about team members’ anxieties. They also recommend using humor when appropriate, and projecting an aura of confidence and courage.

The Fine Art of Decision-Making

Successfully correcting course in a project presumes that you and your team are effective decision-makers. So you’d be wise to learn all you can about decision-making throughout your career. Here are a few resources to help you get started:

- Decisive: How to Make Better Choices in Life and Work by Chip and Dan Heath—An introduction to basic research on decision-making, with pointers on how to make better choices.

- Smart Choices: A Practical Guide to Making Better Decisions by John S. Hammon, Ralph L. Keeney, and Howard Raiffa—A more analytical approach to decision-making that emphasizes establishing a useful process that “gets you to the best solution with a minimal loss of time, energy, money, and composure” (2015, 3).

- How to Make Decisions: Making the Best Possible Choices—A quick overview of helpful decision-making strategies: https://www.mindtools.com/pages/article/newTED_00.htm.

- Deciding How to Decide: An evaluation of useful decision-making tools, with suggestions on how to choose the right tool for a particular decision: https://hbr.org/2013/11/deciding-how-to-decide.

If an audit reveals the painful truth that it’s time to terminate a project, then it’s important to realize that this is not necessarily a bad thing:

Canceling a project may seem like a failure, but for a project to be successful, it must provide value to all parties. The best value is to minimize the project’s overall negative impact on all parties in terms of both time and money. If the only option is to proceed with a scaled-down project, one that delivers late, or one that costs significantly more, the result may be worse than canceling the project. It may be more prudent to invest the time and resources on an alternate endeavor or to reconstitute the project in the future using a different team and revised parameters. (Williams, 8)

When considering terminating a project, it’s helpful to ask the following questions:

- Has the project been made obsolete or less valuable by technical advances? For instance, this might be the case if you’re developing a new cell phone and a competitor releases new technology that makes your product undesirable.

- Given progress to date, updated costs to complete, and the expected value of the project’s output, is continuation still cost-effective? Calculations about a project’s cost-effectiveness can change over time. What’s true at the beginning of the project may not be true a few months later. This is often the case with IT projects, where final costs are often higher than expected.

- Is it time to integrate the project into regular operations? For example, an IT project that involves rolling out a new network system will typically be integrated into regular operations once network users have transitioned to the new system.

- Are there better alternative uses for the funds, time, and personnel devoted to the project? As you learned in in Lesson 2, on project selection, the key to successful portfolio management is using scarce resources wisely. This involves making hard choices about the relative benefits of individual projects. This might be an especially important concern in the case of a merger, when an organization has to evaluate competing projects and determine which best serve the organization’s larger goals.

- Has a strategic inflection point, caused by a change in the market or regulatory requirements, altered the need for the project’s output?

- Does anything else about the project suggest the existence of a strategic inflection point—and therefore a need to reconsider the project’s fundamental objectives?

Determining whether to terminate a project can be a very difficult decision for people close to a project to make. As the Figure 13-1 illustrates, your perspective on a project has a huge effect on your judgment of its overall success. That is why a review conducted by an objective, external auditor can be so illuminating.

Figure 13-1: Your definition of project success and failure depends on your perspective
Source: Adapted from Figure 1-1, Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure

13.4 Closing Out a Project

Project closure is traditionally considered the final phase of a project. It includes tasks such as

- Transferring deliverables to the customer

- Cancelling supplier contracts

- Reassigning staff, equipment, and other resources

- Finalizing project documentation by adding an analysis summarizing the project’s ups and downs

- Making the documentation accessible to other people in your organization as a reference for future projects

- Holding a close-out meeting

- Celebrating the completed project

Seen from a geometric order perspective, these tasks do mark the definitive end of a project. However, in the broader, living order vision of a project’s life cycle, project closure often merely marks the conclusion of one stage and the transition to another stage of the project’s overall life cycle, as shown in Figure 13-2. Seen from this perspective, project closure is actually an extension of the learning and adjusting process that goes on throughout a project. This is true in virtually all industries, although the actual time it takes to cycle through from a plan to the idea for the next version can vary from weeks to years.

The close-out meeting is an opportunity to end a project the way you started it—by getting the team together. During this important event, the team should review what went well, what didn’t go well, and identify areas for improvement. All of this should be summarized in the final close-out report. A final close-out meeting with the customer is also essential. This allows the organization to formally complete the project and lay the groundwork for potential future work.

The close-out report provides a final summary of the project performance. It should include the following:

- Summary of the project and deliverables

- Data on performance related to schedule, cost, and quality

- Summary of the final product, service, or project and how it supports the organization’s business goals

- Risks encountered and how they were mitigated

- Lessons learned

Figure 13-2: Seen from a living order perspective, closure is an extension of the learning and adjusting process that goes on throughout a project

Exactly where your work falls in the project’s life cycle depends on your perspective as to what constitutes “the project” in the first place. The designers and constructors of a building might consider the acceptance of the building by the owner as project closure. However, the results of the project—that is, the building—lives on. Another contractor might be hired later to modify the building or one of its systems, thus starting a new project limited to that work.

If project closure is done thoughtfully and systematically, it can help ensure a smooth transition to the next stage of the project’s life cycle, or to subsequent related projects. A well-done project closure can also generate useful lessons learned that can have far-reaching ramifications for future projects and business sustainability. The closeout information at the end of a project should always form the basis of initial planning for any future, similar projects.

Although most project managers spend time and resources on planning for project start-up, they tend to neglect the proper planning required for project closure. Ideally, project closure includes documentation of results, transferring responsibility, reassignment of personnel and other resources, closing out work orders, preparing for financial payments, and evaluating customer satisfaction. Of course, less complicated projects will require a less complicated close-out procedure. As with project audits, the smooth unfolding of the project closure phase depends to a great degree on the manager’s ability to handle personnel issues thoughtfully and sensitively. In large, on-going projects, the team may conduct phase closures at the end of significant phases in addition to a culminating project closure.

13.5 From the Trenches: Brian Price

Brian Price, a graduate of the UW Master of Engineering in Professional Practice program (a precursor of the Masters in Engineering Management program), is the former chief power train engineer for Harley-Davidson. He teaches engine project management in the UW Master of Engineering in Engine Systems program. In his twenty-five years managing engine-related engineering projects, he had ample opportunity to see the benefits of good project closure procedures, and the harm caused by bad or non-existent project closure procedures. In his most recent role as a professor of engineering, he tries to encourage his students to understand the importance of ending projects systematically, with an emphasis on capturing wisdom gained throughout a project.

Brian shared some particularly insightful thoughts on the topic in an interview:

The hardest parts of any project are starting and stopping. Much of project management teaching is typically devoted to the difficulties involved in starting a project—developing a project plan, getting resources in place, putting together a team, and so on. But once a project is in motion, it gains momentum, taking on a life of its own, making it difficult to get people to stop work when the time comes. It therefore requires some discipline to get projects closed out in a structured way that ties up all the loose ends. Close out checklists can help. (For one example, see Figure 14.2 in Project Management: The Managerial Process, by Erik W. Laron and Clifford F. Gray.) The close-out also needs to wrap up final budgets and reallocate resources.

Generally speaking, the end of a project is a perfect time to reflect on what went well and what could be done differently next time. The After Action Review (AAR) process, derived from military best practice, is very helpful. It focuses on three distinct, but related areas:

1. Project performance: Did it meet objectives? Was it done efficiently and effectively?

2. Team performance: How well did people work together? Were they stronger than the sum of their parts?

3. Individuals’ performances: How did individuals perform? This relates to their personal development.

To learn more about the AAR process, see this in-depth explanation in the Harvard Business Review: https://hbr.org/2005/07/learning-in-the-thick-of-it.

The reflections at the end of a project are a great opportunity to capture key learning, whether technical, managerial, or related to project execution. This can then be codified for dissemination and application on other projects. Continually building a knowledge base is essential for improving techniques and best practice. This never comes easy, as it can be seen as bureaucratic report writing, so as a project manager you will need to insist on it. Keep in mind that the point of building a knowledge base is not, of course, to improve the project you are closing out, but to improve the many as yet undetermined projects that lie ahead.

Focus on what it took to deliver the project (time, resources, tasks, budgets, etc.) compared to the original plan. This information is essential in planning the next project. After all, the main reason projects fail is because they were inadequately planned, and the main reason they are inadequately planned is because the planners lacked complete planning information. Your best source of good planning information is wisdom gained from recent, similar projects. Thus, it is essential to capture and disseminate that information at the close of every project.

Finally, don’t discount the importance of honoring the achievements of the project team. The project closure stage is a good time to build morale with an end-of-project celebration, especially when a close-knit team is about to be dispersed into other projects. People need a coherent conclusion to their work.

Unfortunately, most organizations pay little attention to project closure. This is partly due to basic human psychology—people get excited by the next opportunity. They tend to drift off to the next interesting thing, and something new is always more interesting than something old. But a deeper problem is that organizations tend to be more interested in what the project is delivering, rather than the knowledge and wisdom that allows the company to deliver the project’s value. The real worth of an organization is the knowledge that allows it to continue generating value. For Harley Davidson, for example, that would be its collective knowledge of how to make motorcycles. A well-conducted project closure adds to that knowledge, transforming specific experience into wisdom that the organization can carry forward to future undertakings (2016).

Failure: The Best Teacher

In their book Becoming a Project Leader, Laufer et al. explain the importance of a tolerance for failure. Projects will occasionally close or radically change course, but that doesn’t mean that the team members who worked on such projects were ineffective. In fact, coping with such challenges can help individuals and teams be much more efficient. In his capacity as a project manager for the U.S. Air Force’s Joint Air-to-Surface Standoff Missile, Terry Little’s response to a failed missile launch was not to scold the contractor, Lockheed, for its failure but rather to ask how he could help. Larry Lawson, project manager at Lockheed, called Terry’s response “the defining moment for the project . . . . Teams are defined by how they react in adversity—and how their leaders react. The lessons learned by this team about how to respond to adversity enabled us to solve bigger challenges.” As Laufer et al. articulate, “By being a failure-tolerant leader, Terry Little was able to develop a culture of trust and commitment-based collaboration” (2018).

~Practical Tips

Here are a few practical tips related to project audits and project closure:

- Pair inexperienced personnel with pros: People become acutely aware of the loss of knowledge when people retire or move on for other reasons. If an organization lacks a systematic way to archive information, the hard-won knowledge gained through years of experience can walk out the door with the departing employee. To prevent such a loss of vital knowledge, consider pairing inexperienced engineers with older ones, so knowledge is transferred. As a project manager, this is one way you can help to capture knowledge for the good of your team and organization.

- Interview team members or create video summaries: If you’re having a hard time getting team members to put their end-of-project summaries down in writing, consider interviewing them and taking notes. Another great option is to ask them to create short videos in which they describe their work on the project. Often people will be more candid and specific when talking to a camera than they are in a formal, written report.

- Tell your project’s story: Sometimes it’s helpful to compile a project “biography” that documents a project’s backstory in a less formal way than a project audit. Often this is just an internal document, for the use of the project team only. The more frank you can be in such a document, the more valuable the project biography will be. Also, keep in mind that the most important information about a project is often shared among team members via stories. After all, human cultures have always used stories to express norms and pass on information. They can be a powerful means of exploring the true nature of a project, including the emotional connections between team members. As a project manager, remember to keep your ears open for oft-repeated stories about the projects you are working on, or about past projects. What you might be inclined to dismiss as mere office gossip could in fact offer vital insights into your organization, your project stakeholders, and your current projects.

- Make your data visual: When writing an audit or closure report, it’s essential to present data in a way that makes it easy for your intended readers to grasp. This article from the Harvard Business Review offers helpful ideas for creating effective visualizations of project data: https://hbr.org/2016/06/visualizations-that-really-work.

- Create a repository for audit reports and project summaries: Take the time to establish an organizational repository for storing audit reports and project summaries (whether in writing or video) made by team members. Periodically invite new and experienced project managers to review the repository as a way to promote organization-wide learning and professional development. Make sure this repository is accessible to the entire organization, and not stowed away in the personal files of an individual project manager.

- Don’t rush to finalize project documentation on lessons learned: Sometimes the best time to reflect on a project and pinpoint what you learned is a few weeks or months after the conclusion of project execution. Taking a little time to let things settle will allow you to see the bigger picture and fully understand what went right and what went wrong.

- Take the time to celebrate every project: There are a variety of ways to celebrate and recognize everyone’s accomplishments. Some examples include writing personalized thank you letters, writing a letter of reference for each of your team members, giving out awards that have special meaning and value to each person on the team, taking a team picture, creating a team song or a team video that recaps the project, endorsing each project member for specific skills on LinkedIn. You can probably think of many other ways to celebrate a completed project. The important thing is to do something.

- Know when to say you’re done: Sometimes, as a project heads toward its conclusion, you have to ask “When is done done?” This can be an issue with some clients, who might continue to ask for attention long after your team’s responsibility has ended. An official project closure procedure can help forestall this kind of problem, by making it clear to all parties that the project is officially over.

~Summary

- Many little things can go wrong in a project, but as long as you get the fundamentals right and keep them on target, a project will likely achieve substantial success. However, just because you have the big things right at the beginning of a project doesn’t mean they’ll stay that way. Throughout the life of a project, you need to stop, look, and listen, maintaining a certain level of paranoia about the health of the project and jumping in to alter course when necessary.

- Even if you have implemented reliable monitoring systems designed to alert you to any serious problems, you will sometimes need to dive deeper into your project via a formal audit or informal review. The ultimate goal of any audit/review is to generate actionable intelligence in the form of an audit report that can be used to improve the project or, when necessary, justify shutting it down.

- Deciding whether to correct course or shut a project down entirely is rarely easy, and is often governed more by fear than good decision-making practices. It’s important to start by seeking honest answers to questions about the project to determine its viability. You also need to keep in mind that a stakeholder’s perspective on a project will influence his or her evaluation of a project’s viability.

- Project closure is traditionally considered the final phase of a project, but when seen from the broader, living order perspective, it often merely marks the conclusion of one stage and the transition to another stage of the project’s overall life cycle. If project closure is done thoughtfully and systematically, it can help ensure a smooth transition to the next stage of the project’s life cycle, or to subsequent related projects.

~Glossary

- audit—A deep investigation into any or all aspects of a project, with the aim of enabling stakeholders to make fully informed decisions about the project’s future. An audit can provide a focused, objective review of part or all of a project.

- audit report—A report created at the end of an audit that typically contains an explanation of the context of the audit, including the overall focus or any important issues; an analysis of data, interviews, and related research compiled during the audit; action-oriented recommendations; and, in some cases, lessons learned and possibly one or more supporting appendices.

- change management—“Minimizing resistance to organizational changes through the involvement of key players and stakeholders” (Business Dictionary n.d.).

- close-out meeting—An opportunity to end a project the way you started it—by getting the team together. During this important event, the team should review what went well, what didn’t go well, and identify areas for improvement. All of this should be summarized in the final close-out report. A final close-out meeting with the customer is also essential. This allows the organization to formally complete the project and lay the groundwork for potential future work.

- close-out report—A final summary of project performance. It should include a summary of the project and deliverables; data on performance related to schedule, cost, and quality; a summary of the final product, service, or project and how it supports the organization’s business goals; risks encountered and how they were mitigated; and lessons learned.

- genchi genbutsu—A key principle of the famously Lean Toyota Production System, which means “go and see for yourself.” In other words, if you really want to know what’s going on in a project, you need to actually go to where your team is working, and then watch and listen.

- project audit/review—An inquiry into any or all aspects of a project, with the goal of learning specific information about the project.

- project closure—According to most project management publications, the final phase of a project. However, in the broader, living order vision of a project’s life cycle, project closure often merely marks the end of one stage and the transition to another stage of the project’s overall life cycle—although exactly where your work falls in the project’s lifecycle depends on your perspective as to what constitutes “the project” in the first place.

- recovery manager—Term used by Todd C. Williams in Rescue the Problem Project to refer to a consultant brought in from the outside to audit a failing project, and, if possible, get it back on the path to success (17-19).

- strategic inflection point—As defined by Andrew Grove, CEO of Intel from 1997 to 2005, “a time in the life of a business when its fundamentals are about to change. That change can mean an opportunity to rise to new heights. But it may just as likely signal the beginning of the end” (1999, 3). A strategic inflection point in an individual project is a time in the life of a project when its fundamentals are about to change.

- project auditor—The person responsible for leading an audit or review. Ideally, the project auditor is an outsider who is perceived by all project stakeholders to be fair and objective. He or she should have excellent listening skills and broad-base knowledge of the organization or industry.

~References

Business Dictionary. n.d. “Change management.” BusinessDictionary.com. Accessed June 5, 2018. http://www.businessdictionary.com/definition/change-management.html.

Govindarajan, Vijay , and Hylke Faber . 2016. “Managing Uncertainty: What FDR Knew About Managing Fear in Times of Change.” Harvard Business Review, May 4. https://hbr.org/2016/05/what-fdr-knew-about-managing-fear-in-times-of-change.

Grove, Andrew S. 1999. Only the Paranoid Survive: How to Exploit the Crisis Points That Challenge Every Company . New York: Doubleday.

Hammon, John S., Keeney, Ralph L. Keeney, and Howard Raiffa. 2015. Smart Choices: A Practical Guide to Making Better Decisions. Cambridge: Harvard Business Review Press.

Harari, Oren. 2003. “18 Lessons: A Leadership Primer, Quotations from Colin Powell.” Absolute Advantage. http://www.csun.edu/~alliance/Wellness_Coreteam/Absolute%20Advantage%20Magazine/Articles/Collin%20Powell%2018_lessons.pdf.

Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects. New York: Palgrave Macmillan.

Price, Brian. 2007. Lecture slides for Engine Project Management, week 13, University of Wisconsin-Madison. Madison, May 5.

—, interview by Jeff Russell and Ann Shaffer. 2016. Technical Project Management (September 2).

Scrum.org. n.d. “What is a Sprint Retrospective?” Scrum.org. Accessed July 29, 2018. https://www.scrum.org/resources/what-is-a-sprint-retrospective.

Stanleigh, Michael. n.d. “Undertaking a Successful Project Audit.” Business Improvement Architects. Accessed June 2, 2018. https://bia.ca/undertaking-a-successful-project-audit/.

The Economist. 2009. “Genchi genbutsu.” The Economist, October 13. https://www.economist.com/news/2009/10/13/genchi-genbutsu.

Williams, Todd C. 2011. Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure. New York: AMACOM.

14

Personal and Organizational Project Management Growth

An organization’s ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage. (Slater 1998, 12)

—Jack Welch, CEO of General Electric, 1981-2001

Objectives

After reading this lesson, you will be able to

- Discuss the role of learning in personal and organizational transformation

- Explain issues related to project management maturity models

- Distinguish between thin and thick sustainability

- List ways to facilitate personal project management maturity

- List ways to facilitate organizational project management maturity

The Big Ideas in this Lesson

- All organizational and personal change starts with learning. The kind of evolution associated with living order project management is a natural result of taking in new ideas and information. Don’t persevere in a particular approach or methodology simply because it’s the one you know.

- A focus on project management maturity, and the organizational learning that goes along with it, are essential components of any continuous improvement effort.

- An important element of your personal project management maturity is figuring out where you and your organization stand on questions of sustainability.

- You need to commit to your own personal development.

14.1 Developing Yourself and Your Organization

The word “development” is widely used in business to refer to a process of transformation. In “product development” it refers to the transformation of an idea into a new product. In “real estate development” it refers to the transformation of a piece of property into something of greater value by constructing buildings, creating roads, and so on. Personal and organizational development are also processes of transformation—change that makes a person a more effective project manager, change that makes an organization a more successful company.

Throughout these lessons, you have read about the many ways that dynamic, ever-changing living order affects the work of project managers. Now we’ll consider how these agile, resourceful thinkers embrace the change required to advance their own personal development, as well as the development of their organizations. We’ll also focus on the concept of project management maturity and the maturity models used to measure it. Then we will explore the many ways that learning can make you a better project manager, and the cultural and organizational barriers to effective learning.

Learning and Mindfulness

Researchers have discovered a lot about the effects of mindfulness, a state of nonjudgemental awareness, on an individual’s ability to learn. Here are a few topics that you might want to explore on your own:

- Jon Kabat-Zinn, author and founder of the Stress Reduction Clinic and the Center for Mindfulness in Medicine, explains his definition of mindfuless in this short, 1.5-minute: video: https://www.youtube.com/watch?v=gWaK2mI_rZw

- In his research on well-being and neuropolasticity, neuroscientist Richard Davidson has shown that the human brain can be transformed through meditation and other mindfulness practices. He describes the brain as the “organ which is built to change in response to experience, more than any other organ in our body.” In this hour-long video he discusses his latest research: https://www.youtube.com/watch?v=7tRdDqXgsJ0

- This article by Kiron Bondale offers suggestions on how to be a mindful project manager: https://www.projecttimes.com/kiron-bondale/be-a-mindful-project-manager.html

- Beware of cognitive biases that can affect your decision-making abilities. This article lists 20 common biases to watch out for: http://www.businessinsider.com/cognitive-biases-that-affect-decisions-2015-8

14.2 The ABCs of Learning

All organizational and personal change starts with learning. But what is learning in the first place? It’s not just acquiring information. According to Daniel H. Kim, it is a process of accumulating both know-how and know-why:

Learning encompasses two meanings: (1) the acquisition of skill or know-how, which implies the physical ability to produce some action, and (2) the acquisition of know-why, which implies the ability to articulate a conceptual understanding of an experience….

For example, a carpenter who has mastered the skills of woodworking without understanding the concept of building coherent structures like tables and houses can’t utilize those skills effectively. Similarly, a carpenter who possesses vast knowledge about architecture and design but who has no complementary skills to produce designs can’t put that know-why to effective use. Learning can thus be defined as increasing one’s capacity to take effective action. (Kim 1993)

Robert Merrill, Senior Business Analyst and a project manager veteran, also recommends making time for know-when learning—that is, learning when specific tools and tactics are useful. For instance, a coach knows how to motivate athletes in a number of ways, but a great coach knows when to use each type of motivation. And keep in mind that part of learning is practicing. You never fully learn how to do something until you actually do it (pers. comm., July 2, 2018).

Take a moment to think about that: learning is “increasing one’s capacity to take effective action.” That may not be true of all learning—you might want to learn about Roman history, or metalworking simply because it gives you pleasure and deepens your understanding of life in general, not because either pursuit will prepare you for action. But as you plot your professional development, you would be wise to remember that time devoted to learning is a limited resource. So learning that increases your capacity for effective on-the-job action, and that positions you for future assignments with increased responsibility, is your best investment.

According to Morgan W. McCall, Jr., who has written extensively on personal development, that kind of learning is usually the result of hands-on experience. He argues that leaders are made, not born, through the trial and error learning that occurs through actual work: “adversity, challenge, frustration, and struggle lead to change” (1998, xiv). However, despite mountains of research showing that experience is the best teacher, organizations often sabotage their employees’ ability to learn from failure:

The paradox of wanting people to learn from experience, which by definition involves trial and error, yet punishing them when trial resulted in error, highlights a fundamental dilemma for development. That is, for learning to occur, the context must support learning…. At the most basic level, development is directly affected by the organization’s business strategy (what it is trying to achieve) and by its values (what it is willing to do to get there). These organizational issues determine what is desired, what is rewarded, and what is tolerated. (Morgan W. McCall, 58)

As a project manager, you probably can’t control whether your organization’s business strategy supports and values experiential learning, but you can strive to cultivate non-judgmental project teams that allow for learning from experience.

14.3 Project Management Maturity

The changing nature of living order ensures that organizations that continue to do what they’ve always done will, sooner or later, find themselves unable to compete in the modern market place. Those that succeed often embrace some form of continuous improvement, a key practice of Lean project management in which organizations focus on improving “an entire value stream or an individual process to create more value with less waste” (Lean Enterprise Institute 2014). Or to put it more simply, they strive to create “a culture of continuous improvement where all employees are actively engaged in improving the company” (Vorne).

The exact form continuous improvement takes in an organization varies depending on the industry, the current state of the market, and so on. But for project-centered organizations, a focus on project management maturity, and the organizational learning that goes along with it, are essential components of any continuous improvement effort. Indeed, as David A. Garvin explains, continuous improvement is impossible without learning:

How, after all, can an organization improve without first learning something new? Solving a problem, introducing a product, and reengineering a process all require seeing the world in a new light and acting accordingly. In the absence of learning, companies—and individuals—simply repeat old practices. Change remains cosmetic, and improvements are either fortuitous or short-lived. (1993)

The term project management maturity refers to the “progressive development of an enterprise-wide project management approach, methodology, strategy, and decision-making process. The appropriate level of maturity will vary for each organization based on its specific goals, strategies, resource capabilities, scope, and needs” (PMSolutions 2012). Before you can assess an organization’s overall project management maturity, it’s helpful to have an objective standard of comparison to help you understand the context in which you are operating. In other words, you need a project maturity model, also known as a capability maturity model. A maturity model is a set of developmental stages that can be used to evaluate an organization’s state of maturity in a particular domain. More specifically, according to Becker, Knackstedt, and Poppelbuss, a maturity model

represents an anticipated, desired, or typical evolution path of these objects shaped as discrete stages. Typically, these objects are organizations or processes. The bottom stage stands for an initial state that can be, for instance, characterized by an organization having little capabilities in the domain under consideration. In contrast, the highest stage represents a conception of total maturity. Advancing on the evolution path between the two extremes involves a continuous progression regarding the organization’s capabilities or process performance. (2009)

Among other things, a maturity model offers

- The benefit of a community’s prior experiences

- A common language and a shared vision

- A framework for prioritizing actions

- A way to define what improvement means for your organization (Select Business Solutions n.d.)

The first widely used maturity model, the Capability Maturity Model (CMM), was developed in the software industry in the late 1980’s by the Software Engineering Institute (SEI) at Carnegie Mellon University, working in conjunction with the United States Department of Defense. Mary Rouse describes the five levels of CMM maturity as follows:

- At the initial level, processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.

- At the repeatable level, basic project management techniques are established, and successes could be repeated, because the requisite processes would have been established, defined, and documented.

- At the defined level, an organization has developed its own standard software process through greater attention to documentation, standardization, and integration.

- At the managed level, an organization monitors and controls its own processes through data collection and analysis.

- At the optimizing level, processes are constantly being improved through monitoring feedback from current processes and introducing innovative processes to better serve the organization’s particular needs. (Rouse 2007)

Since the development of the CMM, over a hundred maturity models have been developed for the IT industry alone (Becker, Knackstedt and Poppelbuss 2009). Meanwhile, other industries have developed their own models, each designed to articulate the essential stages of maturity for a particular type of organization. Developing and implementing proprietary maturity models, and assessment tools to determine where an organization falls on the maturity spectrum, is a specialty of countless business consulting firms. Around the world, the most widely recognized maturity model is the Organizational Project Management Maturity Model (OPM3), developed by the Project Management Institute. The OPM3 is designed to help an organization support its organizational strategy from the project level on up through the portfolio and program levels. You can read more about it here: https://www.pmi.org/learning/library/grow-up-already-opm3-primer-8108.

The ultimate goal of any maturity model is to help an organization change where change will introduce clear benefits. According to Joseph A. Sopko, “research from many sources continues to show that higher organizational maturity is synonymous with higher performance” (2015). As maturity models become more widely used, project-based organizations should factor in

the market value of being recognized as a reliable supplier. If the organization’s maturity is lower than customer or market expectations, it may be viewed as a high-risk supplier that would add performance risk to its customers’ programs. And, obviously, if the organization’s maturity is lower than that of its competitors, it will lose competitive advantage since higher OPM maturity has been correlated with reliably delivering to plan and meeting customer expectations.(Sopko 2015)

14.4 Knowledge Management and Organizational Learning

Many projects deliver tangible outcomes, such as physical artifacts, buildings, and infrastructure. Others produce software, reports, or other types of output. But all projects create knowledge. Indeed, this knowledge can end up being more valuable to the organization than any short-term financial gain. However, because intellectual capital is longer-term and intangible, it is often underappreciated at the point of creation.

An organization that is fully committed to project management maturity does not make this mistake. On the contrary, it cultivates a culture of systematic knowledge management, which William R. King defines as follows:

Knowledge management is the planning, organizing, motivating, and controlling of people, processes, and systems in the organization to ensure that its knowledge-related assets are improved and effectively employed. Knowledge-related assets include knowledge in the form of printed documents such as patents and manuals, knowledge stored in electronic repositories such as a “best-practices” database, employees’ knowledge about the best way to do their jobs, knowledge that is held by teams who have been working on focused problems, and knowledge that is embedded in the organization’s products, processes, and relationships.

The processes of KM involve knowledge acquisition, creation, refinement, storage, transfer, sharing, and utilization. The KM function in the organization operates these processes, develops methodologies and systems to support them, and motivates people to participate in them.

The goals of KM are the leveraging and improvement of the organization’s knowledge assets to effectuate better knowledge practices, improved organizational behaviors, better decisions, and improved organizational performance.

Although individuals certainly can personally perform each of the KM processes, KM is largely an organizational activity that focuses on what managers can do to enable KM’s goals to be achieved, how they can motivate individuals to participate in achieving them, and how they can create social processes that will facilitate KM success. (2009)

When done right, knowledge management leads to organizational learning, or the process of retaining, storing, and sharing knowledge within an organization. More than the sum of the knowledge of all the members of the organization, organizational knowledge “requires systematic integration and collective interpretation of new knowledge that leads to collective action and involves risk taking as experimentation” (Business Dictionary n.d.).

Organizational learning as we define it here is a positive thing, a source of renewal for successful companies. But not all learning leads to good outcomes. Haphazard learning that occurs without any conscious evaluation can lead to bad habits and half-baked notions about best practices. As Daniel H. Kim explains, learning is an essential function of all organizations, but it’s not all productive:

All organizations learn, whether they consciously choose to or not—it is a fundamental requirement for their sustained existence. Some firms deliberately advance organizational learning, developing capabilities that are consistent with their objectives; others make no focused effort and, therefore, acquire habits that are counterproductive. Nonetheless, all organizations learn. (1993)

In Lesson 13, we discussed some important ways to contribute to organizational learning—capturing lessons learned during project closure, and taking part in communities of practice. These and other practices can help transform a company into a learning organization, which David A. Garvin defines as “an organization skilled at creating, acquiring, and transferring knowledge, and at modifying its behavior to reflect new knowledge and insights” (1993). Note that knowledge is only half of the equation. A true learning organization responds to knowledge by modifying its behavior:

This definition begins with a simple truth: new ideas are essential if learning is to take place. Sometimes they are created de novo, through flashes of insight or creativity; at other times they arrive from outside the organization or are communicated by knowledgeable insiders. Whatever their source, these ideas are the trigger for organizational improvement. But they cannot by themselves create a learning organization. Without accompanying changes in the way that work gets done, only the potential for improvement exists. (Garvin 1993)

Sharing Learning as Stories

The authors of Becoming a Project Leader worked with several companies (Procter & Gamble, Motorola, NASA, Skanska and Turner, and Boldt) to create communities of practice. These organizations identified their best project managers to take part in a forum, which would meet 2-4 times per year for a day or two per meeting. Forum members submit stories before meeting, and a handful of those stories are then selected for discussion. At the meeting, stories are discussed and reflected upon and then eventually published and shared with the entire organization.

Denise Lee extended the community of practice concept with her Transfer Wisdom Workshops at NASA to help serve “NASA’s practitioners who were not members of the community of practice and were located at NASA centers throughout the US.” As stated by Denise, “Our aim was to help the men and women who work on NASA projects step away from their work for a moment in order to better understand it, learn from it, and then share what they learned with others” (2003).

The concept of the learning organization was first popularized by Peter Senge in the early 1990’s in his book The Fifth Discipline: The Art and Practice of the Learning Organization. Since then many researchers have investigated the role of learning in organizations. After over two decades of study and experimentation, the general consensus is that, to be effective, learning needs to be targeted at specific goals. Most importantly, according to Shlomo Ben-Hur, Bernard Jaworski, and David Gray, it should support the organization’s strategy:

Too many corporate learning and development programs focus on the wrong things. A better approach to developing a company’s leadership and talent pipeline involves designing learning programs that link to the organization’s strategic priorities…. The word learning, which has largely replaced training in the corporate lexicon, suggests “knowledge for its own sake.” However, to justify its existence, corporate learning needs to serve the organization’s stated goals and should be based on what works. (Ben-Hur, Jaworski and Gray 2015)

This is a good time to reflect back on Daniel H. Kim’s definition of learning as “increasing one’s capacity to take effective action.” It’s one thing for an individual to translate learning into effective action. It’s quite another for an organization made up of hundreds or thousands of individuals to accomplish the same thing. Despite millions of dollars invested in learning initiatives, organizations struggle to become learning organizations. In their article “Why Organizations Don’t Learn,” Francesca Gino and Bradley Staats discuss some barriers to learning that include 1) an excessive focus on success that prevents people from learning from failure, 2) and a tendency to rely on perceived experts rather than on the people who are on the front lines, dealing with and learning about a problem (2015).

Another barrier to organizational learning is a tendency to view it as simply the acquisition of information (the know-how), without giving equal weight to the big-picture understanding (the know-why) that comes from actual experience at the individual, team, project, and corporate level. As a result, organizations as a whole, and the individuals within them, fail to realize that the best way to learn about a job is often by actually doing the job. It’s at the project level that individuals achieve growth and learning, and eventually succeed in reaching their goals.

14.5 Sustainability: Thick or Thin?

As you look ahead for ways to expand your project management skills and knowledge, put learning about sustainability at the top of your list. First of all, you need to figure out where you and your organization stand on questions of sustainability. These days, organizations like to make big claims about their commitment to preserving natural resources, but in reality, their efforts often amount to little more than earnest public relations campaigns. In fact, they have no real interest in overturning the dominant paradigm, which sees the natural world solely as a supply of resources for human use.

To come to terms with your ideas on sustainability, you need to understand your personal definition of the kind of value you want to create as an engineer. In his book The New Capitalist Manifesto, Umair Haque introduced the idea of thin and thick value. Thin value is consumerist (think McMansions and Hummers); often generated “through harm to or at the expense of people, communities, or society”; unsustainable because it is created with no regard to the environment; and, according to Haque, ultimately meaningless because “it often fails to make people, communities, and society durably better off in the ways that matter to them most” (2011, 19-20). By contrast, thick value is everything thin value is not. It is sustainable and meaningful over the long term, helping support communities and preserving the environment while allowing a business to generate a profit. Haque points to companies like Wal-Mart, Nike, and Starbucks as examples of thick-value enterprises.

But let’s assume you and your organization share a very real commitment to sustainability. You still need to figure out the limits of your commitment in the face of financial realities. As a way of assessing individual or organizational approaches to sustainability, Robert O. Vos reinterpreted Haque’s ideas, defining thin and thick versions of sustainability. Thin sustainability views financial capital and natural capital (that is, natural resources) as equally important. It seeks “to ensure that the overall value of natural and financial capital must be undiminished for future generations, even if the mix of the two is allowed to change.” It assumes that “economic growth is highly desirable and has infinite potential; growth is assumed to occur due to the capacity of technology, through human ingenuity, to make more with less and…to make substitutes for destroyed natural capital” (2007). In other words, thin sustainability is buoyed by a faith in the power of technology to make up for the damage humans inflict on the environment.

Thick sustainability takes a harder line, viewing any diminution of natural capital as unacceptable. Thick versions of sustainability look to redefine “how we measure economic growth; they may look to see reductions in growth rate or even reductions in the size of the economy. To mitigate this definition, thicker versions of sustainability often differentiate between growth and development. The focus here is on new ways of measuring the quality of life or of products, rather than as monetary values of economic output” (Vos 2007).

So where do you stand on the thin/thick spectrum? And how about your organization? As you work to develop your personal project management maturity, you’ll need to think long and hard about these questions. To learn more, you can start by reading Becoming Part of the Solution: The Engineers Guide to Sustainable Development, by Bill Wallace. He encourages engineers to radically transform the way they work:

Instead of finding ways to extract resources faster, we can be inventing and applying new technologies that use less material and energy. Instead of finding ways to sell more products, we can help clients get more service per unit of product. We can find ways to use natural systems to serve our needs for lighting, heating, and cooling. We can design buildings and other structures for flexibility in use, reuse, and recyclability, thereby reducing life cycle costs.

Pursuing this course will bring about new engineering challenges, challenges that will force us to work smarter and call upon a broad set of skills and resources. These are the sorts of challenges that can attract young people into engineering, showing them how they can apply what they learn to make a difference in the world instead of following old and discouraging pathways. (2005, ix)

Communicating Your Vision of Sustainability

The ability to communicate effectively is essential in every part of an engineer’s job. But it is especially important in sustainable endeavors, which typically require a great deal of interaction between an organization and the general public. Such projects often hinge on the ability to get a wide array of stakeholders on board. Job one, then, is explaining exactly how your project will help society and protect the environment.

Michael Mucha, Chief Engineer and Director for the Madison Metropolitan Sewerage District, and the current Chair for ASCE’s Committee on Sustainability, points out that Envision, a sustainability rating system for civil infrastructure, factors communication into its calculations:

Whereas LEED is a sustainability rating system for habitable, vertical infrastructure. Envision is a rating system for horizontal, non-habitable infrastructure, like roads, wetlands restorations, airports, and water treatment facilities. It’s a way to evaluate how sustainable a project is. One measure for the Envision rating is how well you communicate with the public about the project. That illustrates the importance of communication in sustainable engineering. (2017)

14.6 Personal Project Management Maturity

Taking the time to understand your organization’s project management maturity level offers a helpful corollary effect: it allows you to see your own personal development within a broader context, rather than seeing yourself as an isolated entity. You can’t really begin to pursue your larger professional goals until you understand where you fit into the big picture. If you find yourself working for a company with only the lowest level of project management maturity, you will likely have to lead the way to more effective project management processes, educating yourself in the process. If you work at a company with a well-established project management infrastructure, you will have more opportunities to learn from colleagues and upper management.

Advice from a Microsoft Engineering Manager

Ashwini Varma, principal group engineering manager at Microsoft, credits her desire to solve problems as a key to her success as a project manager. In an interview with Craig Lee, principal engineering manager at Microsoft, she shared some advice for maturing into an effective project manager.

I’ve always had an innate drive to solve problems. When I see chaos, my first reaction is to organize. When I see pain, I want to heal it. This tendency made it natural for me to seek out roles in completely new areas, with new teams and new management. That wasn’t easy, but it gave me confidence to take on even more challenging work.

In the process, I learned that you can’t force your will on a project team. You can’t start telling people who have already been working together what you want them to do now. Instead, you need to work deeply with a team, learn the technology, and develop a realistic understanding of what is possible. Only then can you start to comprehend how to build a sustainable, realistic plan, and only then can you establish your credibility with the team.

Over time I also learned the importance of hiring the right team for the right problem. You can’t underestimate the importance of building the right team. The fact is, engineers are not interchangeable. You need to determine what you need to succeed, then hire engineers who can do that work.

Of course, once you have the team you need, it’s essential to set up monitoring systems that keep you informed on their progress. I like to have multiple feedback loops that provide a picture of the project from different angles, and I encourage other managers on my teams to do the same thing. (2018)

Whatever your situation, you need to commit to your own personal development. Here are some tips to help you pursue growth as a confident, competent project manager, and a leader in your organization.

- Commit to the following practices you have learned about throughout this book:

- Embracing living order tactics, using them whenever they are appropriate

- Making reliable promises

- Implementing Lean principles whenever they are appropriate

- Maintaining a clear, sustained focus on value

- Providing meaningful, current, and accurate information

- Engaging constructively in difficult discussions and being willing to share bad news

- Cultivating a culture of learning and adaptation on your project teams

- Use pull planning instead of push planning whenever appropriate

- Take advantage of formal and informal learning opportunities

- Read the appendix to High Flyers: Developing the Next Generation of Leaders, by Morgan W. McCall: In the book’s appendix, “Taking Charge of your Development,” McCall includes a host of useful suggestions, checklists, and questionnaires. He also offers practical yet inspiring advice, such as the following:

Perhaps the most crucial skill of all when it comes to personal growth is learning how to create a learning environment wherever you are. There is no pat formula, but there are some common-sense actions that might help. Treat people in ways that make them want to coach you, support you, give you feedback, and allow you to make mistakes. Seek out feedback on your impact, and information on what you might do differently. Experiment. Take time to reflect, absorb, and incorporate. (Morgan W. McCall 1998)

- Write a “lessons learned” summary for each project: The post-course self-assessment and key take-aways document that you are assigned to complete at the end of this class are your opportunities to write the kind of reflective “lessons learned” summary that you should continue to create throughout your career. Even if your organization doesn’t require it, take the time to compile such an assessment at the end of each project or phase. Don’t waste time trying to write polished prose—just make notes about what did and didn’t work. As suggested in Lesson 13, you could make a short video or audio recording instead if that would be easier than putting your thoughts in writing.

- Tell stories: Sharing stories with colleagues about past work experiences is an important part of professional development. Sometimes one well-told tale—perhaps shared over lunch or in an elevator on the way to a meeting—can teach more about how a company works than a week of classroom training. Take the time to listen to the stories your coworkers have to share. Consider keeping a list of insights gleaned from casual conversations over the course of a month. You’ll be surprised how much you learned when you thought you were doing something else. Peter Gruber’s seminal article, “The Four Truths of the Storyteller,” published in the Harvard Business Review, documents the power of stories to motivate and inspire: https://hbr.org/2007/12/the-four-truths-of-the-storyteller.

- Cultivate a relationship with a trusted mentor: Having an external point of reference for honest feedback can be invaluable. When you think you have enough experience, offer to serve as a mentor for other people, sharing what you have learned, and staying alert to what you can learn from their experiences.

Three Types of Mentorship

In Becoming a Project Leader, Terry Little describes three types of mentorship. First is formal mentoring programs within organizations, which almost never work. As Terry explains, “Many so-called leaders fail to recognize that mentoring is as important as anything they do and more important than most of what they do.” The larger problem with formal mentoring, however, is the fact that mentees “are incentivized by external reward rather than a desire to improve and grow.” Next is informal mentoring, in which someone more senior in the company chooses mid-level managers. Terry’s approach: “I meet with each person I mentor regularly—nominally once a quarter. I also meet with everyone I mentor as a group once each six months. In between, I send articles or suggested readings, as well as some words of counsel that come to me. To me and to them it’s critical that these things be predictable and personal—something they can count on and that means something to them as diverse individuals.”

The final type of mentorship is informal-informal mentoring. Terry explains: “As we progress up the career chain, our behaviors become more and more visible to an increasingly larger number of people. We are not conscious of it, but others take their cues from those higher up the bureaucratic pyramid than they are. They observe our behavior and make judgments about it. Is it something worth emulating? If so, how can I adapt that behavior to my unique personality? Is it something to avoid? If so, how do I sensitize myself so that I don’t do it unconsciously? Much of what we turn out to be as individuals derives from what we have learned from observing others—not from what others have told us, what we have read and so forth. When others seek to emulate us, we have mentoring at its finest. But when one sees basic leadership principles working effectively in real life, it can have a profound effect” (Little 2004).

- Seek professional and personal experiences that broaden your skills: You can’t expect to learn much from familiar experiences, so look for things that take you a few steps outside your normal comfort zone. For example, direct, face-to-face interactions with customers and colleagues you don’t normally interact with will teach you volumes about how your organization works (and doesn’t work).

- Don’t shy away from leadership roles: Leading projects is often the first step in the development path for a new manager. A project, whether big or small, offers a unique opportunity to enhance leadership skills without necessarily having direct authority over all team members.

- Embrace challenges: Don’t shy away from difficult challenges just because you think they’ll make your life complicated. Think of new job assignments as opportunities for growth and development. This is especially true of new job assignments outside of engineering, in sales, marketing, or other areas.

- Cultivate grit: Best-selling author Angela Duckworth argues that the secret to success is grit—that is, passion and perseverance in pursuit of very long-term goals. Gritty people display extraordinary stamina, work extremely hard, and are willing to pick themselves up after failure and try again. She explains her research on the topic in this six-minute TED talk: https://www.ted.com/talks/angela_lee_duckworth_grit_the_power_of_passion_and_perseverance#t-173940.

- Be prepared to make the ethical choice: In Lesson 8 you read about the many factors affecting our perceptions of right and wrong. Often moral grey areas can make it hard to decide on the right course of action, so you have to lay the groundwork for ethical behavior ahead of time. Do your personal values align with the goals of your organization? Do they align with your individual projects? Take some time to discuss these questions with colleagues who have experience with similar situations. Also make sure you are familiar with the Code of Ethics for Engineers, published by the National Society of Professional Engineers, which is available here: https://www.nspe.org/sites/default/files/resources/pdfs/Ethics/CodeofEthics/Code-2007-July.pdf. Consider making a list of things you absolutely will never do. Then you can refer back to it in the future, when you’re wondering if a particular choice is the ethical one. This can be surprisingly effective in keeping you on the high moral ground.

Protecting the Creative Process

In his book Creativity, Inc., Ed Catmull, president of Pixar Animation and Disney Animation, describes the project management techniques that brought to life animation classics like Toy Story and The Incredibles. It all comes down to embracing the risks and uncertainties that allow true creativity to flourish:

There are many blocks to creativity, but there are active steps we can take to protect the creative process…. The most compelling mechanisms to me are those that deal with uncertainty, instability, lack of candor, and the things we cannot see. I believe the best managers acknowledge and make room for what they do not know—not just because humility is a virtue but because until one adopts that mindset, the most striking breakthroughs cannot occur. I believe that managers must loosen the controls, not tighten them. They must accept risk; they must trust the people they work with and strive to clear the path for them; and always, they must pay attention to and engage with anything that creates fear. Moreover, successful leaders embrace the reality that their models may be wrong or incomplete. Only when we admit what we don’t know can we ever hope to learn it. (2014, xv-xvi)

It might seem obvious that creativity is essential to entertainment companies like Pixar and Disney. But Catmull argues that protecting the creative process is essential in all types of organizations. He encourages managers to actively safeguard their teams’ creative abilities, thereby creating a safe space for team members to take risks, by doing the following:

- Create a flat communication structure in which any person in the organization can talk to any other person, without regard to rank in the larger organizational structure. And strive for candor in project discussions. “Candor is forthrightness or frankness…. The word communicates not just truth-telling but a lack of reserve…. A hallmark of a healthy creative culture is that its people feel free to share ideas, opinions, and criticisms. Lack of candor, if unchecked, ultimately leads to dysfunctional environments” (2014, 86).

- Constantly look for hidden problems, and don’t fall for the false notion that monitoring data can point out every possible issue. “‘You can’t manage what you can’t measure’ is a maxim that is taught and believed by many in both business and education sectors. But in fact, the phrase is ridiculous—something said by people who are unaware of how much is hidden. A large portion of what we manage can’t be measured, and not realizing this has unintended consequences. The problem comes when people think that data paints a full picture, leading them to ignore what they can’t see. Here’s my approach: Measure what you can, evaluate what you measure, and appreciate that you cannot measure the vast majority of what you do”(2014, 219-220).

14.7 Practical Tips for Organizational Development

Here are some ideas to help you help your company mature into a more effective organization:

- Model good behavior: Lead the way by modeling the practices you would like to see adopted throughout your organization. Start within your immediate circle of influence—the individuals you work with on a daily basis, the teams you belong to. Good ideas can be contagious, especially if people see them in practice and experience their benefits.

- Develop a shared vision: Collaborate with like-minded and motivated colleagues in your organization to develop a plan for leading project management growth within your organization. Stay focused on changes that will deliver value, not processes that are ends in themselves.

- Apply what you’ve learned about living order: Think about what you’ve learned in this course and make a list of ways you can use your new understanding of managing projects in living order to benefit your organization. Add this to your “key take-aways” for periodic review.

- Compare your organization to other organizations: People often complain about their jobs, implying that no one does anything right. But that’s rarely true. Benchmark organizations that are similar to yours. How does your organization compare? You may find that your organization actually does many things better than the competition. If that’s the case, use your insights into your organization’s strengths as an impetus to improve in those areas even more. Learning from others outside your industry is another way to grow as an organization. Project management is a key skill that is used across different end markets, products, and processes.

- Be mindful of the needs of your specific type of organization: Every organization is in a different stage of its development. A new start-up has different needs from an established company in a key industry. If you go to work for a new organization, you might find that basic project management processes and tools are nonexistent or immature. Indeed, entrepreneurs sometimes pride themselves on building hyper-flexible organizations in which fixed procedures and processes have no place. But as Wanda Curlee argues, “processes and procedures are not the antithesis of entrepreneurship and flexibility. In fact, project, program, and portfolio management can help a startup manage growth” (2015). You can read her complete article on the topic of startups and project management here: https://www.projectmanagement.com/blog-post/12961/Startups-and-Project-Management–They-Aren-t-Opposites.

- Don’t focus on one project maturity model too early: Review multiple models for project maturity development. Compare their visions of project maturity, identify areas of growth that would improve your organization’s ability to consistently deliver successful project results.

- Experiment: Learning through small experiments allows trial and error without significant negative repercussions. Piloting ideas for a project is one way to experiment.

~Summary

- Personal and organizational development are processes of transformation—change that makes a person a more effective project manager, change that makes an organization a more successful company.

- All organizational and personal change starts with learning. According to Daniel H. Kim, learning is a process of accumulating both know-how and know-why.

- The term project management maturity refers to the “progressive development of an enterprise-wide project management approach, methodology, strategy, and decision-making process. The appropriate level of maturity will vary for each organization based on its specific goals, strategies, resource capabilities, scope, and needs” (PMSolutions 2012). A great many models and assessment tools have been created to measure project management maturity in every industry. Vital elements of project management maturity include a good knowledge management system and a culture that values learning at all levels.

- Thin sustainability views financial capital and natural capital (that is, natural resources) as equally important. Thick sustainability takes a harder line, viewing any diminution of natural capital as unacceptable (Vos 2007).

~Glossary

- Capability Maturity Model (CMM)—The first widely used maturity model, developed in the software industry in the late 1980’s by the Software Engineering Institute (SEI) at Carnegie Mellon University and the United States Department of Defense.

- knowledge management—The “planning, organizing, motivating, and controlling of people, processes, and systems in the organization to ensure that its knowledge-related assets are improved and effectively employed” (King 2009).

- learning—“Increasing one’s capacity to take effective action” (Kim 1993).

- learning organization—According to David A. Garvin, “an organization skilled at creating, acquiring, and transferring knowledge, and at modifying its behavior to reflect new knowledge and insights” (1993).

- mindfulness—A state of nonjudgmental awareness.

- organizational learning—The process of retaining, storing, and sharing knowledge within an organization. More than merely the sum of the knowledge of all the members of the organization, achieving organizational knowledge “requires systematic integration and collective interpretation of new knowledge that leads to collective action and involves risk taking as experimentation” (Business Dictionary).

- Organizational Project Management Maturity Model (OPM3)— The most widely recognized maturity model, developed by the Project Management Institute. The OPM3 is designed to help an organization support its organizational strategy from the project level on up through the portfolio and program levels.

- project management maturity—The “progressive development of an enterprise-wide project management approach, methodology, strategy, and decision-making process. The appropriate level of maturity will vary for each organization based on its specific goals, strategies, resource capabilities, scope, and needs” (PMSolutions 2012).

- project maturity model—A set of developmental stages that can be used to evaluate an organization’s state of maturity in a particular domain.

~References

Becker, Jorg, Ralf Knackstedt, and Jens Poppelbuss. 2009. “Developing Maturity Models for IT Management: A Procedural Model and its Applications.” Business & Information Systems Engineering 1 (3): 213-222. doi:10.1007/s12599-009-0044-5.

Ben-Hur, Shlomo, Bernard Jaworski, and David Gray. 2015. “Aligning Corporate Learning with Strategy.” MITSloan Management Review Fall 2015. http://sloanreview.mit.edu/article/aligning-corporate-learning-with-strategy/?use_credit=688d7d9df0f0255d120a667a2c469f8a.

Business Dictionary. n.d. “Organizational Learning.” BusinessDictionary.com. Inc. WebFinance. http://www.businessdictionary.com/definition/resource-management.html.

Catmull, Ed, and Amy Wallace. 2014. Creativity, Inc. New York: Random House.

Curlee, Wanda. 2015. “Startups and Project Management: They Aren’t Opposites.” PM. April 23. https://www.projectmanagement.com/blog-post/12961/Startups-and-Project-Management–They-Aren-t-Opposites.

Garvin, David A. 1993. “Building a Learning Organization.” Harvard Business Review July-August. https://hbr.org/1993/07/building-a-learning-organization.

Gino, Francesca, and Bradley Staats. 2015. “Why Organizations Don’t Learn.” Harvard Business Review November. https://hbr.org/2015/11/why-organizations-dont-learn.

Haque, Umair. 2011. The New Capitalist Manifesto: Building a Disruptively Better Business. Cambridge: Harvard Business Review Press.

Kim, Daniel H. 1993. “The Link between Individual and Organizational Learning.” MITSloan Management Review Fall 1993. http://sloanreview.mit.edu/article/the-link-between-individual-and-organizational-learning/?use_credit=98b418276d571e623651fc1d471c7811.

King, William R. 2009. “Knowledge Management and Organizational Learning.” Edited by William R. King. Annals of Information Systems (Springer) 4: 3-14.

Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects. New York: Palgrave Macmillan.

Lean Enterprise Institute. 2014. Lean Lexicon, Fifth Edition. Edited by Chet Marchwinski. Cambridge, MA: Lean Enterprise Institute.

Little, Terry. 2004. “Meaningful Mentorship.” Ask Magazine, 20-21.

Morgan W. McCall, Jr. 1998. High Flyers: Developing the Next Generation of Leaders. Boston: Harvard Business School Press.

Mucha, Michael, interview by Ann Shaffer. 2017. Technical and Adaptive Problems (December 11).

PMSolutions. 2012. “What is project management maturity?” PMSolutions. August 16. http://www.pmsolutions.com/resources/view/what-is-project-management-maturity/.

Rouse, Margaret. 2007. “Capability Maturity Model (CMM).” TechTarget. April. http://searchsoftwarequality.techtarget.com/definition/Capability-Maturity-Model.

Select Business Solutions. n.d. “What is the Capability Maturity Model? (CMM).” Select Business Solutions. Accessed July 1, 2018. http://www.selectbs.com/process-maturity/what-is-the-capability-maturity-model.

Slater, Robert. 1998. Jack Welch & The G.E. Way: Management Insights and Leadership.

Sopko, Joseph A. 2015. “Organizational Project Management: Why Build and Improve?” Project Management Institute. http://www.pmi.org/~/media/PDF/learning/organizational-project-management-build-improve.ashx.

Varma, Ashwini, interview by Craig Lee. 2018. Becoming an Effective Project Manager (September 27).

Vorne. n.d. “Kaizen.” LeanProduction. Accessed July 1, 2016. http://www.leanproduction.com/kaizen.html.

Vos, Robert O. 2007. “Perspective: Defining sustainability: a conceptual orientation.” Journal of Chemical Technology and Biotechnology 82 (4): 334-339. doi:https://onlinelibrary.wiley.com/doi/abs/10.1002/jctb.1675.

Wallace, Bill. 2005. Becoming Part of the Solution: The Engineers Guide to Sustainable Development. Washington, D.C.: American Council of Engineering Companies.

15

Putting It All Together

The problem is not that there are problems. The problem is expecting otherwise and thinking that having problems is a problem.

—Theodore Rubin,

American psychiatrist and author

Objectives

After reading this lesson, you will be able to

- List some new practices for project management based on the first fourteen lessons in this book

- Discuss James March’s ideas on thinking like a poet to become a better project manager

- Explain the difference between event-driven and intention-driven project management

- Get started creating your own professional development plan

The Big Ideas In this Lesson

- As you look to the future, keep in mind that a living order approach to personal development focuses on lifelong learning, rather than understanding only what you need to know to master the current situation.

- A poet’s ability to interpret events, and to tell other people what they mean, is extremely useful in living order, where unexpected events unfold every day, unforeseen by even the most carefully constructed project plan.

- After formulating an interpretation of events, project managers must come up with a solution, circling back to revise their interpretation of the situation as necessary.

- The event-driven nature of project management, which can pull your attention in a dozen different directions at once, can leave little time and energy for planning and acting on your long-term career goals. It’s essential to take time to plan your professional development.

15.1 Reassess and Plan for the Future

This last lesson is an opportunity for you to look back at your understanding of project management at the beginning of this book; assess how your abilities align with your new, expanded conception of project management; and develop a plan for incorporating these new ideas and practices into your work. In other words, this is an opportunity to plan for change. A short list of new practices for readers of this book might include

- Recognize when a geometric order approach is useful in a project, and when a more flexible, living order approach is best

- Look for opportunities to incorporate Lean or Agile principles into your projects

- Make decisions about new projects in relation to your organization’s overall project portfolio

- Identify what makes a particular project successful, with a focus on the customer’s definition of value, and communicate that to all stakeholders.

- Limit the amount of detail in a project plan and schedule to the amount required to effectively guide the project team

- Be prepared to adapt and improvise in fast-changing situations, rather than attempting to stick to a plan that is no longer relevant

- Employ monitoring and control strategies that provide the right amount of information, targeted to the people who need that information to make on-going decisions about the project

- Regularly conduct project-review and project-closure activities, so as to keep current projects on track and retain vital information for future projects

- Take advantage of learning opportunities wherever they arise throughout your career

As you have read throughout this book, these are all important and effective ways of keeping projects on-track and headed toward success in the unpredictable, living-order conditions of the modern world. Hopefully, you have already begun changing your approach to project management to incorporate some or all of these practices. You might also hope to lead your entire organization toward some essential changes as well. So, let’s take some time to think about the nature of change and the mind-expanding possibilities of new ideas. It all starts with seeing the world differently.

15.2 Technical Project Manager as Plumber and Poet

In his novel 1984, George Orwell describes a dystopian state in which human thought is controlled by Newspeak, the state’s official language, which citizens are forced to adopt. Because Newspeak lacks words like “freedom” and “justice,” thoughts about such things gradually become “literally unthinkable, at least so far as thought is dependent on words…. Newspeak was designed not to extend but to diminish the range of thought, and this purpose was indirectly assisted by cutting the choice of words down to a minimum” (Orwell). By restricting the ability of citizens to think thoughts that might upset the current state of affairs, the government is able to prevent revolution from taking root.

In his novel, Orwell is making points about the nature of repressive political states. But he’s also commenting on the power of any organization to restrict the way its members think by controlling the official terminology and sanctioned procedures for getting things done. In any large organization, giving an honest assessment of any situation can be exceedingly difficult, especially when the organization itself wants you to see things differently. In an interview with the Harvard Business Review, James March, one of the seminal scholars and thinkers on organizational theory, describes the predicament of astute modern managers, who perceive uncertainty all around, but are compelled by the pressures of organizational thinking to blind themselves to that reality:

The rhetoric of management requires managers to pretend that things are clear, that everything is straightforward. Often, they know that managerial life is more ambiguous and contradictory than that, but they can’t say it. They see their role as relieving people of ambiguities and uncertainties. They need some way of speaking the rhetoric of managerial clarity while recognizing the reality of managerial confusion and ambivalence. (Coutu 2006)

In a collection of his lectures, James March explains that to avoid this kind of self-imposed blindness, managers need to combine their natural plumber’s tendency—the tendency to zero in on problems and fix them—with the poet’s bold, creative approach to the world:

There are two essential dimensions of leadership: “plumbing,” i.e., the capacity to apply known techniques effectively, and “poetry,” which draws on a leader’s great actions and identity and pushes him or her to explore unexpected avenues, discover interesting meanings, and approach life with enthusiasm.

The plumbing of leadership involves keeping watch over an organization’s efficiency in everyday tasks, such as making sure the toilets work and that there is somebody to answer the telephone. This requires competence, not only at the top but also throughout all the parts of the organization; a capacity to master the context (which supposes that the individuals demonstrating their competence are thoroughly familiar with the ins and outs of the organization); a capacity to take initiatives based on delegation and follow-up; a sense of community shared by all members of the organization, who feel they are “all in the same boat” and trust and help each other; and, finally, an unobtrusive method for coordination, with each person understanding his or her role sufficiently well to be able to integrate into the overall process and make constant adjustments to it….

Leadership also requires, however, the gifts of a poet, in order to find meaning in action and render life attractive. The formulation and dissemination of interesting interpretations of reality form the basis for constructive collective action…. Words allow us to forge visions, and poetic language, through its evocative power, allows us to say more than we know, to teach more than we understand. (March and Weil 2005)

Thinking like a poet opens the door to the kind of personal change that will make you a better project manager. At the same time, thinking like a poet will give you the ability to inspire change in your organization. As you’ll see in the next section, a poet’s ability to interpret events, and to tell other people what they mean, is extremely useful in living order, where unexpected events unfold every day, unforeseen by even the most carefully constructed project plan.

You Already Think Like a Poet

James March has suggested that managers could benefit from reading poetry, which forces readers to marshal their powers of interpretation, looking for multiple layers of meaning in any one word (Coutu 2006). But whether or not you are interested in reading poetry, you should at least be aware that living order is ultimately a poetic idea, developed by the French philosopher Henri Bergson. When he first used the term, in his book Creative Evolution, Bergson was talking about the artistic process, which appears chaotic from the outside, but can produce works of extraordinary order and complexity (1911). Living order is a complicated idea, and at first blush it doesn’t even make sense. How can order be alive? What does that mean? Hopefully, after fourteen lessons, you do have a sense of what it means. You probably even feel comfortable using the term “living order” to identify certain phenomena in your professional life. That is, you reinterpreted two English words—“living” and “order”—and, as a result, internalized a new understanding of the world. In other words, you have begun thinking like a poet.

15.3 Event-Driven and Intention-Driven Project Management

As an engineer, you are probably inclined toward the plumbing tasks associated with leadership. After all, almost by definition, engineers like to fix things. And you might think that the poet part of the equation is something entirely new to you. But the work of Swedish researchers Ingalill Holmberg and Mats Tyrstrup suggests that employing a poet’s interpretive skills—that is, looking at a situation and telling other people what it means—is something good managers do every day. You probably have more experience at it than you think.

Holmberg and Tyrstrup developed their theory when studying everyday leadership—that is, the decisions and activities that take up the vast majority of a manager’s time. In interviews with managers at TECO, the Swedish international telecom company, they found that only 10% of projects were completed in the traditional, geometric way, with events unfolding according to plan. Another 20% are driven by a manager who saw himself or herself as heroic for solving unexpected problems and forcing the project to unfold as originally planned. The researchers noted that managers especially loved to describe a project as “a story of heroic feats.” They explain that

many managers tend to describe their efforts according to this model. They begin with a challenging problem (which, by the way, is much bigger than initially expected). A process follows that includes many difficult turns. Knotty problems arise, and at times everything looks bleak—very bleak indeed. But the competent manager has a basic agenda consisting of a number of stages to follow and steps to take. In hindsight, it can be claimed that the whole process has gone according to plan and a successful conclusion has been reached. (54)

Managers who describe their successes in this way tend to think leadership is largely a matter of knowing “today what should be done tomorrow in order to reach the desired results” (54). In other words, they see projects as intention-driven. They believe that a heroic manager with clearly defined intentions can make anything happen.

But according to Holmberg and Tyrstrup, managers who view themselves in this heroic light are deceiving themselves, because the vast majority of a manager’s time is spent on problems that nobody did or could expect. The researchers call these “Well then—what now?” situations. They argue that almost all of a manager’s time is spent trying to answer that question—and not because things were poorly planned at the outset, but because that’s just how things work in a complicated organizational setting. As much as heroically-inclined managers would like to believe that their own intentions are the most powerful force in any project, in reality projects are nearly always event-driven, with managers forced to respond to changing situations from day to day. “Either something unexpected happens, or what was expected to happen does not” (58).

Using a Time Management Quadrant

As you turn your attention from one “Well then—what now?” situation to another, it’s easy to lose track of priorities. In particular, you might fail to leave time for the large-scale, sense-making thinking required to keep a project on track over the long term. In The 7 Habits of Highly Effective People, Stephen Covey recommends using a time management quadrant, like the one shown in Figure 15-1. Make a diagram like this, and then keep track of how you spend your time, writing each activity into the appropriate quadrant (Covey 1989).

Figure 15-1: Time management quadrant

People tend to spend most of their time on Quadrants I and III, neglecting Quadrant II. Thus, long term planning and sense-making (which are not urgent but very important) tend to fall by the wayside. For some suggestions on how to use a time management quadrant to eliminate pointless, Quadrant IV tasks from your work life in order to focus more on the essential Quadrant II tasks, see this helpful article: https://www.usgs.gov/media/files/time-management-grid.

Holmberg and Tyrstrup describe a “Well then—what now?” project as follows:

You find yourself in a problematic situation, working hard and wrestling with the issues as they appear, only to find you are constantly trying to grasp the situation. It is not at all certain how you got where you are or what the situation means. It is extremely difficult to assess how the situation fits with the intentions articulated a few days, a week, or a month ago. It is hard to tell what has been completed, what is still going on, or what is yet to be accomplished. People are constantly at your throat, asking for different instructions or directions. People higher up in the hierarchy, those lower down, and even those at the same level want information and reports that give the results of decisions taken and activities performed. One event seems to give rise to another according to a logic that is anything but obvious. As a manager, you are tired and need a break to go through your papers, emails, the heaps of files, and the phone messages in order to sort out your thoughts and feelings. (55)

In a situation like this, the manager’s main job is to interpret what’s going on—that is, make sense of the situation:

In each case, the manager had to interpret what had already happened in order to formulate what the next step should be. What was the significance of what had or hadn’t happened? How might these events and non-events be best explained, and what are their implications? (59)

After formulating an interpretation, managers must come up with a solution, circling back to revise their interpretation of the situation as necessary.

This brings us back to March’s idea that a leader is partly a plumber and partly a poet. A “Well then—what now?” problem can only be solved by a manager with a poet’s ability to interpret the situation, to see into the heart of the matter and explain to everyone else what’s going on. Then, acting like a plumber, the manager needs to figure out a way to solve the problem. Often, solving the problem also requires quite a bit of poetic creativity and vision.

Holmberg and Tyrstrup conclude their study with some practical suggestions designed to nudge large organizations away from the assumption that unexpected events can be prevented by more detailed planning, which can be extremely time-consuming and costly. Instead, they argue, organizations should focus on hiring managers who can deal with the unexpected. Their research implies that organizations should focus on “selecting managers who are prepared to give up unilateral control and instead to rely on the creativity inspired by improvised actions” (65). Likewise, management training, they argue, should focus on helping managers come up with creative solutions to the question “Well then—what now?”

As you look to your future as a technical project manager, be alert to your own tendency to see yourself as a hero in the midst of chaos. Instead, remember that resolving “Well then—what now?” situations is the main job of a project manager. You need to be able to deal with them creatively and with as little drama as possible.

Becoming an Expert Technical Project Manager: the 10,000 Hour Rule, Revised

You might have heard people talk about the 10,000 hours rule. As popularized by Malcolm Gladwell in his book Outliers, the rule holds that it takes 10,000 hours of practice to become an expert at anything, including project management. But according to Anders Ericsson, the psychologist whose research inspired the maxim, simply doing something over and over won’t lead to true expertise. Instead, you need to actively correct your performance to achieve real excellence. Maria Popova summarizes his findings:

The secret to continued improvement, it turns out, isn’t the amount of time invested but the quality of that time. It sounds simple and obvious enough, and yet so much of both our formal education and the informal ways in which we go about pursuing success in skill-based fields is built around the premise of sheer time investment. Instead, the factor Ericsson and other psychologists have identified as the main predictor of success is deliberate practice—persistent training to which you give your full concentration rather than just your time, often guided by a skilled expert, coach, or mentor. (n.d.)

So, to become an expert technical project manager, you need to invest time in constant learning and training. But you need to do this with an active attention toward self-improvement. To avoid “ceasing to grow and stalling at proficiency level … you need to continually shift away from autopilot and back into active, corrective attention” (Popova).

You can read Popova’s excellent summary of the latest research on the 10,000 hours rule here: https://www.brainpickings.org/2014/01/22/daniel-goleman-focus-10000-hours-myth/. And while you’re at it, consider subscribing to her email newsletter, which explores a huge variety of topics related to culture, history, and art. It’s a wonderful way to learn about issues that lie beyond the boundaries of the engineering world, making it an excellent professional development resource. Reading regularly will ensure that you’re familiar with all the big topics currently circulating in the culture. You can subscribe here: https://www.brainpickings.org/newsletter/

15.4 Creating a Professional Development Plan

This 12-minute video provides a helpful introduction to the process of creating a professional development plan: https://www.youtube.com/watch?v=PRZcstlx6KQ .

In this book, you’ve learned about the importance of planning to ensure a technical project’s success. The same is true of your career. Unfortunately, the event-driven nature of project management, which can pull your attention in a dozen different directions at once, can leave little time and energy for planning and acting on your long-term career goals. As a result, some project managers end up moving from one job to another with no real plan in mind. In other words, they fall into the trap of tolerating an event-driven series of positions at various organizations, rather than insisting on an intention-driven, goal-oriented career. The first step in taking control of your career is creating a professional development plan(PDP), which is a document that describes

1. Your current standing in your field, including a brutally honest assessment of your strengths and weaknesses. Use the Project Management Self-Assessment form provided in Figure 15-2 to begin holding yourself to account.

2. Your short- and long-term career goals. Creating a list of goals typically involves a fair amount of research, so that you can be sure you fully understand the options available to you.

3. A plan for achieving your goals that includes specific deadlines. Again, this part of your professional development plan will require some research, so that you fully understand the best possible ways to achieve your goals. For example, you might want to investigate useful certifications or professional conferences.

Figure 15-2: Project Management Self-Assessment

Download Figure 15-2 in PDF form

To create a meaningful development plan, you also need to engage a trusted mentor and perhaps a few valued colleagues. Connect with people who are willing to share experiences with you, who understand the big picture, and who can give you honest assessments of your strengths and weaknesses. Definitely take advantage of any formal mentorship programs available through your organization or in your field. However, according to Terry Little in Becoming a Project Manager, you are likely to get the best results through more informal mentoring arrangements with willing senior employees. It’s possible a senior manager who takes mentoring seriously will approach you about establishing a mentor/mentee relationship, but if that doesn’t happen, don’t be afraid to seek out your own mentors. But what makes a good mentoring relationship? According to Little, the following principles are a good foundation:

1. Mentors must be willing to spend time doing it.

2. Mentees must be willing to learn.

3. Mentoring is everyone’s responsibility, not just the responsibility of those in senior positions.

4. Advice to mentees should be predictable and personal.

5. With any position you hold, your behavior should be worthy of emulation. (2018)

No matter how much work you and your mentor put into your professional development plan, the plan is only useful if you actually monitor your progress in achieving your goals and take the time to update the plan throughout your career. Whereas projects are team efforts involving collaboration among many parties, your professional development is entirely your responsibility. In an article for Forbes, Chrissy Scivicque emphasizes that while your organization’s human resources department might help you create a plan, executing it successfully is really up to you:

Your professional development is not the responsibility of anyone but you. Not your company, not your boss, not even your coach. Just you.

Some companies try to help with the process by helping employees create professional development plans (PDP) as part of the performance review process. While it’s a nice gesture, it simply isn’t very useful for the vast majority of employees.

In my experience, I’ve found that a PDP created at the behest of an employer is often an exercise for management, not the employee. In fact, if the employee will later be judged on that criteria, he or she actually feels encouraged to aim low so as not to be set up for future failure. For those who happen to have bigger goals that don’t involve working for the company, the PDP is pretty meaningless. The employee ends up playing a game, telling the manager what he wants to hear and not using the plan to facilitate real, desired professional growth.

Even if your company helps you develop a plan, it’s always a smart idea to create one of your own in private. This will help you identify and take action on growing the skills needed to achieve your true long-term career goals, whether or not they involve your current company. (2011)

In her article, Scivicque also emphasizes that a professional development plan is only useful if you revise it regularly to reflect new opportunities and challenges, as well as your own changing aspirations. You can read her complete article here: http://www.forbes.com/sites/work-in-progress/2011/06/21/creating-your-professional-development-plan-3-surprising-truths/#5cd14a4627bb.

Experience, Reflection, and Mentoring

In their book Becoming a Project Leader, Alexander Laufer, Terry Little, Jeffrey Russell, and Bruce Maas provide real-life case studies of people struggling with and growing into the role of project manager. They explain that “the large sample of project managers we studied did not become successful due to intensive and formal classroom education. Rather, the primary means for their development was on-the-job learning” (109). According to their research, the three most important avenues for this vital form of learning are pursuing challenging tasks to gain experience, working with a mentor, and learning through communities of practice. “Project managers develop as successful leaders by employing a variety of practices which are from bottom to top (the project manager tackling challenging tasks and affecting the organization), top to bottom (mentoring), and across the organization (community of practice)…. If an organization is to grow and weather the inevitable ups and downs it will face in a dynamic environment, professional development is essential” (127).

One of the great benefits of taking part in a community of practice is that it offers a low-pressure setting in which people can talk about their work, usually in the form of stories. The ability of stories to transfer knowledge and wisdom among people cannot be overemphasized. “People love to read stories because they attract and captivate, can convey a rich message in a non-threatening manner, and are memorable. Stories are thus the most effective learning tool at our disposal, especially in situations where the prospective learner suffers from a lack of time—which is the case for most project managers” (Laufer et al. 2018, 121-122).

All of these professional development tactics draw on the 70/20/10 model for learning and development, which holds that 70% of learning comes from challenging assignments, 20% comes from relationships with coworkers including mentors and communities of practice, and 10% from formal training. You can learn more about the 70/20/10 model here: https://trainingindustry.com/wiki/content-development/the-702010-model-for-learning-and-development/.

15.5 The Future of Technical Project Management

One important part of planning for your professional development is keeping an eye on trends that will shape technical project management in the coming years. Technological advances, expanding globalization, and new communication and data systems will all change how technical project managers do their jobs. Here’s a summary of emerging trends, along with links for more information:

- Data analytics: Businesses are increasingly collecting mountains of data on quality assurance testing, customer behaviors and preferences, in-field equipment performance, warranty claims, and so on. These data can drive the justification for projects, help to focus project efforts, and inform project progress. Project managers will need to cultivate their ability to extract meaningful information from otherwise overwhelming stores of data, and then use that information to make crucial decisions and to shape day-to-day project management. These articles explain how to use data analytics to improve project outcomes:

- https://www.clarizen.com/data-analytics-can-improve-project-outcomes/

- https://www.cio.com/article/3182352/project-management/how-to-use-data-analytics-to-improve-project-outcomes.html.

- Business Agile: The Agile development model has leapt over the borders of IT projects into the larger world. Companies are now incorporating Agile principles into “the whole of a company’s function,” with massive implications for how business decisions are made and plans are executed (Burger, Business Agile and the Future of Project Management 2017). Among other innovations, this new approach to business emphasizes continuous learning, information-sharing among departments, and incentives that “support measuring outcomes, making evidence-based decisions, and learning” (Gothelf 2014). Read this blog post for an in-depth look at the implications of business Agile: https://blog.capterra.com/business-agile-and-the-future-of-project-management/. This article from the Harvard Business Review makes the case for weaving Agile-thinking into everything a company does: https://hbr.org/2014/11/bring-agile-to-the-whole-organization. The website for the Agile Business Consortium is an excellent source of resources on the topic: https://www.agilebusiness.org/business-agility.

- Diversity initiatives: According to Rachel Burger, the world of project management has been slow to make hiring a diverse group of employees a priority, even while other fields have been making major strides in this area. But a trend toward diversity “is trickling in from the business community and the political climate as a whole.” As a result, project managers can expect to hear more about the need for diverse teams—that is, teams that include an equal number of men and women, with representation from as many races, cultures, sexual orientations and religions as possible, and built-in measures for accommodating disabilities. But these changes will not occur in a vacuum. You should expect lots of arguments about the best way to proceed. Burger advises project managers to “take advantage of new community offerings about diversity and inclusiveness, and get ready for industry-level conflicts about people management in regards to ability, age, ethnicity, gender, race, religion, sexual orientation, and class” (2017). You’ve read about the benefits of having a diverse team in Lesson 5. This article summarizes these benefits: https://www.liquidplanner.com/blog/the-new-secret-to-successful-teams-diversity/. This article from PMI explains how to overcome misunderstandings that can arise on multicultural teams: https://www.pmi.org/learning/library/dealing-cultural-diversity-project-management-129.

- The internet of things and artificial intelligence: Advances in technology will affect every business in the world, one way or another (Burger 2017). This is definitely true of the internet of things (IoT), which is the “system of interrelated computing devices, mechanical and digital machines, objects, animals or people that are provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction” (TechTarget n.d.). This article by Anna Johansson describes the many ways IoT has and will continue to change modern business: https://www.huffingtonpost.com/anna-johansson/8-ways-the-internet-of-th_b_11763836.html. You probably already have experience with forms of artificial intelligence (AI) such as Amazon’s Alexa, or the Apple’s Siri. But these automated personal assistants are just the tip of the iceberg. This article describes ways that AI will change business and how leaders will need to adapt: https://hbr.org/2020/03/ai-is-changing-work-and-leaders-need-to-adapt.

- Globalization: The Levin institute at the State University of New York (SUNY) defines globalization as “a process of interaction and integration among the people, companies, and governments of different nations, a process driven by international trade and investment and aided by information technology. This process has effects on the environment, on culture, on political systems, on economic development and prosperity, and on human physical well-being in societies around the world” (The Levin Institute n.d.). Globalization has already had a profound effect on the way the world does and will continue to do business in myriad ways. In a NASA roundtable discussion, Greg Balestrero discussed the effects of globalization on the supply chain: “It’s very difficult to think of any company or organization that doesn’t feel the pressures and the implications of globalization on the supply chain. And it’s an intellectual supply chain as well as a physical supply chain. The global supply chain is a growing issue…. With globalization comes a challenge of having a common framework and understanding—as simple as a lexicon, as complicated as a common process—for project and program management” (APPEL News Staff 2007). You can learn more about this essential topic at www.globalization101.org, a website maintained by the Levin Institute.

Other issues that will continue to have a huge effect on technical project management in the coming years include

- Lean and Agile: According to expert John Shook, despite almost two decades of effort, the construction industry is only in the early stages of effectively implementing Lean principles in all phases of construction (Wiegand 2016). Likewise, IT professionals still face many challenges in their quest to take advantage of Agile principles and practices in an organizationally appropriate and effective manner.

- Emerging technology: An article in Engineering News-Record describes the use of hologram headsets that allow a worker to see a 3D model of what she needs to build directly on site, making it possible to begin assembling part of a building without even referring to a tape measurer (Rubenstone 2016). This is just one example of the fast-moving technological changes that will affect your work as a technical project manager in the near future.

- Partnerships: As the tendency toward globally interconnected businesses intensifies, formal international business partnerships will become the norm rather than the exception. To successfully manage projects that span multiple countries, you’ll need to focus on your cross-cultural competencies, making sure you are prepared to interact with people from all over the world.

~Practical Tips

This set of practical tips summarizes the advice you’ve read in earlier lessons. To help promote an understanding of the role of geometric and living order in your organization’s projects, consider printing this list and posting it somewhere where your colleagues and project stakeholders can easily read it. And be ready to discuss these ideas with anyone who asks about them.

- Throughout a project, recognize the tension that exists between geometric and living order, and avoid imposing a geometric process on a situation that requires a more flexible, living order approach.

- Put as much effort as you possibly can into starting a project well because the way you start a project has a big impact on how you finish.

- In all stages of a project, take time to remind stakeholders how the customer perceives the project’s value. Make sure everyone involved can clearly articulate the customer’s definition of the project’s value.

- Continually work toward building a functional, collaborative team. Don’t waste time trying to achieve the impossibility of a perfect team.

- Do all you can to make sure all project stakeholders understand the definition of project success.

- Use the planning part of any project as an opportunity for thinking and collaboration. Focus less on the plan itself and more on starting the dialogue with all stakeholders.

- Do not let a project evolve without continually referring to and connecting back to your organization’s overall strategy. At every stage of planning and executing a project, incorporate strategic thinking.

- In all procurement-related tasks, focus on best value rather than least initial cost.

- Use the scheduling part of any project as an opportunity to think about project tasks at varying levels of detail, and as an opportunity to communicate with stakeholders about the best way to achieve project success.

- Don’t shy away from confronting the uncertainty in any project. Only by understanding the many forms of uncertainty associated with a project can you understand the degree of risk involved.

- Accept the fact that resources are usually scarce and constrained, and use your project management skills to use those scarce and constrained resources effectively.

- In a dynamic, changeable environment, move beyond the traditional view of monitoring and control, which emphasizes gathering data about the past, and instead adopt a pull approach to monitoring and control, which emphasizes data about the current time and the immediate future.

Finally, here are some concluding practical tips on management and leadership, adapted from the work of Alexander Laufer, whose book Mastering the Leadership Role in Project Management (2012) has provided a wealth of inspiration for these lessons.

- Always keep the context in mind: Principles and practices must be modified to fit the context of a project situation.

- Adapt when necessary, instead of attempting to control everything: Projects are plagued with questions and problems. A successful manager has the flexibility to adapt as necessary to address these matters and not simply strive to control them.

- Be prepared to manage and lead: In some ways, a technical project requires the same combination of management and leadership as driving a car. You need to remain aware of everything going on with the controls on the dashboard (management) while at the same time looking out the windshield to make sure you reach your destination (leadership).

- Be prepared for a shift from living order to geometric order, once things get going: Many projects start in living order (and a high degree of uncertainty) and transition to geometric order.

- Don’t forget the beauty of AND: Project management often involves combining two different activities or ways of thinking about a project, such as leadership AND management, stability AND flexibility, processes AND practices, thinking AND doing.

- Look for ways to collaborate at all times: The primary role of a project manager is to build collaboration, interdependence, and trust among the project stakeholders.

- Think of yourself as a problem solver: Successful project managers develop expertise in problem identification and solving.

- Remember, everything you do or learn adds to your wealth of knowledge and experience: Seek out new ways to add to your practical experience and overall knowledge. Job assignments are one obvious way to do this, but don’t forget other options, such as mentoring relationships, and stories told by your colleagues about past projects.

~Summary

- New project management practices for readers of this book include recognizing when a geometric order approach is best and when a living order approach is best, being prepared to adapt and improvise, and limiting the amount of detail in a project plan and schedule to the amount required to effectively guide the project team.

- According to James March, an effective leader knows how to work like a plumber, by “keeping watch over an organization’s efficiency in everyday tasks,” and also like a poet, who strives to “explore unexpected avenues, discover interesting meanings, and approach life with enthusiasm” (March and Weil 2005).

- Many managers think leadership is largely a matter of knowing “today what should be done tomorrow in order to reach the desired results” (Holmberg and Tyrstrup 2012, 54). In other words, they see projects as intention-driven. But according to Swedish researchers Ingalill Holmberg and Mats Tyrstrup, managers who view themselves in this heroic light are deceiving themselves, because the vast majority of a manager’s time is spent on problems that nobody did or could expect. In other words, projects are nearly always event-driven, with managers forced to respond to changing situations from day to day (58).

- The first step in taking control of your career is creating a professional development plan (PDP), which is a document that describes your current standing in your field, your short- and long-term career goals, and a plan for achieving your goals, including specific deadlines.

~Glossary

- event-driven—Term used to describe a project that unfolds in response to changing events.

- intention-driven—Term used to describe a project that unfolds according to the single-minded intention of the project manager.

- Internet of things (IoT) —The “system of interrelated computing devices, mechanical and digital machines, objects, animals or people that are provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction” (TechTarget n.d.).

- professional development plan (PDP)—A document that describes 1) your current standing in your field, including a brutally honest assessment of your strengths and weaknesses; 2) your short- and long-term career goals; and 3) a plan for achieving your goals that includes specific deadlines.

~References

APPEL News Staff. 2007. “What’s Ahead for Project Management: A Roundtable Discussion with PMI.” ASK OCE 2 (2). https://appel.nasa.gov/2010/02/27/ao_2-2_f_ahead-html/.

Bergson, Henri. 1911. “Creative Evolution.” Project Gutenberg. Accessed June 15, 2018. http://www.gutenberg.org/files/26163/26163-h/26163-h.htm.

Burger, Rachel. 2017. “Business Agile and the Future of Project Management.” Capterra Project Management Blog. August 14. https://blog.capterra.com/business-agile-and-the-future-of-project-management/.

—. 2017. “The 5 Biggest Project Management Trends Shaping 2018.” Capterra Project Management Blog. November 14. https://blog.capterra.com/the-5-biggest-project-management-trends-shaping-2018/.

Coutu, Diane. 2006. “Ideas as Art [an interview with James March].” Harvard Business Review, October. https://hbr.org/2006/10/ideas-as-art.

Covey, Stephen R. 1989. The 7 Habits of Highly Effective People. New York: Free Press.

Gothelf, Jeff. 2014. “Bring Agile to the Whole Organization.” Harvard Business Review, November 14. https://hbr.org/2014/11/bring-agile-to-the-whole-organization.

Holmberg, Ingalill, and Mats Tyrstrup. 2012. “Chapter 3: Managerial Leadership as Event-Driven Imrovisation.” In The Work of Managers: Towards a Theory of Management, by Stefan Tengblad, 47-68. Oxford: Oxford University Press.

Laufer, Alexander. 2012. Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results. Upper Saddle River: FT Press.

Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects. New York: Palgrave Macmillan.

March, James G., and Thierry Weil. 2005. On Leadership. Malden, MA: Blackwell Publishing.

Orwell, George. 1949. “1984: Appendix, The Principles of Newspeak.” George Orwell. Accessed December 11, 2016. http://orwell.ru/library/novels/1984/english/en_app.

Popova, Maria. n.d. “Debunking the Myth of the 10,000-Hours Rule: What it actually Takes to Reach Genius-Level Excellence.” BrainPickings. Accessed December 22, 2016. https://www.brainpickings.org/2014/01/22/daniel-goleman-focus-10000-hours-myth/.

Rubenstone, Jeff. 2016. “Mixing Reality on Site: Hologram Headsets Put 3D Models Front and Center.” Engineering News-Record, November 28/December 5: 20-24.

Scivicque, Chrissy. 2011. “Creating Your Professional Development Plan: 3 Surprising Truths.” Forbes, July 21. http://www.forbes.com/sites/work-in-progress/2011/06/21/creating-your-professional-development-plan-3-surprising-truths/#5cd14a4627bb.

TechTarget. n.d. “internet of things (IoT).” TechTarget. Accessed 17 2018, July. https://internetofthingsagenda.techtarget.com/definition/Internet-of-Things-IoT.

The Levin Institute. n.d. “What Is Globalization?” Globalization 101. Accessed July 17, 2018. http://www.globalization101.org/what-is-globalization/.

Wiegand, John. 2016. “Viewpoint: Construction Project Delivery, Dispelling Lean Myths.” Engineering News-Record, November 15.

1

Appendix A - Risk and a Changing Climate

I appreciate the invitation from the authors of Technical Project Management in Living and Geometric Order to prepare this appendix, which presents examples of risk and uncertainty faced in current civil infrastructure projects. This appendix is intended as a practical illustration of ideas presented in Lesson 8, “Managing Project Risks.”
— Larry Roth, Vice President, Arcadis I.S., Inc., and former Executive Vice President on the staff of the American Society of Civil Engineers

The Big Ideas in This Appendix

- Our changing climate will increase risk and uncertainty in the performance of civil infrastructure in ways that are difficult to predict.

- To be sustainable, infrastructure being designed today must be resilient and must be able to accommodate and adapt to environmental conditions in multiple futures that a changing climate could bring.

- Risk assessment and adaptive management are useful strategies for better understanding and adapting to risk in an uncertain future.

A.1 The Need to Adapt

Climate change has greatly increased the risk we face in planning, designing, and operating civil infrastructure. Much of this risk stems from new uncertainty in our ability to predict environmental conditions that will affect design and operation of infrastructure projects. For example, we already see significant changes in precipitation patterns and increased frequency of extreme weather-related events. Unfortunately, we don’t know enough about the far-reaching effects of climate change to be able to confidently predict future conditions, and to assume worst-case conditions may be foolhardy or wasteful. The following three project examples illustrate how climate change increases risk and uncertainty in civil infrastructure design and operation.

- A new seawall for a city on the west coast of the United States: In the late 1990s, a new seawall would be considered fit for use if it met the needs of stakeholders and the public and if it was resilient in the face of seismic loading from earthquakes. Today, it cannot be fit for use unless it’s also resilient to sea level rise. But how much sea level rise will occur during the useful life of the new seawall? In the past, we would have relied on published information to inform us of tidal variations. Also, we would have analyzed the probability of extreme tidal events and storm surges to guide our design. Today, we should first determine if a new seawall is the right option—retreat from the coast may be the best choice. If retreat is not an option, we must rely on our best data, models, and judgment to estimate the probable range of sea level rise, and as good stewards of infrastructure, we should ensure we can adapt our design to levels of sea level rise that may vary from our best estimates.

- A new water supply reservoir on the Texas Gulf Coast: Two decades ago, we would have relied on the existing hydrologic record to determine the safe yield of the reservoir and to size the reservoir’s spillway for safe operation. Today, the hydrologic record, no matter how long, nor how robust, represents a new starting point for a record that may be very different in the future due to climate change. We should ask, are there other options for water supply? If not, can we be sure that there will be enough water to fill the reservoir in future droughts brought about by a changing climate? Can we predict how climate change will affect extreme precipitation events and the ability of the spillway to safely pass floods? Relying on the existing hydrologic record alone may result in a reservoir that’s not fit for use, nor safe for operation. In a changing climate, we need to be able to adapt reservoir operation to changing conditions.

- A new building on Alaska’s North Slope: Two decades ago, for a new building on Alaska’s North Slope situated on permanently frozen muskeg, we would have designed a refrigerated foundation to prevent the building’s heat flow from thawing the supporting permafrost. Today, climate change threatens the permanence of permafrost. We should ask, how will our refrigerated foundation perform if the permafrost surrounding it is thawing because of a warming climate? Though refrigerated foundations were an innovative solution when first used, what kinds of creative solutions can we apply to a future disrupted by climate change? How can we ensure that our creative solutions today will be adaptable to conditions that may differ from our predictions?

These and other projects today clearly illustrate that climate change requires new approaches. In an opinion piece for the Engineering News-Record (ENR), William A. Wallace challenged engineers to develop infrastructure solutions that recognize the risk and uncertainty posed by a changing climate. To do that, he argues, engineers must rethink the foundational engineering assumption of stationarity, which presumes that “past environmental conditions are good predictors of future ones.” Until relatively recently, using past conditions to predict the future enabled engineers to “plan, design and deliver long-lived infrastructure, confident that projects would be safe, reliable, and efficient.” Climate change, however, has upset the apple cart. Wallace argues that engineers must embrace non-stationarity as “the new normal” because ”long-held engineering assumptions about environmental conditions are no longer reliable, so projects may not function the way they’re supposed to and can present a significant risk to public health, safety, and welfare” (Wallace 2018).

This is a big deal—past is no longer prologue. Risk and uncertainty have increased.

A.2 Non-Stationarity and Living Order

Stationarity is a geometric-order concept that presumes things remain unchanged over time. Non-stationarity, a profoundly living-order concept, presumes the opposite—that things change over time, sometimes rapidly and often in unpredictable ways. Managing a project based on non-stationarity is a living-order undertaking, requiring flexibility, adaptability, and creativity.

How can we learn to live in living order to best anticipate what climate change might bring? John Matthews of Conservation International says, “Let’s not just design for a single future; let’s think about multiple possible futures.” Because we cannot be sure which of the multiple futures climate change might bring, we must be able to adapt to the environmental conditions that develop during the useful life of the project. In other words, we must be able to react and adjust so that infrastructure remains safe and fit for use. The Federal Highway Administration (FHWA) offers guidance on adaptation strategies for multiple futures in its “Synthesis for Approaches for Addressing Resilience in Project Development” (2017). These strategies include the following:

- Manage and maintain: Ensure that infrastructure can be maintained by responding to extreme events through advanced preparation.

- Increase resiliency: Ensure the ability to recover quickly from difficulties or failure caused by extreme events.

- Increase redundancy: If a process or function can be interrupted by an extreme event, ensure that back-up systems or workarounds can continue operation.

- Protect: Use shields or shelters to reduce or eliminate damage caused by changing climate stressors.

- Accommodate: Build in the capacity to modify or redesign infrastructure to meet changing conditions in a climate-stressed environment.

- Relocate: Reduce exposure to climate stressors by relocating infrastructure; for example, retreat to higher ground to avoid the impacts of sea level rise on coastal infrastructure.

A.3 Managing Risk in Living Order

To address the living order challenge of climate change, we must evaluate adaptation strategies in our infrastructure projects to satisfy present-day budget constraints while maintaining the ability to adjust to conditions that differ from our best predictions made during design. Risk assessment is a useful tool to help us evaluate adaptation strategies for civil infrastructure; to tailor those strategies to meet our needs at a level of risk we find tolerable and acceptable; and to enable us to effectively communicate risk to stakeholders and the public. Recall from Lesson 8 that risk is the potential for loss or injury. Put simply:

Risk = Probability of an event x Consequences of that event.

To assess risk, we need to know:

- What is the current hazard or threat, and how likely is it to occur?

- How will climate change affect the nature and likelihood of hazards or threats in the future?

- Who and what are in harm’s way now and in the future?

- How will civil infrastructure perform in the face of the hazard, should it occur?

- How much harm will be caused if the civil infrastructure fails to perform adequately?

Under unchanging environmental conditions, or stationarity, risk assessment is sensitive to changes in input values; uncertainty associated with the input data and calculation models will affect the result. Non-stationarity associated with climate change introduces more knowledge uncertainty into the analysis, making it even more important to include both a sensitivity analysis and an uncertainty analysis in the risk assessment. A sensitivity analysis helps quantify the effects of small or large changes in input values on the result. An uncertainty analysis uses probabilistic methods to assess the level of confidence we can have in the result. For example, non-stationarity makes our estimates of the nature and likelihood of future hazards uncertain because of natural variability, and because we can only make rough estimates of how climate change will affect the types of hazards we will face and the probability of those hazards occurring. The goals of sensitivity and uncertainty analyses are 1) to understand how variations in input values affect the result; 2) to quantify the uncertainty in the result, and; 3) if possible, to identify which uncertain input values contribute most to total uncertainty

Two key definitions are essential to risk assessment:

- Residual risk: As we can never eliminate risk, residual risk is the risk that remains after considering the mitigating effects of all options to reduce risk. Residual risk is the risk that remains even after all reasonable and practicable measures have been implemented.

- Tolerable risk: If risk cannot be eliminated, what level of risk is acceptable, or tolerable? Tolerable risk is the level of risk people are willing to accept to secure certain benefits. Tolerable risks range from those we encounter every day and that are broadly acceptable, like driving a car, to those that are unacceptable, such as mass casualties or societal disruption from a major natural or man-made disaster. See Figure A-1.

Figure A-1: Range of tolerable risks (Source: Larry Roth)

Applying the concept of tolerable risk offers an informed and appropriate basis on which to formulate risk management policy and to prioritize and allocate scarce resources for risk reduction. Tolerability of risk informs deliberations on “how safe is safe enough?” and creates a sound basis for better understanding of risk; improved communication of risk and risk-related issues; transparency in risk decision-making; and overall enhanced risk management. When we quantify risk using probability and consequences, we can also quantify risk reduction afforded by various adaptation strategies, which enables us to make quantitative comparisons of solutions that may be more resilient, sustainable, and cost-effective.

In civil infrastructure, the basic principles of tolerable risk are that life safety is paramount, that risk cannot be ignored, and that absolute safety cannot be guaranteed. The goal is to reduce risk to as low as reasonably practicable—that is, to focus on what can be reasonably achieved without spending an inordinate amount of time, money, and resources to reduce risk relative to benefits. To meet this goal, application of the concept of tolerable risk requires consideration of

In risk management, the phrase
“as low as reasonably practicable”
is often abbreviated as “ALARP.”

- Individual Risk: The probability of harm to individuals and the things they value.

- Societal Risk: The probability of adverse consequences that impact society at large; society is increasingly averse to risk as the scale of consequences increases.

- Efficiency: The need for society to use available resources to achieve the greatest benefit.

- Equity: The right of all individuals to be treated with fairness.

Application of the concept of tolerable risk to decision-making regarding multiple possible futures caused by our changing climate offers many advantages. The concept of tolerable risk

- Enables the decision-making process to focus on the most serious risks posed by climate change and to prioritize actions accordingly

- Enables taking actions that are commensurate with risks, which improves cost-effectiveness

- Enables rational consideration of a variety of adaptation strategies to reduce risk as well as consideration of benefits that cannot be readily monetized

- Promotes consistency in that similar approaches can be taken in similar circumstances to achieve similar ends

- Promotes equity in that everyone’s interests and safety can be treated with fairness

- Promotes efficiency by using available resources to achieve the greatest benefit

- Provides transparency in the decision-making process

- Enables clear communication of the risks and risk-based decisions to those most affected

- Provides clarity on who is responsible for identifying, managing, and communicating risk

Using the concept of tolerable risk means we can avoid making decisions regarding risk reduction based on judgment and stakeholder preferences. Instead, we can consider issues such as resilience and sustainability, and efficient use of resources. When we quantify risk using probability and consequences, we can also quantify risk reduction afforded by a variety of adaptation strategies, which enables identification of solutions that may be more resilient, sustainable, and cost-effective.

A.4 Adaptive Management

Risk assessment, no matter how thorough and well-executed it might be, cannot eliminate living order uncertainty that civil infrastructure will face in a changing climate. Risk assessment can be useful, however, in improving our ability to manage uncertainty using adaptive management to incorporate adaptation strategies for multiple futures. Adaptive management is a framework of flexible decision-making for ongoing knowledge acquisition, monitoring, and evaluation. It’s a process of continuous improvement in planning, design, and operation to ensure specified objectives are achieved.

Adaptive management enables structured decision-making to reduce uncertainty by using a process that incorporates advanced planning, observation and measurement of conditions, selection of pre-determined response actions based on conditions observed, and feedback of accrued information to improve future management actions. Adaptive management is useful for dealing with the effects of climate change because it allows us to react to changing conditions while learning more about both the impacts of change and the success or failure of our adaptation strategies.

Because the complex relationship between the works of man and the environment is further complicated by climate change, we cannot know what the future will bring. We have, however, an obligation to design infrastructure that is safe and fit for use today, and that is resilient and adaptable to the inevitable changes we will see. Figure A-2 illustrates an adaptive management process for living order to provide a robust framework that can guide future actions to assure safety and fitness for use.

Figure A-2: Adaptive management for living order (Source: Larry Roth)

As the earlier project examples demonstrate, our approach to design two decades or more ago relied on the geometric-order concept of stationarity. Climate change, however, dictates that we employ the living-order concept of non-stationarity to meet our current and future needs for safe, reliable, and efficient infrastructure. Risk assessment is a valuable means to better understand the risk and uncertainty climate change will bring. Quantifying risk using probability and consequences enables us to better understand, manage, and communicate that risk and uncertainty. We can also make quantitative comparisons of solutions to find those that are resilient, sustainable, and cost-effective by quantifying risk reduction afforded by various adaptation strategies. Finally, application of adaptive management processes can ensure that infrastructure we design and build today will be fit for use and safe in a future world that has been altered by climate change.

~Glossary

adaptive management—A framework of flexible decision-making for ongoing knowledge acquisition, monitoring, and evaluation. It requires continuous improvement in planning, design, and operation to ensure specified objectives are achieved.

non-stationarity—”The presumption that, because of climate change, past environmental conditions are no longer a reliable predictor of future conditions” (Wallace 2018).

residual risk—The risk that persists even after all reasonable and practicable measures to eliminate risk have been implemented.

stationarity—A fundamental assumption of engineering that presumes “past environmental conditions are good predictors of future ones.” Until relatively recently, using past conditions to predict the future enabled engineers to “plan, design and deliver long-lived infrastructure, confident that projects would be safe, reliable and efficient” (Wallace 2018).

~References

Federal Highway Administration (FHWA). 2017. Adaptation Clearinghouse. July. Accessed August 12, 2019. https://www.adaptationclearinghouse.org/resources/fhwa-synthesis-of-approaches-for-addressing-resilience-in-project-development.html.

Wallace, William A. 2018. “Viewpoint: Lead on Climate Change Solutions Before It’s Too Late.” Engineering news-Record. Accessed August 12, 2019. https://www.enr.com/articles/45689-lead-on-climate-change-solutions-before-its-too-late.

2

Appendix B - Quality Management

Quality is free. It’s not a gift, but it’s free.
—Philip Crosby

Objectives

After reading this appendix, you will be able to

- Discuss the role of quality within the project management triangle and define quality in the context of a project

- Explain the importance of project requirements in quality planning and identify components of a project quality plan

- Distinguish between quality assurance and quality control and identify tools commonly used to manage quality on a project

- Explain the benefits of quality management standards and systems

The Big Ideas in This Appendix

- Any adjustments to the triple constraints of scope, budget, and schedule can affect the quality of a project’s outcome.

- A comprehensive quality plan also specifies how quality testing and inspection will be implemented and identifies the resources required to meet the project’s quality requirements.

- The goal of any project is to build quality in from the bottom up. This entails constant reference to the customer’s definition of value, and then translating that definition into actual engineering requirements.

B.1 Quality in Project Management

The triple constraints of project management—scope, budget, and schedule—are often referred to as the iron triangle because that name conveys the extent to which these constraints affect the execution and outcome of every project. As you learned in Lesson 3, a change to one constraint necessitates a change to at least one other constraint to keep the triangle whole. For example, if you need to expand the project’s scope, then you’ll have to either increase the budget or slow the schedule to complete the additional work. Similarly, if you decrease the budget, you’ll have to either decrease the schedule or reduce the scope to make it possible to complete the project with the available funds. And speeding up a schedule to complete the stated scope will inevitably require a higher budget.

Any adjustments to the triple constraints can affect the quality of the project’s outcome. That’s why the iron triangle (or the project management triangle, as it is also called) is usually portrayed with the word “Quality” at the center, as shown in Figure B-1. Indeed, many project management experts consider quality to be the fourth constraint on every project.

Figure B-1: Maintaining the required level of quality requires balancing the constraints of scope, budget, and schedule.

Quality’s position at the center of the iron triangle emphasizes the need to consider quality when inevitable trade-offs between constraints are made in a living order project. As you learned in Lesson 3, scope evolution often occurs in living order projects as the project team develops a more in-depth understanding of the customer’s requirements. Changes to the scope might result in a revised definition of quality for the product of the project, which could require an extended project timeline. Conversely, cuts to a project’s budget could require that the project team work with the customer to develop a new definition of quality for a particular deliverable.

Balancing Project Constraints Using a Cost-Benefit Analysis

To help the customer or project sponsor make decisions about balancing project constraints while maintaining the required level of quality, a project leader may undertake a formal or informal cost-benefit analysis, which involves adding up the benefits of a specific action and then subtracting the costs associated with that action (Kenton 2020). This form of analysis is useful when making decisions involving constraint trade-offs as well as larger decisions such as deciding which of two proposed projects to proceed with.

These two articles provide more details on cost-benefit analysis:

- https://online.hbs.edu/blog/post/cost-benefit-analysis

- https://twproject.com/blog/analysis-costs-project/.

Talking about Quality

The term quality can mean different things in different industries, organizations, and groups of people. But the American Society for Quality (ASQ) spells out two hallmarks of quality: “fitness for use” and “conformance to requirements” (n.d.).

In other words, a product, building, or service can be considered high quality if it is fit for the use for which it was intended and if it conforms to its predefined requirements. But how do you go about making that determination in a way that ensures all stakeholders will agree? You need to create an objective standard in the form of SMART requirements (Smith 2019).

Since the early 1980s, businesses have used variations of SMART criteria to evaluate their objectives. The term “SMART” is an acronym for the following attributes that ensure objectives are actually achievable: specific, measurable, assignable (or agreed on), realistic and time-based. In the context of project quality, the most important aspect of the SMART approach is the need to be specific about scope requirements, so it is clear that the project deliverables meet those requirements. To avoid misunderstandings about quality requirements—and possible rework—defining what is not in scope is just as important as defining what is in scope. You can read more about formulating SMART quality criteria here: https://www.amanet.org/articles/critical-link-between-requirements-and-project-quality/.

Of course, the goal of any project is to build quality in from the bottom up. This entails constant reference to the customer’s definition of value, and then translating that definition into actual engineering requirements. One widely used method for accomplishing this is quality function deployment (QFD) or the “voice of the customer.” This technique helps organizations translate the product attributes the customer wants into tangible, measurable requirements that the project team can deliver. QFD makes use of a product planning matrix, commonly referred to as the House of Quality, as well as technical and competitive benchmarking to establish target values for each product design requirement (ASQ n.d.). At its best, QFD can take subjective qualitative attributes and establish links to quantitative metrics that will ensure customer satisfaction, and it can be a particularly helpful technique in terms of establishing what the team needs to work on to deliver the scope of the project within the customer’s definition of quality.

The American Society for Quality website provides more information on QFD and the House of Quality matrix at: https://asq.org/quality-resources/qfd-quality-function-deployment.

Delivering Quality versus Gold Plating

Taking the time to develop SMART criteria for judging quality while also employing a method like QFD to systematically build quality in from the bottom up will help you avoid falling into the trap of gold plating, which means adding functionality that exceeds the project’s requirements, “possibly even beyond what is practical or reasonable for the effort” (Egeland 2013). As noted in an article on the Global Knowledge website: “Quality is not about giving the customer extras or completing extra work” (2017). For starters, the extras added to a deliverable may be based on “erroneous perceptions of what you believe the customer wants. These extras add time, possible costs, and other impacts to a project, but do not always result in increased customer satisfaction” (2017).

Rexter Retana, a civil engineer and project manager, views scope creep and gold plating as two sides of the same coin. One is a result of incremental change requests from the customer; the other is a result of the project team, or individual team members, adding features or deliverables that were not included in the original requirements. According to Retana, gold plating can have several negative consequences, including driving up project costs by consuming additional time and resources, increasing project risk, especially if the extra features or deliverables are not documented, raising the client’s expectations for future projects, and fueling client dissatisfaction—and even legal disputes—if the gold plating results in budget and schedule overruns (2014).

The Cost of Quality

Delivering a project’s quality requirements means considering the cost of quality, which includes costs over the life of the product, not just those incurred during the project. Quality costs are typically divided into two categories: cost of conformance (or good quality) and cost of nonconformance (or bad quality). The costs within each category, are often broken out further, as shown in Figure B-2.

Figure B-2: The cost of conformance (prevention/appraisal costs) reflects the time and money required to prevent problems and defects, while the cost of nonconformance (internal/external failure costs) reflect the time and money to recover from them (Radziwill 2019).

Cost of Conformance

The cost of conformance, or the cost of good quality, includes the cost of preventing quality defects as well as the cost of appraising or detecting defects in the project deliverables or processes. Prevention costs are associated with planned activities such as setting quality standards, developing a project quality plan, conducting deliverable reviews during an Agile sprint review meeting, evaluating process capability, and educating and training team members on quality standards and processes (Radziwill 2019). Appraisal costs come in the form of measuring and monitoring activities to evaluate “purchased materials, processes, products, and services to ensure that they conform to specifications” (ASQ n.d.). Audits, inspections, and testing also fall under the appraisal cost category (Warcholinski n.d.).

Cost of Nonconformance

The cost of nonconformance, or the cost of poor quality, is a result of quality failures—both during and after the project. Internal failure costs, which are incurred when defects are discovered before deliverables are received by the customer, could include costs of scrap, rework, and failure analysis (ASQ n.d.). External failure costs occur when deliverables that fall short of established quality standards are not detected until after transfer to the customer; such costs could accrue from repair work, complaint resolution, and warranty claims (ASQ n.d.). Another way to look at nonconformance costs is to think of internal failure costs as “waste” and external failure costs as “downstream consequences,” of which there can be many (McMenamin 2017).

Taguchi Loss Function

The Taguchi method of quality control is “an approach to engineering that emphasizes the roles of research and development (R&D), product design, and development in reducing the occurrence of defects and failures” and ensuring the product performs exactly as designed (Liberto 2019). Underlying the Taguchi method is the assumption of a standard—that is, a target value for quality. Although customers may accept products or deliverables between the upper and lower limits of the quality specifications, they will get greater value from products that are closer to the target quality. Value for the customer decreases on either side of the target value (Rob 2019). Another way to look at it is to consider the ‘utility’ of the quality being applied: Is it actually adding value to the end customer or consuming resources unnecessarily? Key to the Taguchi method is the Taguchi loss function, which measures “the cost of quality as a function of deviation from the standard,” is an explicit reference to the costs of poor quality as well as the costs of quality that is too high (Schenkelberg n.d.).

To learn more about the Taguchi loss function, start with this short article on the Taguchi quality control method: https://www.investopedia.com/terms/t/taguchi-method-of-quality-control.asp. For a more detailed discussion of the Taguchi loss function, visit: https://sixsigmaninja.com/taguchi-loss-function/.

B.2 Quality Planning

The set of requirements that define the project scope provide the foundation for the project’s quality-planning activities and determine the processes and deliverables that will be covered by the quality plan. The project leader, along with the project team and other stakeholders, use the project requirements to specify the quality requirements as well as the quality metrics, standards, and acceptance criteria that will be used to validate if the project’s processes and deliverables are compliant. A comprehensive quality plan also specifies how quality testing and inspection will be implemented and identifies the resources required to meet the project’s quality requirements.

When developing a quality plan, avoid a checkbox mentality that creates unnecessary work that shifts the team’s focus away from delivering quality. An effective quality plan should maintain quality standards and oversight, while also being flexible enough to adapt to ongoing refinements to scope as the project unfolds.

The quality plan for each project will differ depending on the needs of the project, but some common elements of a quality plan include:

- The project’s approach to quality management

- The deliverables (i.e., the unique and verifiable products, services, or results) and processes that will be reviewed

- How the quality requirements will be defined for the deliverables and the processes

- Roles and responsibilities

- When and how you will manage quality

- When and how you will control quality (i.e., how the team will evaluate the deliverables)

- How defects will be prevented and corrected

- Definitions (Hall n.d.)

The following articles provide additional recommendations for quality planning, with specific suggestions on what to include in your project quality plan:

- Designing Buildings Wiki (construction industry): designingbuildings.co.uk/wiki/Project_quality_plan_PQP

- Digital Project Manager (software development): https://thedigitalprojectmanager.com/quality-management-plan/

- ProjectEngineer.NET (general project management): www.projectengineer.net/4-core-parts-of-a-quality-management-plan/

Quality and Procurement

Recall from Lesson 4 that expected quality should also be addressed in procurement documents such as the request for proposal (RFP), the proposal, and the final contract. Contractual commitments to quality in the form of warranties serve as a strong incentive to control quality on a project and need to be factored into quality planning from the start.

B.3 Managing Quality

Delivering on the expected level of quality requires quality management activities focused on the project’s processes as well the project’s deliverables. Often, those two aspects of quality management are broken out into two components: quality assurance (QA) and quality control (QC). Quality assurance is proactive and process-focused, while quality control is reactive and product focused (MindsMapped 2018).

Quality Assurance (QA)

Quality assurance (QA) comprises the preventive activities and processes designed to “provide confidence that the quality requirements will be fulfilled” (ASQ n.d.). QA work requires data gathering and analysis and a careful examination of processes. These activities are often completed through the use of a project audit, which is intended to confirm that the quality standards, policies, plans, and processes are being followed—and that those processes are producing the expected quality results (Simplilearn 2020).

As you learned in Lesson 13, audits help the project team determine if any corrective action is required to keep the project on track. Informal audits may be conducted by the project leader or project team during a project, including at the end of a sprint on an Agile project. A more formal, systematic audit conducted by someone external to the project, such as members of the project management office (PMO), may be used to make bigger decisions about a project’s future or as a way to gather lessons learned after the project has ended. The Stage-Gate model, discussed in Lesson 2, also typically involves an audit in some form.

Quality Control (QC)

Quality control (QC) includes the techniques and activities used to detect quality defects in the project’s deliverables. QC activities include inspection, statistical sampling and analysis, and testing. When initiating QC activities on a project, consider some of the following questions proposed in an article on the American Management Association’s website:

- Does each quality standard in the quality plan have QC activities assigned to it?

- For each QC activity, consider the following:

- What will be measured, how will it be measured, and who will perform the measurement activity?

- How many times will the activity be performed (once, in batches, periodically)?

- Where and when will the activity be performed (upon delivery, triggered by a specific event, at the end of the sprint or project)?

- How will you determine if a QC action is producing the desired results? (Smith 2019)

Effective quality management requires integrated QA and QC activities. Throughout the project, the project team analyzes the results of the QC activities as part of the QA process to determine if any corrective actions are necessary (Project Management Skills, n.d.).

Quality Management Tools

Project leaders typically draw from a range of tools when managing quality. Later in this appendix, we’ll explore some commonly used quality tools, but it’s worth noting that effective communication is often the most critical tool for managing quality over the course of a project. Brian Price, the former chief power train engineer for Harley-Davidson and an adjunct professor in the UW Master of Engineering in Engine Systems program, has this to say about the importance of good communication in quality project management:

To me, the most important aspects of quality management are to make sure there is clarity around understanding priorities and what matters to the customer—as well as ensuring that is well communicated, especially as things change over time. In my experience, most quality issues arise from incorrect assumptions, poor communication that results in team members or stakeholders working with outdated scope or quality definitions, and inadequate analysis of impacts when scope changes. That last one can be avoided by checking the iron triangle and making informed trade-offs to accommodate the changes (pers. comm. June 23, 2020).

Vera Martinovich, an engineering manager at Boeing, also emphasizes the importance of communication in quality management. In particular, she notes that a key component of quality planning and management is ensuring that you and your team understand the project’s missions, purpose, and goals:

Take time to lay the foundation of the project and communicate it to your team. You should be able to state clearly why you are doing the project, how you will do it, and what you hope to accomplish. You want the team to use that foundation to help them make decisions as time goes on. If they know the why, they will use that information to tailor the work they do.” (pers. comm. June 20,2020).

Although the tools used to manage quality on a project vary by industry and by project, quality management experts often rely on a core set of tools—called the seven basic tools of quality. The Engineering.com website provides this list of the seven basic quality tools used to analyze and represent quality-related data and resolve quality defects:

- Check sheet

- Histogram

- Run chart

- Control chart

- Pareto chart.

- Fishbone diagram

- Scatter diagram (Muelaner 2020)

You can learn more about the tools listed here by reading the Engineering.com article, “The Seven Basic Tools of Quality,” which provides more in-depth descriptions along with examples of each tool: https://new.engineering.com/story/the-seven-basic-tools-of-quality. As you do additional reading on quality management, you’ll likely across variations on this list.

The seven basic tools of quality provide a good starting point for project leaders new to quality management, but they represent just the tip of the iceberg in terms of the available tools and techniques for managing quality on a project. On the American Society for Quality website, you’ll find descriptions of more than 60 different quality tools, including details on how to create them and when to use them. You can also access templates and Excel tools, along with suggested articles, case studies, and books related quality management. The Quality Tools page of the association’s website is a good place to start: https://asq.org/quality-resources/quality-tools#Resources.

B.4 Quality Standards and Systems

Larger organizations often make use of quality management standards and systems to bring cohesion to their project quality management activities. In some organizations, the PMO plays a central role in developing organizational quality standards by gathering best practices and lessons learned from individual projects to establish standardized quality processes, procedures, tools, and techniques customized to the needs of the organization. As part of its audit function, the PMO may also monitor projects for compliance and consistency to those corporate procedures and provide training and support to up-skill individuals and teams.

In certain industries, or for certain clients, an established quality management system and accreditation to an independent quality standard may be required for an organization to qualify for large-scale contracts (BuildingTalk 2018). The ISO 9001:2015 standard outlines the criteria for a quality management system and provides guidance for improving processes and training employees (ISO n.d.). The ISO 9001:2015 standard is “based on the plan-do-check-act methodology and provides a process-oriented approach to documenting and reviewing the structure, responsibilities, and procedures required to achieve effective quality management in an organization” (ASQ n.d.).

According to the ASQ, a well-documented quality management system helps an organization meet the customer’s requirements, comply with regulations, reduce waste, lower costs, prevent mistakes, and define, improve, and control processes (n.d.).

Plan-Do-Check-Act Methodology

The iterative plan-do-check-act methodology, or PDCA cycle (shown in Figure B-3), which serves as an integral part of the ISO 9001:2015 quality standard, “outlines an intuitive framework for improving the quality and effectiveness of processes” (Thomas 2019). According to ISO, PDCA “operates as a cycle of continual improvement” and serves as a tool to manage both processes and systems (n.d.).

You can read more about the cycle and a description of each of the four stages here: https://www.thomasnet.com/insights/pdca-cycle/.

Figure B-3: The four-step plan-do-check-act (PDCA) cycle provides an iterative approach to quality and continuous improvement. Source: ChristophRoser; AllAboutLean.com/CC BY-SA

The thread of quality runs through a project from beginning to end. Throughout, the team leader must balance the desired quality with the triple constraints of budget, schedule, and scope. Over the life of the project, the project leader must continually check in on quality ensure the living project does not deviate from an acceptable outcome.

~Practical Tips

- Build in quality from the ground up: Taking the time to develop SMART criteria for judging quality, and employing a method like QFD to systematically build quality in from the bottom up will help you avoid falling into the trap of gold plating.

- Focus on high-impact items when determining the cost of quality: Rather than trying to measure and track every possible quality-related cost, focus on the processes and activities that have the biggest potential impact in terms of cost and outcome.

- Keep team members and other stakeholders up to date on changes to scope or quality definitions over the course of the project: Effective communication is often the most critical tool for managing quality over the course of a project. Poor communication can lead to incorrect assumptions and rework.

- Be specific about quality requirements: Clearly define what is in scope and what is not in scope so it is clear to everyone involved if the deliverables meet the project requirements.

~Summary

- Quality is often described as the fourth project constraint, which must be balanced with the three constraints that form the iron triangle of project management: scope, budget, and schedule. Balancing project constraints requires a common understanding of quality, often defined as “conformance to requirements,” and a set of SMART requirements defined “in a manner that facilitates objective validation, rather than subjective opinion.” (Smith 2019). The cost of quality must also be considered when balancing project constraints. Quality costs are typically divided into two categories: cost of conformance (the cost of good quality) and cost of nonconformance (the cost of poor quality).

- The set of requirements that define the project scope provide the foundation for the project team’s quality-planning activities and determine the processes and deliverables that will be covered by the quality plan. The project requirements are used to specify quality requirements and identify the quality metrics, standards, and acceptance criteria that will be used to validate if the project’s processes and deliverables are compliant. A comprehensive quality plan also specifies how quality testing and inspection will be implemented and identifies the resources required to meet the project’s quality requirements.

- Quality management includes activities focused on both the project’s processes and the project’s deliverables. Quality assurance (QA) is made up of the preventive activities and processes designed to “provide confidence that the quality requirements will be fulfilled” (ASQ n.d.). QA involves data gathering and analysis as well as a careful examination of processes, often completed as part of a formal or informal project audit. Quality control (QC) includes the techniques and activities (such as inspection, statistical sampling and analysis, and testing) used to detect quality defects in the project’s deliverables. Project leaders make use of a range of tools when planning and managing quality—the most critical of which is effective communication.

- Some organizations rely on quality management standards and systems to bring cohesion to their project quality management activities. The PMO may lead this effort by gathering best practices and lessons learned from across many projects to establish standardized quality processes, procedures, tools, and techniques customized to the needs of the organization. An established quality management system and accreditation to an independent quality standard (such as the ISO 9001:2015 standard) may be required for an organization to qualify for large-scale contracts in certain industries or for a particular client. (BuildingTalk 2018).

~Glossary

- cost of conformance—The cost of good quality, which includes the cost of preventing quality defects as well as the cost of appraising or detecting defects in the project deliverables or processes.

- cost of nonconformance—The cost of poor quality, which is a result of quality failures—both during and after the project.

- cost of quality—The cost of delivering on the quality requirements of the project. The cost of quality, including the costs of conformance and the costs of nonconformance extend beyond the project and accrue over the life of the product of the project.

- gold plating—Adding functionality that exceed a project’s requirements, “possibly even beyond what is practical or reasonable for the effort” (Egeland 2013).

- quality—The features of a product or project that bear on its fitness for use—that is, its ability to meet the requirements of the customer; another component of quality is freedom from deficiencies.

- quality function deployment (QFD)—A technique that helps organizations translate the product attributes the customer wants into tangible, measurable requirements that the project team can deliver. QFD, which is also known as voice of the customer, makes use of a product planning matrix, commonly referred to as the House of Quality, as well as technical and competitive benchmarking to establish target values for each product design requirement (ASQ n.d.).

- Taguchi loss function—A measure of “the cost of quality as a function of deviation from the standard” (Schenkelberg n.d.).

~References

American Society for Quality (ASQ). n.d. “How to Build A House of Quality with Technical and Competitive Benchmarking.” American Society for Quality. Accessed July 3, 2020. https://asq.org/quality-resources/house-of-quality.

—. n.d. “What Is a Quality Management System (QMS)?” American Society for Quality. Accessed May 20, 2020. https://asq.org/quality-resources/quality-management-system.

—. n.d. “What Is ISO 9001:2015 – Quality Management Systems?” American Society for Quality. Accessed May 19, 2020. https://asq.org/quality-resources/iso-9001.

BuildingTalk, “Five Benefits of ISO 9001 in the Construction Industry.” BuildingTalk, https://www.buildingtalk.com/blog-entry/5-benefits-of-iso-9001-in-the-construction-industry/.

Egeland, Brad. 2013 “Gold Plating Project Management – Part 1.” October 6. Project Smart. https://www.projectsmart.co.uk/gold-plating-project-management-part-1.php.

Global Knowledge. 2017. “What is Project Quality Management?” April 10. Global Knowledge. https://www.globalknowledge.com/us-en/resources/resource-library/articles/what-is-project-quality-management/.

Hall, Harry. n.d. “How to Develop a Quality Management Plan.” Project Risk Coach. https://projectriskcoach.com/how-to-develop-a-quality-management-plan/.

Hartney, Jon. 2019. “The 6 Steps of Resource Allocation.” ProjectEngineer. July 5. https://www.projectengineer.net/the-6-steps-of-resource-allocation/.

International Organization for Standardization. n.d. “Members.” International Organization for Standardization. Accessed May 20, 2020. https://www.iso.org/members.html.

Kenton, Will. 2020. “Cost-Benefit Analysis.” Investopedia. Accessed August 20, 2020. https://www.investopedia.com/terms/c/cost-benefitanalysis.asp.

Liberto, Daniel. 2019. “Taguchi Method of Quality Control.” Investopedia. August 26. https://www.investopedia.com/terms/t/taguchi-method-of-quality-control.asp.

McMenamin, Edward. 2017. “A Fresh Look at Cost of Quality.” Quality Magazine. November 6. https://www.qualitymag.com/articles/94337-a-fresh-look-at-cost-of-quality.

MindsMapped, 2018. “Quality Assurance vs. Quality Control.” MindsMapped, March 31. https://www.mindsmapped.com/quality-assurance-vs-quality-control/.

Muelaner, Jody. 2020. “The Seven Basic Tools of Quality.” Engineering.com. January 28. https://new.engineering.com/story/the-seven-basic-tools-of-quality.

Project Management Skills, n.d. “What is Quality Assurance?” Project Management Skills. https://www.project-management-skills.com/what-is-quality-assurance.html.

Radziwill, Nicole. 2019. “A New Look at Prevention and Appraisal Costs.” Intelex. August 29. https://community.intelex.com/explore/posts/new-look-prevention-and-appraisal-costs.

Retana, Rexter. 2014. “BIM Scope Creep.” BIM ThinkSpace.” August 20. https://www.bimthinkspace.com/2014/08/bim-scope-creep.html#_About_the_author.

Rob. 2019. “Taguchi Loss Function.” Six Sigma Ninja. November 11. https://sixsigmaninja.com/taguchi-loss-function/.

Schenkelberg, Fred. n.d. “Taguchi’s 3 Fundamental Concepts.” Accendo Reliability. https://accendoreliability.com/taguchis-3-fundamental-concepts/.

Simplilearn. 2020. “Project Quality Management: Perform Quality Assurance Vs Perform Quality Control.” Simplilearn. July 29. https://www.simplilearn.com/project-quality-management-article.

Smith, E.J. 2019. “The Critical Link Between Requirements and Project Quality.” American Management Association. April 11. https://www.amanet.org/articles/critical-link-between-requirements-and-project-quality/.

Steinman, Jay. 2017. “Defining and Measuring Project Quality.” Control Engineering. May 5. https://www.controleng.com/articles/defining-and-measuring-project-quality/.

Thomas, 2019. “What is the Plan-Do-Check-Act (PDCA) Cycle?” Thomas. October 8. https://www.thomasnet.com/insights/pdca-cycle/.

Warcholinski, Matt. n.d. “The Cost of Quality in Software Development – Is the Quality Worth It?” Brainhub. https://brainhub.eu/blog/cost-of-quality-in-software-development/.

3

Appendix C - Project Recovery

We can’t solve our problems with the same level of thinking that created them.
—Albert Einstein (1946)

Objectives

After reading this appendix, you will be able to

- Identify problems affecting troubled projects

- Discuss issues related to cognitive biases and other issues that prevent a clear understanding of project problems

- Explain techniques for assessing options and developing a rescue plan

The Big Ideas in This Appendix

- It’s rare that a single, easy-to-identify cause sends a project off the rails. Usually multiple problems work together to sabotage a project.

- You can’t pull a troubled project back from the brink until you fully understand how it got there in the first place.

- Getting a project back on track and avoiding new problems requires a recovery plan with detailed requirements and a clear definition of success—along with established acceptance criteria for the newly established project deliverables.

C.1 Identifying a Troubled Project

Even the most-successful project managers have likely worked on projects that seemed to spiral out of control on their watch. Or they may have been asked to step in and take over a project already teetering on the brink of failure. In hindsight, the signs of trouble on those projects and the actions required to save them may seem obvious, but recognizing that a project is in trouble and making a commitment to get it back on track can be difficult first steps.

Project management literature has much to say about rescuing a troubled project. The focus is often on the importance of identifying the root cause of a problem on a project—as if the solution lies in simply getting to the bottom of a problem that just needs to be “fixed.” The reality is typically much more complex, with gradations of trouble on an at-risk project ranging from issues caused by a single, major variable—such as the loss of a key team member or a sudden increase in the price of fuel oil—to problems resulting from the interactions of many different variables inside and outside the project.

Those variables can interact in countless ways depending on the nature of the project, the project team, the stakeholders, the organization, and the overall environment in which the project is taking place. For instance, a project could be at risk because key project stakeholders are no longer engaged, causing the project team to drift away from their focus on delivering value to the customer. That drift could then result in scope creep, which, in turn, leads to cost and schedule overruns that can no longer be absorbed by project reserves. Poor communication from the project manager could be exacerbating those problems, as could the failure of the customer and project team to have clearly defined success at the start of the project.

Sometimes the problem lies in the interaction of factors that, on their own, would be benign. For example, you might successfully hire a vendor to create a deliverable using their proprietary technology. Or, instead, you might choose to do it in-house, using your own technology so you can be sure you understand the process and the outcome. Either option could be fine. But hiring a vendor to use your technology, which they don’t understand, could spell disaster.

The multitude of project variables, along with the complexity of their interactions, can make it very difficult to understand the full extent of the problems on a project—much less the best approach for getting the project back on track. But if you are blinded by cognitive biases, fully understanding the situation is nearly impossible.

Avoiding Cognitive Biases

You’ve already seen in earlier lessons how cognitive biases—or errors in thinking—can prevent people from clearly understanding project risks. For instance, confirmation bias—the tendency to pay attention only to information that confirms your preconceptions—can contribute to an illusion of control, making a team believe a project is going well even when it isn’t (Virine, Trumper and Virine 2018). A project manager trying to both manage and champion a project—or a team vested in a particular approach—may not see that their project is in trouble. Even if they can perceive trouble, confirmation bias may trick them into thinking things will get better without the need to upend the existing project. Meanwhile, the planning fallacy contributes to a delusional sense of optimism, causing everyone to believe everything is fine, when in fact the project is spinning out of control. Other cognitive biases, such as conservatism (weighting evidence you are already familiar with more heavily than new evidence) and groupthink (adopting a belief because a significant number of people already hold that belief), can limit your imagination, preventing you from foreseeing how something that seems minor now could turn out to be a serious problem. Cognitive biases can also prevent you from recognizing that a series of apparently unrelated problems could, collectively, point to a project in serious jeopardy.

As a project manager, you’ll need to beware of biases, your own as well as those of the people who are providing you information about the project. Daniel Kahneman, a Nobel Prize winner for his groundbreaking work on cognitive biases, has shown that one of the most effective ways to counter the effects of cognitive biases is reference class forecasting, a method of predicting outcomes by setting aside the outcome you and your team predict and instead analyzing the actual outcomes of similar projects. Also known as taking an outside view, this form of forecasting outcomes “requires planners to identify a reference class of analogous past initiatives, determine the distribution of outcomes for those initiatives, and place the project at hand at an appropriate point along that distribution” (Lovallo and Kahneman, 2003). Selecting the right reference class—that is, the right group of relevant projects—requires the project leader to weigh many variables, but ultimately comes down to a judgment call.

If you’re a manager at a chemical company considering building an olefin plant incorporating a new processing technology, you may instinctively think that your reference class would include olefin plants now in operation. But you may actually get better results by looking at other chemical plants built with new processing technologies. The plant’s outcome, in other words, may be more influenced by the newness of its technology than by what it produces. The key is to choose a class that is meaningful but narrow enough to be truly comparable to the project at hand. (Lovallo and Kahneman, 2003)

Recognizing the power of cognitive biases and using reference-class forecasting to combat their effects will help you and your team gain a true understanding of a troubled project. Terry Little, an innovative U.S. Air Force program manager who built a career around rescuing failing projects, learned early on that true understanding was a necessary precondition to success. He described his first steps in reviving a stalled cruise-missile program like this:

I started collecting some information about the status of the program. It became apparent that the…team did not grasp the extent of the dissatisfaction with their achievements. As in other times throughout my career, I realized that my first challenge would be to change the way in which the team perceived reality. (Laufer, 2012, 21)

That’s not a small thing—changing how a group of people perceives reality. But it’s the first and most important job of a leader charged with pulling a troubled project back from the brink of failure.

Failing to Recognize Failure

An extreme example of the dangers posed by cognitive biases like confirmation bias and groupthink can be found in the 2018 collapse of a pedestrian bridge on the Miami campus of Florida International University. The bridge, which spanned an eight-lane road, collapsed while still under construction, killing six people. According to National Transportation Safety Board (NTSB) Chairman Robert Sumwalt, “Errors in bridge design, inadequate peer review, and poor engineering judgment led to the collapse of this bridge…The failure of all concerned parties to recognize and take action on the threat to public safety presented by the significant observed bridge structure distress prior to the collapse, led to the tragic loss of life in this preventable accident.” As Sumwalt explained, in the weeks leading up to its collapse, the bridge was essentially “screaming at everyone that it was failing,” yet no one on the project seemed willing to recognize the extent to which the project was in trouble (NTSB 2019).

For more information about the Florida International University pedestrian bridge collapse, including an animation of the sequence of events leading up to the collapse, watch this six-minute video created by the NTSB:

A YouTube element has been excluded from this version of the text. You can view it online here: https://wisc.pb.unizin.org/technicalpm/?p=1476

Spotting Signs of Trouble

Although problems on failed projects are often glaringly obvious in hindsight, “sometimes when you are inside a project—and you’re managing it day to day—it becomes very difficult to see what is actually happening. You’re too close to the detail” (Harrin n.d.). To ensure you’re not blinded by the day-to-day rush of detail, it can be helpful to stop every now and then and compare your project to a list of known types of problems that often indicate a project is in need of rescue:

- The project is significantly over budget, with little chance of getting it back on track.

- The project team is regularly missing basic performance metrics or major deadlines/milestones.

- The scope of the project keeps changing.

- No one is really able to explain what you are trying to deliver on the project, and there are ongoing disagreements between stakeholders about the project’s requirements and goals.

- Team morale is low, team members seem disconnected, and turnover on the project team is increasing (Warcholinski n.d.).

- Key stakeholders are no longer engaged; they have stopped attending meetings, and they provide limited feedback when asked to participate in decision making.

- The number of change orders has been increasing, and the customer has disputed several project invoices in recent weeks (Seador 2019).

- Team members and other resources are being pulled off the project by upper management.

- Project technology is not working.

- The wrong people are in the wrong roles, preventing them from executing the project successfully.

- Your informed intuition tells you something is off on the project even though you have yet to identify a problem.

Every experienced project manager typically has their own set of warning signs, and over time, you’ll likely develop your own. One way to get a better sense of the most telling warning signs in your organization is the managing by walking around (MBWA) management style you learned about in Lesson 11. Becoming a regular practitioner of MBWA will increase the odds that you’ll spot a warning sign while you still have time to act. Spontaneous conversations with team members and informal reviews of ongoing work can uncover issues requiring immediate action or further investigation.

Of course, the mere existence of warning signs does not necessarily mean a project is in peril. What really spells trouble is the persistence of issues that seem to have no clear resolution and that contribute to “an overall growing sense of unease.” According to Matt Warcholinski, trouble spots in a project do not doom it to failure, as long as you use the problems to “analyze why the project is failing” and then figure out what to do about them (Warcholinski, n.d.). In other words, once you identify problems, you have to make sure you really understand them.

C.2 Understanding the Problem

What does it mean to understand a problem? First and foremost, you need to see it in context.

Seeing the Layers of Context

As you learned in Lesson 1, a project’s context consists of the day-to-day environment and the larger organizational background in which the project unfolds. Figure C-1 shows the many layers of context that can enfold a single project.

Figure C-1: A troubled project can have impacts that extend far beyond the project itself

Clearly, then, identifying a problem is only the beginning. You can’t really understand it until you understand the extent to which the problem is impacting the project team, the project itself, the program or portfolio, the business unit, the organization, the customer, shareholders, and even the general public. A project leader who attempts to “solve” problems without looking at this big picture is like a park ranger intent on stamping out a single spark while a forest fire rages in the background.

Context is especially important when dealing with problematic team dynamics. Team tensions can cause communication problems between the project manager and team and among team members, with those problems then radiating outwards, leading to rework, missed milestones, and cost overruns. In turn, those issues can lead to resentment and team dysfunction—all of which could put the project (or even an entire program or portfolio of projects) at risk.

An example of trouble radiating outward from a project occurred at Revlon, which acquired a new company, Elizabeth Arden, and then barreled ahead with integrating the new company’s system into its own ERP in one fell swoop, rather than rolling out changes incrementally, allowing employees to learn the new system step-by-step. Doing everything at once made it impossible to identify individual problems as they arose. Worse, it appears the company failed to formulate any kind of serious risk management strategy to deal with the cascading problems that did arise. Almost immediately, one of Revlon’s North Carolina plants experienced shipping delays. Revlon eventually lost almost $64 million in sales and was sued by its own shareholders (Techliance, n.d. and Dolfing 2019). One of several lawsuits alleged, among other things, that the company “failed to design, implement and consistently operate effective process-level controls” on the project (Saran 2019).

Trouble on a complex engineering project can put more than the organization at risk, particularly if the trouble takes the form of technical failures and flawed deliverables. The impact of this type of trouble, which can often be traced back to failures in project leadership, can easily extend beyond the project and the organization to the customer and even the general public—as evident in the collapse of the Florida International University pedestrian bridge.

Identifying the Root Cause

Once you have a good understanding of a troubled project’s context, you can look for the root cause of the project’s problems. In this stage, your goal isn’t to “fix” the project by fixing the root cause of its problems—usually an impossible goal—but rather to gain a deeper understanding of the project you are trying to rescue. Without that understanding, you can easily fall into the trap of trying to solve the wrong problem.

As organizational theorist Russell L. Ackoff described the challenge: “We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem” (1974, 8). Solving the right problem requires you and your team to ask critical questions to get to the root cause of the problems you are facing.

The American Society for Quality (ASQ) defines a root cause as “the core issue—the highest-level cause—that sets in motion the entire cause-and-effect reaction that ultimately leads to the problem(s).” A root cause analysis is “a collective term that describes a wide range of approaches, tools, and techniques used to uncover causes of problems.” (n.d.)

Root Cause Analysis Tools

The American Society for Quality (ASQ) identifies three primary tools for conducting root cause analysis: fishbone/Ishikawa diagrams, Pareto charts, and scatter diagrams. For more on these tools, along with links to additional resources related to root cause analysis, see the “Cause Analysis Tools” page on the ASQ website: https://asq.org/quality-resources/root-cause-analysis/tools.

In Rescue the Problem Project, Todd C. Williams discusses the importance of conducting root cause analysis early in the efforts to recover a failing project:

“Although determining root causes up front takes more time and requires making tough decisions early, in the end it requires less management and increases the odds of a successful recovery…. When all root causes are uncovered, the recovery manager can best determine and document the corrective actions needed to fix those issues. In addition, he or she assembles the recovery plan, with multiple alternatives, to complete the newly redefined project. The plan’s goal is to fix the issues at their root cause and then, after arriving at a compromise on the new scope, schedule, and budget, to deliver the product.” (9-10)

John Nelson recommends taking the long view when it comes to looking for root causes on failing projects:

When I’m asked to help revive a troubled construction project, I find it’s helpful to ask, “What happened 1,000 days ago?” The precipitating event usually took place then—roughly three years before. Of course different industries require you to use different time frames. But the point is that the root cause of potential project failure usually lies further back in time than an inexperienced engineer might think.

And often the root cause doesn’t have anything to do with engineering. Politics, for instance, can throw a project into disarray. Sometimes people can’t agree on how to proceed, and the ongoing disputes finally exhaust everyone. In the end, they agree on something, anything, just because they have to end the process, not because it’s the best approach. It’s only later that the repercussions of those decisions become evident. The repercussions might appear to be engineering problems when they are actually problems caused by people who couldn’t come to an agreement—for example, suppose a public park floods every spring, leading people to think the park designers did something wrong, when in fact the root cause was a dispute in the parks department that prevented an optimal site selection in the first place.” (2020)

Engaging the Project Team and Other Stakeholders

Gaining a clear understanding of the problems you are trying to solve is impossible without engaging with the project team and other stakeholders to get their take on the project’s context and the root causes of its problems. This early engagement is also an essential first step in getting everyone onboard with the changes required to implement a solution, thus increasing your chances of eventual success. As Moira Alexander notes in an article for TechRepublic, ”When a team is able to have an impact on the decision or solution, it enables them to get past the fear so they can utilize their energy in tackling the issue faster“ (Alexander 2019).

Keep in mind that engaging with the team and stakeholders doesn’t mean simply presenting a list of problems you’ve already identified. Instead, ask key people to work with you to generate alternative explanations for the project’s challenges. This will help you overcome your own confirmation bias, making it more likely you’ll identify the critical issues—and, ultimately, the optimal response. (Larson and Gray, 2011, 393). Establishing a “no fault” culture as you start this work will help the team more quickly identify problems and foster collaboration as you move on to developing solutions (Lloyd-Walker, Mills and Walker 2014).

C.3 Assessing Options and Developing a Plan

With a solid understanding of the project’s problems in hand, you’ll need to consider the options for moving forward. As discussed in Lesson 13, sometimes the best choice for the organization is to shut down a troubled project. Termination may be the only option for projects that are troubled due to externalities such as a new import quota that makes it impossible to acquire a required resource or the release of a new technology by a competitor or regulatory changes mid-project that would require significant and costly rework. Certain internal factors, such as a change in organizational strategy, may also be enough to tip the scales in favor of project termination.

In many cases, however, a project in trouble can—and should—be brought under control and rescued from failure. According to Matt Warcholinski, you should move forward with a rescue “when you can extract tradeoffs out of project constraints, and still achieve the result” required by the organization (n.d.). If you have determined that a troubled project still has value for the organization, the next step may be convincing key stakeholders to recommit to the project by clearly articulating the project’s benefits and then developing a plan that will rescue it from failure.

As you develop the plan, consider the value of specific activities so you can identify what you need to stop doing before restarting the project. Doing this frees up resources and gets the team focused on what matters. Be on the lookout for proposed solutions that simply pile on more work and tasks. An example of this is the imposition of more tracking and monitoring to ensure a specific issue does not occur again. While that work may be necessary, make sure it adds value before adding it to the recovery plan. Also beware supposed silver bullets. As noted earlier this appendix, it’s unlikely that a single event or problem pushed the project to the brink of failure. “More often than not, it is a complex entwined set of problems that combine and collectively result in failure” (McGrath and Martin, n.d.). The proposed recovery plan needs to account for that.

Scenario Planning

If significant scope change is being considered, scenario planning (sometimes referred to as “what-if analysis”) with stakeholders can help clarify expectations and avoid unintended consequences. This is particularly important if changes must be made rapidly, under pressure. Running likely outcome scenarios for a range of options (do nothing, implement one or more corrective actions, terminate the project, etc.), with risk probability attached to each, can help you move beyond addressing the symptoms to assessing the implications of the changes being considered.

Scenario planning starts from the premise that the future will not look like the present and can range from “a simple evaluation of the effects of changing the duration of one or more activities to more complex analysis like introducing duration uncertainty, running a project forecast based on performance-to-date” or conducting a schedule and cost risk analysis that takes into account identified project and enterprise risks (Røberg 2017). Assessing the risks and benefits for each of the options before finalizing a recovery plan can be critical to getting a project back on track. Scenario planning can seem like a luxury when a project is failing, but rushing to a decision on the best way to rescue a project in trouble can ultimately make things worse if the project team and stakeholders don’t fully consider the potential impacts and risks of the proposed solutions.

Establishing a Red Team

To combat groupthink and other biases at this critical stage, consider creating an outside red team to assist the project recovery team. As described by Bryce Hoffman in his book Red Teaming, the role of a red team is to “counter ideas and decisions, whether or not they seem correct, with alternative views” (TechTarget 2017). A red team approach helps ensure the recovery team is “taking a hard look at assumptions, examining the ways in which plans could fail, and carefully considering alternative explanations and perspectives” while considering possible scenarios and formulating a rescue plan (Hoffman 2017). You may be able to gain similar benefits working within the recovery team by designating someone to serve as a devil’s advocate, with the goal of encouraging team members to “consider other angles of a problem, to think more deeply about their own views, and perhaps to be stimulated to explore solutions they would not have considered before” (Business News Daily 2020).

Keep in mind, though, that these approaches can only succeed in a strongly collaborative culture, with teammates who trust each other. A confident, flexible team can stand up to the serious critiques offered by a red team or a devil’s advocate and work together to make things better. By contrast, a team made up of know-it-alls who insist on retaining control over every detail is rarely adaptable enough to profit from these approaches. In that case, you might have to step back and decide if you have the right people in the right roles, making changes as necessary before you proceed.

Tiger Teams

More complex, high-priority troubled projects may benefit from a tiger team—an approach that originated with the military and NASA, which famously used a tiger team to safely return the crew of the Apollo 13 lunar mission to earth after the explosion of two oxygen tanks damaged the spacecraft.

A tiger team is typically a small, agile team of cross-functional experts formed to “focus on important, high-profile, high-impact, mission-critical projects.“ The cross-functional expertise of the group allows the tiger team to approach problems on a troubled project from multiple perspectives, making it easier for them to identify and focus on the most critical issues (Lucidchart n.d.).

To learn more about tiger teams, read the article “Understanding the Tiger Team Approach” on the Lucidchart website: https://www.lucidchart.com/blog/what-is-a-tiger-team.

Getting Stakeholder Buy-In

Introducing significant changes on a troubled project requires stakeholder agreement, which you negotiate to achieve (Williams 2011, 185). One likely topic of negotiation at this stage is project scope, including both the deliverables that will be included in the revised project scope and the deliverables that need to be dropped from the project to get things back on track. Other items that may need to be negotiated include a revised budget and schedule, the establishment of new work processes, and decisions about whether to replace a technology or vendor. In the context of a developing a recovery plan, the principled negotiation approach discussed in Lesson 12 can help ease tensions and keep all parties focused on interests—rather than positions—which can be evaluated based on objective standards. Throughout the negotiations, you’ll need to make use of your communication and persuasion skills, as well as your emotional intelligence, to arrive at the optimal solution and get the buy-in necessary to move the project forward.

Developing the Optimal Solution Using the Cynefin Framework

A project at risk of failing has been shaped by the realities of living order. Traditional, geometric order approaches to problem solving may not be enough to get such a project back on track. In Lesson 3 you read about the Cynefin® (pronounced kuh-nev-in) decision-making framework, whose name comes from a Welsh word signifying “the multiple factors in our environment and our experience that influence us in ways we can never understand” (Snowden and Boone 2007). This living order tool offers a flexible approach to understanding the problems on a troubled project and determining the best path forward. Dave Snowden, the creator of the framework, describes it as a “sense-making framework”—a way of looking at reality to identify the type of system in which you are operating in order to understand how you can gain knowledge and determine how you should act (2018).

The Cynefin framework divides system types into five domains:

- Obvious/Clear—Everyone can easily see the relationship between cause and effect, and no one disputes it.

- Complicated—A relationship between cause and effect exists, but it is not self-evident to the decision makers.

- Complex—There is no linear relationship between cause and effect. You determine the correct solution by probing emerging patterns—that is, testing ideas for action through experiments (2018).

- Chaotic—No patterns or constraints exist. Chaotic situations are, according to Snowden, fairly rare (Snowden and Boone 2007).

- Disorder—This is the “state of not knowing what type of system you are in…It’s not the same as a chaotic system…. it may be ordered; you just don’t realize it” (2018).

The Cynefin framework helps you ensure your recovery plan is appropriate to the context or domain in which you are working by providing you information about the types of constraints you are likely dealing with, the most appropriate decision model for your situation, and the types of practices you should apply to resolve the problems.

For more information on the Cynefin framework, you can visit the website of Dave Snowden’s company, The Cognitive Edge (https://www.cognitive-edge.com), or start with this eight-minute video in which Snowden introduces the framework and explains its architecture and function: https://www.youtube.com/watch?feature=youtu.be&v=N7oz366X0-8&app=desktop.

C.4 Finalizing the Recovery Plan

As Todd C. Williams observes in Rescue the Problem Project, “At the core of project recovery is change….Without change, the project will continue to fail.” (2011, 185). Generating the necessary level of change requires a detailed recovery plan, which “is necessarily different from the existing project plan” (10). According to Williams, the recovery plan will “define the areas to fix and recommend changes in the project and product to achieve the desired result,” and should include the following (82, 184):

- The actions already taken

- An enumeration of the deviations from the contract

- Changes to the scope, schedule, and budget

- Financial considerations

- Corrective actions to root causes

- A formal project plan

- High-level schedule

In short, getting the project back on track and avoiding new issues requires a recovery plan with detailed requirements and a clear definition of success—along with established acceptance criteria for the newly established project deliverables. You’ll also need to establish new timelines and budgets, prioritize what to tackle first, reassign or add resources, and communicate new work processes and expectations to the team.

To ensure you create a comprehensive recovery plan, Robert Merrill, a Senior Business Analyst at the University of Wisconsin-Madison, suggests approaching the task as “blank-sheet planning.” As Merrill explains, “You essentially have a new project (including cleaning up the mess left by the old one).” Because you have the benefit of starting with much more knowledge than you had at the start of the original project, however, you will be in a better position to avoid creating yet another troubled project (pers. comm., 3/28/2020).

Even with a blank-sheet planning approach to creating a recovery plan, you will need to make use of many of the original project documents. Documents such as the business case, the contract or statement of work, the project charter, and the project scope statement can offer some much-needed perspective and guidance about the core value the original project was intended to produce, even if those documents need to be revised as part of the recovery plan.

For a more complete discussion of the documentation review required when developing a recovery plan, read this white paper from Surge ERP Consulting, which advocates including a documentation review with key stakeholders and project team members as a first step in a project rescue: http://surge-erp.ca/wp-content/uploads/2016/01/Rescuing_a_Troubled_Project-20160115-FINAL.pdf.

C.5 Implementing the Plan

The details of your recovery plan and how you roll it out will vary considerably depending on the project, your organization, and the industry in which you are working. But no matter what the project, you’ll need to keep an eye out for old problems that resurface and new ones that may be caused by the “solution.” Behavioral issues may reoccur, and some problems, such as unresponsive stakeholders or a troubled technology, may be difficult or impossible to fix (Williams, 2011, 216). You may find that some stakeholders try retain the old scope because they are vested in it and are deluded by the sunk-cost fallacy into thinking that just because they’ve already invested heavily in a particular approach, they should keep investing in it heavily no matter what. Implementing a recovery plan sometimes requires the project manager to be absolutely definitive about killing off the old approach—while at the same time enthusiastically championing the new approach.

The Cynefin framework reminds us that being complacent about initial successes as you begin the process of recovery could cause the entire project to collapse into chaos (Snowden and Boone, 2007). No matter how detailed the plan and how engaged the project team and key stakeholders were in developing the recovery plan, new issues will emerge as the plan is executed. To keep the recovery on track, you’ll need a change management strategy as well as a focus on risk management.

Along with completing technical project management tasks in the implementation stage, you’ll have work to do rebuilding stakeholder trust and team morale. Recall from Lesson 1 that part of working in living order is ensuring the project team members and other stakeholders understand a project’s value and are committed to delivering it. That is even more true as you begin to implement your recovery plan.

Now is the time to stay focused on communication—both to keep stakeholders engaged and to limit the development of new problems and errors that may be a result of a learning curve as team members get a handle on updated activities and processes. Update project documents and ensure only the most current information is available to the team. Outdated materials can be archived for reference. Virtual project websites and project dashboards are excellent tools for providing a single source of information on a project, but only if they are kept up to date. Project teams working in recovery mode are typically reasonably good at putting out new direction, but often fail to clean up outdated information, creating confusion and slowing down the work required to get the project back on track.

C.6 Avoiding Problems on the Next Project

Every project benefits from a geometric order approach to project closure, which emphasizes the importance of systematically preserving lessons learned for future projects. That is especially true of projects that were pulled back from the brink of failure.

Whether related to the core project activity, its execution, or just how the project planning and management succeeded (or didn’t), lessons learned represent vital information that can be used to better plan the next project. In the context of a project, a lesson is knowledge or understanding gained by a positive or negative experience, and it has the following characteristics (Secchi 1999):

- Significant—Has a “real or assumed impact on operations.”

- Valid—Is factually and technically correct.

- Applicable—Identifies a “specific design, process, or decision that reduces or eliminates the potential for failures and mishaps, or reinforces a positive result.”

In a blog post titled, “Lessons Learned in Project Management,” project manager Elizabeth Harrin offers several ideas on capturing and sharing lessons learned: https://www.girlsguidetopm.com/lessons-learned-in-project-management/.

An after-action review (AAR) or an Agile retrospective at the end of a project or individual sprint are just two approaches to working with team members to capture lessons learned. No matter the meeting format, the goal is to have the entire project team reflect on what they learned and what they would do differently on the next project or sprint.

It’s worth noting that documenting lessons learned on a rescued project poses unique challenges as team members may struggle to document issues and mistakes in a way that doesn’t seem like finger-pointing. The key to capturing what was really learned requires being sensitive to context and how that factors into the learning. In the end, those efforts will prove valuable to the organization as well as the project manager and individual team members. As noted by George Watson, a long-time project leader with experience in a wide range of industries, “From almost every failed project, something new emerges that would not have been considered or even feasible prior to the failure. Over the years, I’ve learned that the best time to be a project manager is immediately following a major failure” (pers. comm., May 7, 2020).

From the Trenches: Larry Roth on the Importance of Change Management

Better than capturing lessons learned from a failed or almost-failed project, of course, is planning to prevent the problems from occurring in the first place. Larry Roth, Vice President at Arcadis and former Assistant Executive Director of the American Society of Civil Engineers, summarizes the importance of change management in keeping a project on track, as follows:

“Successful project managers must successfully manage change. To do this, they must recognize that some change is inevitable, and they should be prepared for it by anticipating it before it occurs and then recognizing it when it does happen. Project managers caught off guard by change have often ignored the warning signals until it is too late, or they deny that change is happening for too long.

A good project manager (and team) will take the time very early on in the project to brainstorm about what could go wrong during the project. Chances are they won’t get it right, but they will be far better prepared when trouble occurs; they’ll be looking for it and won’t be taken by surprise. Looking for problems in advance is tough to do. The start of a project is a heady, enthusiastic time and no one wants to think negative thoughts. A good project manager must be disciplined to take the time and make the effort to brainstorm about what could go wrong.

Project managers can help themselves by incorporating change management into the project plan and by using a simple tool such as the risk register, which is an early identification of potential project uncertainties and risks. The risk register, which may take the form of a risk matrix (discussed in Lesson 8), is a living document that is subject to discussion and modification throughout the project. It makes it easier to identify change that is beyond control of the project team and to manage that change in a timely and effective manner. Key risks are anticipated along with identifying the likelihood of the risk event, when the risk event might occur, and the possible impacts on the project. Although these risk tools can never be thorough enough to identify all the havoc to the project that change might wreak, they can be extremely useful in raising the team’s awareness of the inevitability of change and identifying possible actions in advance” (pers. comm., May 17, 2020).

~Practical Tips

- Build trust before a project starts: If you can’t do that, build trust quickly while on the project by being honest and sharing what you know and what you don’t know. Don’t berate people; tell the truth. Ask for help and opinions and then use the information you are given.

- Pay attention to scope creep: Small changes may appear manageable by themselves, but when they build up, they may reach a point where the project is no longer viable in its current form.

- Make sure you have the right people on the recovery team: Before developing and executing the recovery plan, decide if you have the right people in the right roles. Trying to move forward with the same people wearing the same glasses—that is, offering the same perspectives on the project and its problems—may mean that nothing changes. Make adjustments to your team, if possible, so you have a diverse mix of perspectives and skills. You need people who are confident, flexible, and open to collaboration.

- Evaluate the original process: When developing the recovery plan, consider whether the process on the original project was fundamentally flawed, or if it was just being badly executed.

- Take advantage of hindsight: Stop and ask this fundamental question: “If we were planning to do the project from scratch, with these conditions and what we know now, would we do it?” Quite often, people will try to keep a project on life support, but if they were coming to it fresh, in those conditions, they wouldn’t choose to start it at all.

- Insist on evidence: Sometimes a project may not be in as much trouble as people think. Do you have evidence the project is in trouble or do you have evidence it isn’t in trouble? Do you have evidence it is worth fixing? Forcing people to provide tangible evidence to justify their decision helps move them away from just living in hope or fear.

- Watch for technology that isn’t working: Some projects get into trouble because the team is trying to fix the technology at the same time they are implementing it. You can avoid this by making an objective assessment of technology or process maturity at the start.

- Beware of too much complexity: Sometimes projects are more complex than they need to be. For example, you might be asked to implement a new payroll process that uses a new IT platform with changed workflows. Such an omnibus project can fail for a multitude of reasons. Try decoupling the component projects and then execute them separately or in sequence.

- Take action and move on: Too often when a project gets into trouble, there is too much navel gazing and analysis. Make a good-enough decision, and move forward. Burning time on the wrong direction is a high cost for a project in motion.

- Communicate: Implementing a recovery plan requires ongoing and thorough communication. Just as important as providing updates on new processes and approaches is ensuring that old information is removed.

~Summary

- Even the most-successful project managers have likely worked on projects that seemed to spiral out of control. Gradations of trouble on an at-risk project can range from issues caused by a single, major variable—such as the loss of a key team member or a sudden increase in the price of fuel oil—to problems resulting from the interactions of many different variables inside and outside the project.

- These variables can interact in countless ways, making it hard to clearly understand the project’s risks. Cognitive biases, or errors in thinking, can make perceiving risks even more difficult. For example, the planning fallacy can make you feel far more optimistic about a project than reality warrants, while the conservatism bias can cause you to weigh evidence you are already familiar with more heavily than new evidence.

- Daniel Kahneman, a Nobel Prize winner for his groundbreaking work on cognitive biases, has shown that one of the most effective ways to counter the effects of cognitive biases is reference class forecasting, a method of predicting outcomes by setting aside the outcome you and your team predict and instead analyzing the actual outcomes of similar projects. It’s also helpful just to stop and compare your project to a list of known types of problems that often indicate a project is in need of rescue.

- Once you identify a project’s problems, you have to make sure you really understand them. First and foremost, you need to see them in context. That is, you need to understand the extent to which the problems are impacting the project team, the project itself, the program or portfolio, the business unit, the organization, the customer, shareholders and even the general public.

- Once you understand a troubled project’s context, you can look for the root cause of the project’s problems. In this stage, your goal isn’t to “fix” the project by fixing the root cause of its problems—usually an impossible goal—but rather to gain a deeper understanding of the project you are trying to rescue. Without that understanding, you can easily fall into the trap of trying to solve the wrong problem. It helps to take a long view when looking for a root cause, looking back years, if necessary, to find the exact point at which the project began to spin out of control.

- Gaining a clear understanding of the problems you are trying to solve is impossible without engaging with the project team and other stakeholders to get their take on the project’s context and the root causes of its problems. This early engagement is also an essential first step in getting everyone onboard with the changes required to implement a solution, thus increasing your chances of eventual success.

- With a solid understanding of the project’s problems in hand, you’ll need to consider the options for moving forward. Sometimes termination is the best option, but often a well-conceived and managed rescue plan can save a troubled project. If significant scope change is being considered, scenario planning can help clarify expectations and avoid unintended consequences. To combat groupthink and other biases at this critical stage, consider creating an outside red team to assist the project recovery team. Naturally, getting stakeholder buy-in is crucial to successfully implementing any rescue plan.

~Glossary

- confirmation bias—A cognitive bias, or error in thinking, that causes people to pay attention only to information that confirms their preconceptions.

- conservatism—A cognitive bias, or error in thinking, that causes people to weigh evidence they are already familiar with more heavily than new evidence.

- groupthink—A cognitive bias, or error in thinking, that causes people to adopt a belief because a significant number of people already hold that belief.

- outside view—Term used to refer to an outcome forecast generated through reference class forecasting.

- planning fallacy—A cognitive bias, or error in thinking, that causes people to be overly optimistic about their chances of success in an endeavor.

- recovery plan—A plan that defines the areas to fix and recommends changes in the project and product to achieve the desired result (Williams 2011, 82).

- reference class forecasting—A method of predicting outcomes by setting aside the outcome you and your team predict and instead analyzing the actual outcomes of similar projects.

- root cause—“The core issue—the highest-level cause—that sets in motion the entire cause-and-effect reaction that ultimately leads to the problem(s)” (American Society for Quality n.d.).

- root cause analysis— “A collective term that describes a wide range of approaches, tools, and techniques used to uncover causes of problems” (American Society for Quality n.d.).

~References

Ackoff, Russell L. 1974. Redesigning the Future: A Systems Approach to Societal Problems, Volume 10. Hoboken: Wiley.

Alexander, Moira. 2019. “How to Deliver Bad News to Project Stakeholders.” TechRepublic. August 19. https://www.techrepublic.com/article/how-to-deliver-bad-news-to-project-stakeholders/.

American Society for Quality. n.d. “Cause Analysis Tools.” American Society for Quality. Accessed April 21, 2020. https://asq.org/quality-resources/root-cause-analysis/tools.

—. “What is Root Cause Analysis (RCA)?.” American Society for Quality. Accessed April 28, 2020. https://asq.org/quality-resources/root-cause-analysis.

Anderson, Tim. 2018. “How to Avoid Product Manager Burnout.” Jama Software. January 23. https://www.jamasoftware.com/blog/avoid-product-manager-burnout/.

Ballestrin, Kim. 2015. “Using Cynefin to Solve Problems While Navigating Uncertainty.” The Lean Post. July 28. https://www.lean.org/LeanPost/Posting.cfm?LeanPostId=444.

Business News Daily. 2020. “Speak Up! Dissension Is Key to Successful Teamwork.” Business News Daily. March 6. https://www.businessnewsdaily.com/8594-dissenting-voice-teamwork.html.

Clarizen. 2019. “How to Spot Project Failure Early.” Clarizen. July 14. https://www.clarizen.com/how-to-spot-project-failure-early/.

Cook, Matthew, and John P.T. Mo. 2018. “A Systems Approach to Life Cycle Risk Prediction for Complex Engineering Projects.” Cogent Engineering. March 26. https://www.tandfonline.com/doi/full/10.1080/23311916.2018.1451289.

Dolfing, Henrico. 2019. “Case Study 6: How Revlon Got Sued by Its Own Shareholders Because of a Failed SAP Implementation. Medium. August 8. https://medium.com/@henricodolfing/case-study-how-revlon-got-sued-by-its-own-shareholders-because-of-a-failed-sap-implementation-58b66f1267fa.

Funcheon, Deirdra. 2019. “NTSB: Fatal Miami Bridge Collapse Caused By ‘A Paralyzing Culture of Group-Think’.” Bisnow. October 23. https://www.bisnow.com/south-florida/news/construction-development/miami-bridge-collapse-fiu-101395.

Harrin, Elizabeth. n.d. “How to Save a Failing Project.” LiquidPlanner. https://www.liquidplanner.com/explore/resources/how-to-save-a-failing-project/.

Hoffman, Bryce G. 2017. “Red Teaming.” Bryce G. Hoffman. https://brycehoffman.com/books/red-teaming/.

Kenny & Company. 2012. “Warning Signs of Project Failure and Resolution Methods.” Kenny & Company. July 23. https://michaelskenny.com/points-of-view/warning-signs-of-project-failure-and-resolution-methods/.

Larson, Erik W., and Clifford F. Gray. 2011. Project Management: The Managerial Process, Sixth Edition. New York: McGraw-Hill Education.

Laufer, Alexander. 2012. Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results. Upper Saddle River: FT Press.

Leitch, Rebecca. 2017. “The Five Warning Signs of Strategic Project Failure – And How to Avoid Them.” Strategy Execution. July 27. https://www.strategyex.co.uk/blog/pmoperspectives/the-five-warning-signs-of-strategic-project-failure-and-how-to-avoid-them.

Linanne, Ciara. 2019. “Revlon Shares Slide 6.9% After Report of Material Weakness in Financial Controls.” MarketWatch. March 24. https://www.marketwatch.com/story/revlon-shares-slide-65-after-report-of-material-weakness-in-financial-controls-2019-03-19.

Lloyd-Walker, Beverly, Anthony Mills, and Derek Walker. 2014. “Enabling Construction Innovation: The Role of a No-Blame Culture as a Collaboration Behavioural Driver in Project Alliances.” Construction Management and Economics. 32 (3). https://www.researchgate.net/publication/262576462_Enabling_construction_innovation_The_role_of_a_no-blame_culture_as_a_collaboration_behavioural_driver_in_project_alliances.

Lovallo, Dan & Kahneman, Daniel. 2003. “Delusions of Success: How Optimism Undermines Executives’ Decisions.” Harvard Business Review. (June.) https://hbr.org/2003/07/delusions-of-success-how-optimism-undermines-executives-decisions.

McGrath, John, and Philip Martin. n.d. “Project Failure: A Catalyst for Success.” Project Times. Accessed April 25, 2020. https://www.projecttimes.com/articles/project-failure-a-catalyst-for-success.html.

National Highway Transportation Safety Board (NTSB). 2019. “Highway Accident Report: Pedestrian Bridge Collapse Over SW 8th Street, Miami, Florida, March 15, 2018.” NTSB. https://www.ntsb.gov/investigations/AccidentReports/Reports/HAR1902.pdf.

Nelson, John. 2020. Interview by Ann Shaffer and Mary Pat Shaffer. (July 29).

Røberg, Oyvind. 2017. “How What-If Scenario Analysis Improves Project Management.” Safran. September 25. https://www.safran.com/blog/how-what-if-scenario-analysis-improves-project-management.

Saran, Cliff. 2019 “SAP Disruption Leads to Revlon Class Action Lawsuit.” ComputerWeekly. May 31. https://www.computerweekly.com/news/252464278/SAP-disruption-leads-to-Revlon-class-action-lawsuit.

Seador, Gregory. 2019. “Avoiding Construction Project Disputes.” Risk Management. October 1. http://www.rmmagazine.com/2019/10/01/avoiding-construction-project-disputes/.

Secchi, P., ed. 1999. “Proceedings of Alerts and Lessons Learned: An Effective way to Prevent Failures and Problems. Technical Report WPP-167.” Noordwijk, The Netherlands: ESTEC.

Snowden, David. 2018. “Cynefin® Introduction by Dave Snowden.” Cognitive Edge. http://cognitive-edge.com/videos/cynefin-framework-introduction/.

—. 2019. “Cynefin St David’s Day 2019 (1 of 5).” Cognitive Edge. March 5. https://cognitive-edge.com/blog/cynefin-as-of-st-davids-day-2019/.

Snowden, David J., and Mary E. Boone. 2007. “A Leader’s Framework for Decision Making.” Harvard Business Review. https://hbr.org/2007/11/a-leaders-framework-for-decision-making.

Techliance. n.d. “Major ERP Failures to Learn from for Better Implementation.” https://techliance.com/blog/erp-failures/.

TechTarget. 2017. “Red Teaming.” WhatIs.com. https://whatis.techtarget.com/definition/red-teaming.

Virine, Lev, Michael Trumper, and Eugenia Virine. 2018. “Heuristics and Biases in Project Management.” PM World Journal. VII (1): 1-11. https://pmworldlibrary.net/wp-content/uploads/2018/01/pmwj66-Jan2018-Virines-heuristics-and-biases-in-project-management.pdf.

Warcholinski, Matt. n.d. “Troubled IT Projects: When to Rescue & When to Abandon.” Brainhub. https://brainhub.eu/blog/troubled-it-projects-when-to-rescue/.

Weber, Rosina. 2001. “An Intelligent Lessons Learned Process.” ScienceDirect. vol. 20, no.1, pp 17-34. https://www.sciencedirect.com/science/article/abs/pii/S0957417400000464?via%3Dihub.

Williams, Todd C. 2011. Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure. New York: AMACOM.

4

Appendix D - Learning from Our Students

The following former students graciously shared their thoughts on how their work has been affected by this book and by the Technical Project Management class they took as part of the Master in Engineering Management program at the University of Wisconsin–Madison:

- John P. Dolan, Professional Engineer, United States Air Force

- Lindsay Feldt, Project Engineer, Better by Design, LLC

- Michele Kaiser, Program Manager – Backhoes, John Deere Worldwide Construction and Forestry Division

- John Kruse, Mechanical Engineer III, KaVo Kerr Group

- Alexandre Ledoux, Ph.D., Mechanical Engineering Manager, KaVo Kerr Group – Imaging

- Benjamin Ludy, Engineering Manager, Milwaukee Tool

- David Pagenkopf, Director – Application Development, University of Wisconsin–Madison

If you’d like to contribute to future editions of this appendix, please contact Jeffrey Russell at jeffrey.russell@wisc.edu.

What part of the Technical Project Management course was most helpful?

John P. Dolan, Professional Engineer, United States Air Force

The most helpful parts of Technical Project Management were the introduction of the idea of living order, Lean thinking, how to determine value and success for a customer, and the return to the fundamentals of project scheduling. In my daily job leading other project managers, I often get trapped into putting out fires instead of being able to focus on the big picture fundamentals, what the customer truly values, which will bring about project success or failure.

I had also never been introduced to the ideas of Lean project management before this class. I find this train of thought to be fascinating, and it could be truly revolutionary for the civil engineering and construction industry if enough sponsors of the idea can be recruited to change the direction of companies.

Lastly, I haven’t had the chance to refocus on my own project management and scheduling skills for a while. I’ve been focused on the day-to-day and don’t often get a chance to sharpen my own skills because I am required to concentrate on the performance of other individuals. It was great to relearn project scheduling—in particular, scheduling from backwards to forwards—and incorporating a living order approach in a geometric order world. I’m a big believer that if someone can do the fundamentals of their job exceptionally well, success will almost be guaranteed. This course gave me a chance to refocus on the fundamentals of project management, focus on my own development, and then bring new ideas to my work place, where no significant changes in project management have occurred in many years.

Lindsay Feldt, Project Engineer, Better by Design, LLC

Walking through each step involved in managing a technical project from initiation to completion (and beyond) was advantageous. Learning about the living order methods in conjunction with the more traditional geometric order methods was very effective. It was clear that both approaches are beneficial depending on the situation and the environment. In the manufacturing environment, I was only previously exposed to the geometric order, so it was helpful to learn about living order methods as well. I have found the planning and scheduling phases especially beneficial in strengthening my role as a technical leader within my company.

Michele Kaiser, Program Manager – Backhoes, John Deere Worldwide Construction and Forestry Division

The team project, in which we used an applicable industry project to apply the lessons from the course, was the most useful for me. It allowed me to relate the course concepts immediately to a work-related project.

John Kruse, Mechanical Engineer III, KaVo Kerr Group

I found project management to be more than the sum of its parts. No one lesson was a knockout revelation, but when put together, the concepts were very useful.

Alexandre Ledoux, Ph.D., Mechanical Engineering Manager, KaVo Kerr Group – Imaging

I found the explanations of the different methods used to run projects to be very helpful. A review of traditional planning vs. Agile methodologies was also useful. Finally, completing a project with a team was very helpful for me.

Benjamin Ludy, Engineering Manager, Milwaukee Tool

For me, working though the group project simulation was the most helpful. Being able to apply the concepts of the class with a subgroup of the cohort was great for making the concepts stick.

Dave Pagenkopf, Director – Application Development, University of Wisconsin–Madison

Integrating the various Technical Project Management course components in the course project was the most helpful for me. In particular, I learned a lot about how to communicate with project sponsors and other key stakeholders, in part by creating a succinct and cohesive plan. When combined with practical metrics and a professional presentation, the project plan can tell a credible and compelling story. I have used these skills in other professional realms beyond project management.

What have you continued to learn more about since completing the class?

John P. Dolan, Professional Engineer, United States Air Force

Since completing the class, I’ve spent the most time learning more about Lean thinking and Lean project management. Since being introduced to the idea, I’ve read several books on the topic and proposed changes in my own organization. There is so much waste in the construction industry and in federal government organizations, yet no one is willing to change. As I’ve learned in Technical Project Management, culture eats process every time, and this is proven day-in and day-out in the military. Even though everyone knows we waste money, do things that are pointless, and execute projects in the wrong manner, no one will change because the organizational momentum is so strong. “We’ve always done it this way” and “No one else will change if we do” have met at every juncture when I’ve tried to propose change. And guess what? Culture always won.

Lindsay Feldt, Project Engineer, Better by Design, LLC

I have been able to apply nearly every aspect of Technical Project Management to my job. The concepts of risk management appealed to me during class, and I have since tried to learn more about these strategies in order to apply them better. I have identified some real inadequacies at my company when it comes to preparing for and recognizing possible project risks and am working with my team to come up with a better risk management strategy. There are plenty of opportunities for improvement, with every project bringing new and unique challenges. I am learning as I go about what works well and what doesn’t in real-world projects.

Michele Kaiser, Program Manager – Backhoes, John Deere Worldwide Construction and Forestry Division

Since completing the class, I’ve learned about managing schedules with a cross-functional team, using the John Deere enterprise product development process, risk assessments, milestone/gate readiness checklists, leadership reviews, and authorization for expenditure reviews for senior level management. On top of those program management related items, I’ve gained the most experience in program/project financials since completion of the course.

John Kruse, Mechanical Engineer III, KaVo Kerr Group

I had always viewed the change and chaos of project management as stemming from a lack of appropriate guidance or leadership, but once I embraced the dynamic situation, I began to see new opportunities.

Alexandre Ledoux, Ph.D., Mechanical Engineering Manager, KaVo Kerr Group – Imaging

I learned a lot about Agile and its implication outside Software Engineering project tracking. For a project for another course, I focused on Agile methodologies for Mechanical Engineering. Also, as part of our leadership team, I am working on adapting our project tracking methods to better communicate project completion dates to upper management.

Benjamin Ludy, Engineering Manager, Milwaukee Tool

I have been working on scoring our projects in a single database after they are completed. I focus on estimated versus actual for both schedule and cost. This has helped me understand which types of projects are underperforming. Using that information, I can figure out why they are underperforming, and then make changes designed to improve them. Without the tracking database, these insights into underperforming projects would be impossible.

Dave Pagenkopf, Director – Application Development, University of Wisconsin–Madison

Living order was introduced after I took the course, so I have been learning more about the topic on my own and then integrating that thinking into my leadership practices and expectations. These topics have never been covered in any project management course I have taken in my career. Integrating living order concepts with traditional project management skills is a welcome addition to the course and will prove valuable to graduates of the course. There is now a vocabulary for living order, making it much easier to talk to others about this important topic.

Do you have any new insights related to what you learned in the class?

John P. Dolan, Professional Engineer, United States Air Force

See above in relation to project management, how much waste there is in the civil engineering and construction industry, and the importance of culture. I’ve proposed many ideas to inject Lean thinking into my organization, eliminating waste, and changing the way business is done. But, if I haven’t had sole administrative and operation control over the people and process, there’s been no change. Existing culture won every time.

Michele Kaiser, Program Manager – Backhoes, John Deere Worldwide Construction and Forestry Division

Having worked as a program manager for almost two years now, after having come from an engineering and engineering management background, I have a much better appreciation for how complex project and program management can be, especially when using common resources for multiple projects simultaneously. I’ve honed skills relative to crashed schedules and proactive planning for schedule and resource risks.

John Kruse, Mechanical Engineer III, KaVo Kerr Group

The biggest thing I have picked up after class is that even in a company with a relatively strong project management culture, many leaders are still poorly versed in some of the foundational concepts I learned in class. This creates opportunities to improve internal process and delivery, but can create short term tension or delays when having to explain improved methods or hidden risks of the old ways of doing things. Institutional memory is hard to change and many things I had assumed were just working smoothly behind the curtain of project management were actually in need of significant attention.

Alexandre Ledoux, Ph.D., Mechanical Engineering Manager, KaVo Kerr Group – Imaging

I enjoyed the class in general. While it was a lot of work to catch up on all the traditional methods, the time spent learning new things was worthwhile, especially in the comparison of push vs pull planning. Something that was not explicitly taught but came with the class is the creation of professional relationships while projects are completed. For example, I am still talking or texting daily with my Technical Project Management team members on several topics, both for school and for work. Spending a lot of time working on complex management projects helps build teams one project at a time.

Dave Pagenkopf, Director – Application Development, University of Wisconsin–Madison

I had been leading and working on projects for 20 years prior to the course, had my Project Management Professional (PMP) certification for 9 years, and had taken numerous other project management courses. I mistakenly thought there wasn’t much else to learn and the course would be a waste of my time. Instead, the course quickly revealed several areas where I needed to improve my project leadership skills because my practices were not as mature and polished as I thought. Plus, some of my knowledge was dated. It was a very humbling experience. My key insight is to always maintain a learner’s mindset: be open to new ideas, other perspectives, and different ways of doing things.

Can you give one specific example of a situation in which something you learned in the class affected your project management skills on the job?

John P. Dolan, Professional Engineer, United States Air Force

One particular example where I’ve applied some of my new Technical Project Management skills is when I teach people who work for me about project scheduling. I did this today. Instead of focusing only on a start to finish project schedule, I teach people to think about the project from finish to start, and then vice versa. Schedule the project both ways! This gives them a new perspective on how to view the project and estimate required time and tasks. They don’t get trapped in an A leads to B, then B to C mindset. Instead, they think forwards and backwards, and can see how different items can be executed simultaneously.

Another example is Lean thinking. Ever since taking Technical Project Management, I’ve placed a much higher importance on what the customer needs, what they find valuable, and their requirement. Instead of being focused on the “What they want,” I’ve spent more time on the “Why they need it.” I’ve definitely benefited from this because it’s kept me centered on providing what the customer needs and really helping them identify what they need from me and how I can help them get it.

Lindsay Feldt, Project Engineer, Better by Design, LLC

I took a new position as a project engineer last March in the hopes of eventually moving into a managerial position after completing my graduate degree and gaining more experience within my company. No one at my company is familiar with Microsoft Project, so I volunteered to create some project schedules using the skills learned in Technical Project Management. My boss was very impressed after the successful completion of these projects and asked if I was interested in accelerating my move into the Director of Engineering position to early this next year.

Michele Kaiser, Program Manager – Backhoes, John Deere Worldwide Construction and Forestry Division

Schedule crashing! This is a common occurrence with “pull” projects where your end date cannot be moved. In our case, we had an emissions project that had to be pulled ahead several months in order to meet regulations. I led the cross-functional team in finding different ways to manage the project effectively, despite having less time.

John Kruse, Mechanical Engineer III, KaVo Kerr Group

I am a sub manager on a project team under a PM who is highly skilled but is somewhat new to the company. Over the last year, we encountered pretty much every type of internal and external obstacle noted in class and a handful of black swans. While I was not the main leader, I was able to see nearly every chapter in this book play out. More often than not, the end solution was exactly what was prescribed in the text, only it took us days or weeks to recognize the situation, propose new-to-the-company management ideas, and get buy-in from stakeholders who I had previously assumed would have already known better. It was really exciting seeing the principles in class play out for a seasoned PM and personally being able to provide support and justification of the concepts to the rest of the organization.

Alexandre Ledoux, Ph.D., Mechanical Engineering Manager, KaVo Kerr Group – Imaging

I implemented the use of Jira, an Agile tool typically used by software engineering for the tracking of our mechanical engineering activities. This provided a centralized tool for all our department activities (Software and ME at this time). Based on current results, the electrical team will probably do the same. While Jira was not explicitly mentioned, the use of pull planning and Agile scheduling was addressed in class.

Benjamin Ludy, Engineering Manager, Milwaukee Tool

At Milwaukee Tool, most of our engineering work is standardized and there is little variation from project to project. As such, we do not use formal WBS tools. However, I had a project manager on my team struggling to define a project that had an usual scope. We outlined a WBS together and used that as the starting point. From there, he was able to map out the project and come up with a solid plan. Recognizing that the work package was different was necessary before a schedule could be created. Jumping straight to a schedule document was not working and, instead, was counterproductive.

Dave Pagenkopf, Director – Application Development, University of Wisconsin–Madison

Prior to taking the course I was a coauthor for an IT project proposal. We had to present our proposal to the company’s Chief Financial Officer for funding and approval. The project was a multi-year effort that would cost several million dollars. However, the payback in IT operational cost savings would be quick. It made perfect sense to us and we thought it would be an easy sell to our CFO. Despite our enthusiasm for the project, the CFO was not impressed and rejected our proposal. Further, he gave us quite a dressing down for advancing a poor business case and wasting his time.

After completing the Technical Project Management course, my colleague and I revised our proposal and made another pitch to our CFO. We applied the ideas in the course on preparing and presenting proposals, plans, and financial reports for an executive-level audience. After our presentation, the CFO funded the project and he gave us accolades for preparing an excellent proposal; he said it should be a model for other IT projects. The scope of the project hadn’t changed, but instead we tailored our proposal to our audience, eliminated the IT jargon, clearly identified the benefits, and were specific about how we would realize the benefits.

Do you have any advice to offer new technical project managers based on your on-the-job experience?

John P. Dolan, Professional Engineer, United States Air Force

First, remember to take time to focus on improving your own skills. If you aren’t taking the time to improve yourself, you’ll never become a better project manager, and your skills will remain secondary.

Secondly, success is always defined by the customer, not you. It doesn’t matter if your project is under budget, completed early, or looks beautiful if it doesn’t provide the customer what they need. Remain focused on the customer’s requirement(s), what they value, and how you can help them achieve their goals. If you remain focused on that, instead of how many pretty PowerPoint Slide presentations you can make when scheduling a road closure, your project will always be successful.

Lindsay Feldt, Project Engineer, Better by Design, LLC

Organization and planning are so important. Many of the themes discussed in Technical Project Management are focused around forethought and being proactive about issues that can and do come up in any technical project. I have put these to practice and found I am learning to adapt to project change more smoothly. Instead of having to react hastily, I’ve found it is much better to be prepared, have a plan, and stay organized.

Michele Kaiser, Program Manager – Backhoes, John Deere Worldwide Construction and Forestry Division

Here are my top rules to live by:

- Everything in program/project management requires flexibility, agility, and the ability to make a quick decision.

- Relationships are the currency for getting things done! Know people and build trust. Advocate for your team!

- Make sure you know the difference between whining and when something actually needs to change (i.e. adding more time to the schedule).

- Know who your peers are and benchmark them – you don’t have to do what they do, but you should know what they do. Apply what works well for you and your team.

- Take the blame when things don’t go well and share the credit when they do.

- Be you and be comfortable in your leadership style.

- Above all, stay positive—your team is following your cue!

John Kruse, Mechanical Engineer III, KaVo Kerr Group

Don’t assume “more experienced” colleagues or managers know the material covered in this book. When something doesn’t feel right, take a stand, propose incremental improvements, and try to build a reputation as a thoughtful process person. That said, you will have to learn to live with some processes or practices that you now know to be less than ideal.

Alexandre Ledoux, Ph.D., Mechanical Engineering Manager, KaVo Kerr Group – Imaging

Don’t get stuck on one type of project management. Adapt your techniques and tools based on your company and your team. Create a mix between pull and push planning to keep engagement high, and transition slowly to your preferred style over time with the support of your organization.

Benjamin Ludy, Engineering Manager, Milwaukee Tool

My advice would be to keep it as simple as possible and then add in more sophisticated tools as needed. All projects can be broken down to what is being done, by whom, and by when. This should always be clear regardless of project type or the tools/processes being used. Make sure the tools that you do decide to use are working for you and the team and not vise-versa.

Dave Pagenkopf, Director – Application Development, University of Wisconsin–Madison

Don’t become complacent. You will never know everything. Maintain an open mind, learn from your mistakes, and do better next time.

For example, when I started working on software projects, no one had heard of Agile methodology. Today, most software projects use Agile, and the project management practices that go with it are going through a transition. We are all having to learn new techniques and practices. It is stressful at times, and we make mistakes. We are impatient with the pace of change. However, it must be done.

5

Glossary

A  |  B  |  C  |  D  |  E  |  F  |  G  |  H  |  I  |  J  |  K  |  L  |  M
N  |  O  |  P  |  Q  |  R  |  S  |  T  |  U  |  V  |  W  |  X  |  Y  |  Z

active control—A focused form of project control that involves the following: 1) controlling what you can by making sure you understand what’s important, taking meaningful measurements, and building an effective team focused on project success; and 2) adapting to what you can’t control through early detection and proactive intervention.

activity—“An element of work performed during the course of a project. An activity normally has an expected duration, an expected cost, and expected resource requirements” (Project-Management.com 2016). Beware that some organizations subdivide activities into tasks, while others use task and activity synonymously.

adaptive management—A framework of flexible decision-making for ongoing knowledge acquisition, monitoring, and evaluation. It requires continuous improvement in planning, design, and operation to ensure specified objectives are achieved.

Agile—A project management methodology that emphasizes an iterative approach to product development, with the project specifications evolving along with the customer’s notion of the software requirements. There are many flavors of Agile, but the most widely used is Scrum.

Agile engineering—A new form of product development that makes use of the interative cycles of fast feedback and revisions first implemented in Agile software development. It encourages teams to learn about their product and make improvements faster than they could with traditional product development.

arbitration—A dispute-resolution method in which the disputing parties agree to let a neutral third party make a final decision.

audit—A deep investigation into any or all aspects of a project, with the aim of enabling stakeholders to make fully informed decisions about the project’s future. An audit can provide a focused, objective review of part or all of a project.

audit report—A report created at the end of an audit that typically contains: an explanation of the context of the audit, including the overall focus or any important issues; an analysis of data, interviews, and related research compiled during the audit; action-oriented recommendations; and, in some cases, lessons learned and possibly one or more supporting appendices.

behavioral economics—According to OxfordDictionaries.com, “a method of economic analysis that applies psychological insights into human behavior to explain economic decision-making.”

black swan event—Term used by Nassim Nicholas Taleb in his book Black Swan: The Impact of the Highly Improbable to refer to the most extreme form of externality. According to Taleb, a black swan event has the following characteristics: it is an outlier, unlike anything that has happened in the past; it has an extreme impact; and, after it occurs, people are inclined to generate a rationale for it that makes it seem predictable after all (2010, xxii).

bottom-up estimate—“Detailed cost estimate for a project, computed by estimating the cost of every activity in a work breakdown structure, summing these estimates, and adding appropriate overheads” (Business Dictionary n.d.). A bottom-up estimator starts by dividing the project up into tasks, then estimates a cost for each task, and sums the total costs for all the project tasks.

budget—The funds that have been allocated for a project.

business case—An “argument, usually documented, that is intended to convince a decision maker to approve some kind of action. The document itself is sometimes referred to as a business case. As a rule, a business case has to articulate a clear path to an attractive return on investment (ROI). At its simplest, a business case could be a spoken suggestion…. For more complex issues, a business case should be presented in a carefully constructed document. A business case document should examine benefits and risks involved with both taking the action and, conversely, not taking the action. The conclusion should be a compelling argument for implementation” (TechTarget n.d.).

Capability Maturity Model (CMM)—The first widely used maturity model, developed in the software industry in the late 1980’s by the Software Engineering Institute (SEI) at Carnegie Mellon University and the United States Department of Defense.

capacity—The “maximum level of output that a company can sustain to make a product or provide a service. Planning for capacity requires management to accept limitations on the production process. No system can operate at full capacity for a prolonged period; inefficiencies and delays make it impossible to reach a theoretical level of output over the long run” (Investopedia n.d.).

change management—“Minimizing resistance to organizational changes through the involvement of key players and stakeholders” (Business Dictionary).

close-out meeting—An opportunity to end a project the way you started it—by getting the team together. During this important event, the team should review what went well, what didn’t go well, and identify areas for improvement. All of this should be summarized in the final close-out report. A final close-out meeting with the customer is also essential. This allows the organization to formally complete the project and lay the groundwork for potential future work.

close-out report—A final summary of project performance. It should include a summary of the project and deliverables; data on performance related to schedule, cost, and quality; a summary of the final product, service, or project and how it supports the organization’s business goals; risks encountered and how they were mitigated; and lessons learned.

cognitive reframing–The process of reconsidering events and facts to see them in a new way.

compliance program–A formalized program designed to ensure that an organization and its employees adhere to government regulations, follow all other laws, and behave ethically.

compress a schedule–The process of taking a schedule you have already developed and reducing it without adjusting the project’s scope.

confirmation bias—A cognitive bias, or error in thinking, that causes people to pay attention only to information that confirms their preconceptions.

consensus building—A “conflict-resolution process used mainly to settle complex, multiparty disputes” (Burgess and Spangler 2003).

conservatism—A cognitive bias, or error in thinking, that causes people to weigh evidence they are already familiar with more heavily than new evidence.

context—According to Merriam-Webster, the “situation in which something happens: the group of conditions that exist where and when something happens.”

contingency fund—A financial reserve that is allocated for identified risks that are accepted and for which contingent or mitigating responses are developed. Contingency funds are also often available to pay for an agreed-upon scope change.

contingency plan—1) A plan for an alternative route to project success that can be implemented if an obstacle to progress arises. 2) Resources set aside to cover unanticipated costs.

contingency planning—The development of alternative plans that can be deployed if certain risks are realized (e.g., parts from a supplier do not meet quality requirements).

contract—According to Merriam-webster.com, “a binding agreement between two or more persons or parties.” A contract can take many forms, ranging from a submitted invoice (which can serve as a binding agreement) to 200 pages of legal language plus appendices.

controlling—In the monitoring and controlling phase of project management, the process of making changes in response to data generated by monitoring tools and methods to avoid missing major milestones.

core concerns—According to Roger Fisher and Daniel Shapiro, “human wants that are important to almost everyone in virtually every negotiation. They are often unspoken but are no less real than our tangible interests” (2005, 14). Fisher and Shapiro focus on the following five core concerns: appreciation, affiliation, autonomy, status, and role.

cost—“An expenditure, usually of money, for the purchase of goods or services” (Law 2016). Note that, like all terms, the meaning of “cost” varies somewhat from industry to industry. For example, in product development, the term has three specific meanings: 1) cost to create the product or project; 2) cost to establish a manufacturing cell capable of producing the product; and 3) cost of the final good or service to the market.

cost of conformance—The cost of good quality, which includes the cost of preventing quality defects as well as the cost of appraising or detecting defects in the project deliverables or processes.

cost of nonconformance—The cost of poor quality, which is a result of quality failures—both during and after the project.

cost of quality—The cost of delivering on the quality requirements of the project. The cost of quality, including the costs of conformance and the costs of nonconformance extend beyond the project and accrue over the life of the product of the project.

cost-plus—An agreement in which the contractor or seller “is reimbursed for all direct allowable costs (materials, labor, travel) plus an additional fee to cover overhead and profit. This fee is negotiated in advance and usually involves a percentage of the total costs” (Larson and Gray 2011, 452). In small projects, this arrangement is sometimes referred to as time and materials.

crashing—A schedule compression technique that involves adding resources such as overtime or more equipment to speed up the schedule. Because of the costs involved in adding resources, crashing is “the technique to use when fast tracking has not saved enough time on the project schedule. With this technique, resources are added to the project for the least cost possible” (Monnappa 2017).

critical path—The “series of activities which determines the earliest completion of the project” (Project-Management.com 2016).

DBOM (Design, Build, Operate, Maintain)—A type of partnership in which a private organization builds a facility and operates it on behalf of the public for as long as 20 years. DBOM partnerships have been used since the mid-1980s to construct and operate waste-to-energy projects that transform trash into electrical power.

DBOOM (Design, Build, Own, Operate, Maintain)—A new variation on DBOM which makes it possible for public or private organizations to finance and operate huge undertakings like infrastructure, energy, or transportation projects.

direct costs—“An expense that can be traced directly to (or identified with) a specific cost center or cost object such as a department, process, or product” (Business Dictionary n.d.). Examples of direct costs include labor, materials, and equipment. A direct cost changes proportionately as more work is accomplished.

direct project overhead costs—Costs that are directly tied to specific resources in the organization that are being used in the project. Examples include the cost of lighting, heating, and cleaning the space where the project team works. Overhead does not vary with project work, so it is often considered a fixed cost.

dispute resolution—A “process for resolving differences between two or more parties or groups” (Business Dictionary n.d.).

duration—“The time needed to complete an activity, path, or project” (Larson and Gray 2011, 659).

Earned Value Management (EVM)—An effective method of measuring past project performance and predicting future performance by calculating variances between the planned value of a project at a particular point and the actual value.

emergent leaders—People who emerge as leaders in response to a particular set of circumstances.

emotional intelligence—The ability to recognize your own feelings and the feelings of others.

estimate—An assessment of the likely budget for a project. An estimate involves counting and costing and is based on ranges and probabilities. Throughout a project, managers and team members are asked to estimate remaining work, cost at completion, and required remaining time. An estimate is a forward projection, using what is known, to identify, as best as possible, the required effort, time, and/or cost for part or all of a project.

ethics—According to Merriam-Webster, a “set of moral principles: a theory or system of moral values.”

event-driven—Term used to describe a project that unfolds in response to changing events.

exit champion—A manager who is charged with advocating the end of a project if he or she thinks that is in the best interests of the organization, regardless of the desires of the project team members.

fast tracking—A schedule compression technique in which “activities that would have been performed sequentially using the original schedule are performed in parallel. In other words, fast tracking a project means the activities are worked on simultaneously instead of waiting for each piece to be completed separately. But fast tracking can only be applied if the activities in question can actually be overlapped” (Monnappa 2017).

fixed resource—A resource that “remains unchanged as output increases” (Reference n.d.).

fixed price: An agreement in which the contractor or seller “agrees to perform all work specified in the contract at a fixed price” (Larson and Gray 2011, 451).

float—See slack.

genchi genbutsu—A key principle of the famously Lean Toyota Production System, which means “go and see for yourself.” In other words, if you really want to know what’s going on in a project, you need to actually go to where your team is working, and then watch and listen.

general and administrative (G&A) overhead costs—The “indirect costs of running a business,” such as IT support, accounting, and marketing” (Investing Answers n.d.).

geometric order—A type of order identified by the French philosopher Henri Bergson that is characterized by linear development, clear cause and effect, and predictable events.

gold plating—Adding functionality that exceed a project’s requirements, “possibly even beyond what is practical or reasonable for the effort” (Egeland 2013).

group think—A type of cognitive bias that causes people to adopt a belief because a significant number of people already hold that belief.

idea averaging—Taking a little from one idea, and a little from another, and a little from another—without fully committing to any.

information–based bargaining—An effective type of negotiation described by G. Richard Shell in his book Bargaining for Advantage, which focuses on “three main aspects of negotiation: solid planning and preparation before you start, careful listening so you can find out what the other side really wants, and attending to the ‘signals’ the other party sends through his or her conduct once bargaining gets under way” (Shell 2006, xviii-xix).

informed intuition—A combination of information and instinctive understanding. You develop informed intuition through experience and by constantly learning about your individual projects, your teammates, your organization, and your industry.

Integrated Project Delivery—A Lean-oriented contractual arrangement that emphasizes collaboration among all participants from the very earliest stages of the project, and that encourages participants to help solve each other’s problems, taking a proactive approach to risk (Thomack 2018).

intention-driven—Term used to describe a project that unfolds according to the single-minded intention of the project manager.

Internet of things (IoT)—The “system of interrelated computing devices, mechanical and digital machines, objects, animals or people that are provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction” (TechTarget n.d.).

issue—A known concern, something a team will definitely have to address. Compare to a risk, which is caused by external factors that the project team cannot fully identify.

iterative estimating—A combination of top-down and bottom-up estimating, which involves constant refinement of the original estimate by taking into account information typically used in a top-down estimate (such as past history of similar projects) and increasingly detailed information generated by bottom-up estimating.

key performance indicator (KPI)—A metric associated with a specific target (Gonzalez).

knowledge management—The “planning, organizing, motivating, and controlling of people, processes, and systems in the organization to ensure that its knowledge-related assets are improved and effectively employed” (King 2009).

Last Planner System (LPS)—A proprietary production planning system that exemplifies living order concepts and pull thinking; developed by Glenn Ballard and Greg Howell as a practical implementaion of Lean principles.

last responsible moment—“The instant in which the cost of the delay of a decision surpasses the benefit of delay; or the moment when failing to make a decision eliminates an important alternative” (Lean Construction Institute).

Lean—A business model and project management philosophy that offers a means to streamline projects while allowing for the flexibility required to deal with unexpected events. It emphasizes the elimination of waste through the efficient flow of work from one phase of a project to another.

learning—“Increasing one’s capacity to take effective action” (Kim 1993).

learning organization—According to David A. Garvin, “an organization skilled at creating, acquiring, and transferring knowledge, and at modifying its behavior to reflect new knowledge and insights” (1993).

linear responsibility chart—See RACI chart.

linearity bias—A cognitive bias that causes people to perceive direct, linear relationships between things that actually have more complex connections.

living order—A type of order identified by the French philosopher Henri Bergson that is characterized by rapid change and unpredictable events.

managing by walking around—A management style that emphasizes unplanned encounters with team members, and spontaneous, informal reviews of equipment and ongoing work.

mediation—A dispute resolution process in which a neutral third party helps “disputants come to consensus on their own” (Program on Negotiation: Harvard Law School 2018).

milestone—“A significant event in the project; usually completion of a major deliverable” (State of Michigan: Department of Technology, Management & Budget).

mindfulness—A state of nonjudgmental awareness.

monetize risk—To assign a dollar value to the potential impact of risks facing a project. Monetizing risks gives outcomes “real economic value when the effects might otherwise be ignored” (Viscusi 2005). Once you’ve monetized a project’s risks, you can rank them and make decisions about which deserves your most urgent attention. Every industry has its own calculations for monetizing risks, although it is unethical in some industries, especially where public safety is concerned.

monitoring—In the monitoring and controlling phase of project management, the process of collecting progress data and sharing it with the people who need to see it in a way that allows them to understand and respond to it.

monitoring and controlling—The process of reconciling “projected performance stated in your planning documentation with your team’s actual performance” and making changes where necessary to get your project back on track  (Peterman 2016). Monitoring and controlling occurs simultaneously with execution.

Monte Carlo simulation—”A mathematical technique that generates random variables for modelling risk or uncertainty of a certain system. The random variables or inputs are modelled on the basis of probability distributions such as normal, log normal, etc. Different iterations or simulations are run for generating paths and the outcome is arrived at by using suitable numerical computations” (The Economic Times n.d.).

negotiation—A discussion with the goal of reaching an agreement that is moderately satisfying to both parties. Nobody gets everything they want in a successful negotiation, but everybody gets something. Perhaps most importantly, a wisely conducted negotiation ensures that the parties can continue to work together in the future.

non-stationarity—The presumption that, because of climate change, past environmental conditions are no longer a reliable predictor of future conditions” (Wallace 2018).

operational effectiveness— Any kind of practice which allows a business or other organization to maximize the use of their inputs by developing products at a faster pace than competitors or reducing defects, for example (BusinessDictionary.com).

organizational breakdown structure (OBS)—A description of the project team. It explains “who reports to whom, the details of the hierarchy, and the reporting structure…. Organizational breakdown structures are normally communicated visually through the use of graphs or charts. A project or general manager is listed and underneath the PM several divisions might be created, such as product development, design, materials management, and production” (Bradley n.d.). See also responsibility assignment (RAM) matrix, below.

organizational learning—The process of retaining, storing, and sharing knowledge within an organization. More than merely the sum of the knowledge of all the members of the organization, achieving organizational knowledge “requires systematic integration and collective interpretation of new knowledge that leads to collective action and involves risk taking as experimentation” (Business Dictionary).

Organizational Project Management Maturity Model (OPM3)—The most widely recognized maturity model, developed by the Project Management Institute. The OPM3 is designed to help an organization support its organizational strategy from the project level on up through the portfolio and program levels.

outside view—Term used to refer to an outcome forecast generated through reference class forecasting.

over-allocation—A resource allocation error that occurs when more work is assigned to a resource than can be completed within a particular time period, given that resource’s availability.

over-commitment—A resource allocation error that occurs when a task takes longer than expected, tying up the resource longer than originally scheduled.

parametric estimating—A way to use experience from parts of other projects to come up with estimates for work packages that are similar to past work but not the same.

path—“A sequence of connected activities” (Larson and Gray 2011, 662).

phase estimating—A type of iterative estimating that is “used when the project is large or lengthy or is developing something new or untried for the organization. In phased estimates, the near-term work is estimated with a high level of accuracy ±5 – 15% whereas future work is estimated at a high level with ±35% accuracy” (Goodrich n.d.). As the project advances through major phases, the budget for subsequent phases is intentionally reviewed and refined in light of knowledge gained to date.

physical distance—The actual space between team members.

plan—A strategic framework for the scheduling and execution of a project. In traditional, geometric order project planning, a plan presumes events will unfold in a predictable way, with little need to update the plan. In living order project planning, the plan is always provisional and subject to change.

planning bias—A cognitive bias that makes us think we can finish projects faster, and for less money, than is actually realistic.

planning fallacy—A cognitive bias, or error in thinking, that causes people to be overly optimistic about their chances of success in an endeavor.

portfolio—The “array of investments in projects and programs a company chooses to pursue” (Morgan, Levitt and Malek 2007, 3).

portfolio optimization—The “difficult and iterative process of choosing and constantly monitoring what the organization commits to do” (Morgan, Levitt, & Malek, 2007, p. 167).

positional bargaining—An inefficient form of negotiation in which opposing parties take up positions and defend them, making only small concessions when forced to do so.

premortem—A meeting at the beginning of a project in which team members imagine that the project has already failed and then list the plausible reasons for its failure.

price—“A value that will purchase a finite quantity, weight, or other measure of a good or service” (Business Dictionary).

proactive concurrency—Intentionally developing an awareness of options that can be employed in case you run into problems with your original plan.

proactive resilience—Taking timely action to prevent a crisis, often by introducing a change that upends the usual way of doing things at an organization (Laufer, et al. 2018, 56).

procurement—The process of acquiring goods and services. Used to refer to a wide range of business activities.

professional development plan (PDP)—A document that describes 1) your current standing in your field, including a brutally honest assessment of your strengths and weaknesses; 2) your short- and long-term career goals; and 3) a plan for achieving your goals that includes specific deadlines.

program—“A cluster of interconnected projects” (Morgan, Levitt and Malek 2007, 9).

project— A “piece of planned work or activity that is completed over a period of time and intended to achieve a particular aim” (Cambridge English Dictionary 2018).

project—The “temporary initiatives that companies put into place alongside their ongoing operations to achieve specific goals. They are clearly defined packages of work, bound by deadlines and endowed with resources including budgets, people, and facilities” (Morgan, Levitt and Malek 2007, 3).

project audit/review—An inquiry into any or all aspects of a project, with the goal of learning specific information about the project.

project auditor—The person responsible for leading an audit or review. Ideally, the project auditor is an outsider who is perceived by all project stakeholders to be fair and objective. He or she should have excellent listening skills and broad-base knowledge of the organization or industry.

project champion—A project team member who serves as the project’s chief advocate, especially during the early days of planning. The project champion often becomes the project manager, but not always.

project charter—A “single, consolidated source of information” (Richter 2014) for project initiation and planning. It describes your current knowledge about the project and includes information such as the names of all stakeholders, a statement of your organization’s needs, the history leading up to the project, the project’s purpose, deliverables, and roles and responsibilities. A project charter is also sometimes called a project overview statement. It’s sometimes helpful to think of the project charter as a contract between the project team and the project sponsors.

project closure—According to most project management publications, the final phase of a project. However, in the broader, living order vision of a project’s life cycle, project closure often merely marks the end of one stage and the transition to another stage of the project’s overall life cycle—although exactly where your work falls in the project’s lifecycle depends on your perspective as to what constitutes “the project” in the first place.

project initiation—The early phase in which you lay the groundwork for the entire project.

project management maturity—The “progressive development of an enterprise-wide project management approach, methodology, strategy, and decision-making process. The appropriate level of maturity will vary for each organization based on its specific goals, strategies, resource capabilities, scope, and needs” (PMSolutions 2012).

project management—The “application of processes, methods, knowledge, skills, and experience to achieve the project objectives” (Association for Project Management n.d.).

project maturity model—A set of developmental stages that can be used to evaluate an organization’s state of maturity in a particular domain.

project outcome—In its narrowest sense, a project’s measurable output—whether that’s a building, a software application, or a part for a fighter jet. In a broader sense, the impact a project has compared to its larger goals.

project overview statement—See project charter.

project planning—In traditional, geometric order project planning, the process of formulating the plan that will guide the rest of the project. In living order project planning, “project planning” also refers to the continuous process of incorporating new knowledge into the initial project plan.

project scope—All the work “that needs to be done to provide the product or service your project is delivering” (Martinez n.d.).

project success—The degree to which a project is done well. Stakeholders’ evaluation of project success is a subjective judgement, varying depending on their perspective, and typically changes over time.

project variation request (PVR)—See scope change request.

proposal—According to Merriam-webster.com, “something (such as a plan or suggestion) that is presented to a person or group of people to consider.” Depending on the nature of your company, this “something” might consist of little more than a few notes in an email, or it might incorporate months of research and documentation, costing hundreds of thousands of dollars to produce.

pull planning—Project planning that accounts for the unpredictable, ever-changing nature of the living order. Pull planners start at the desired end state of the project, working backwards to determine the most efficient (least wasteful) way to achieve the desired outcome. To be effective, pull planning requires a collaborative group of workers who coordinate regularly, updating their plan to reflect current conditions.

pull schedule—A schedule typically consisting of color-coded sticky notes that can be removed or repositioned as necessary. This can also be replicated in a number of different software programs. The key is to start with the end goal and then work backwards to determine the tasks required to achieve that goal.

push planning—Project planning that presumes events will unfold in a predictable, geometric order. Push planning is founded on management forecasts of customer demand, with great emphasis placed on the need to keep the parts of the plan moving forward. Managers and subcontractors focus on their individual portions of the project, with limited regard for managing workflow and preventing waste through collaboration and coordination.

quality—The features of a product or project that bear on its fitness for use—that is, its ability to meet the requirements of the customer; another component of quality is freedom from deficiencies.

quality function deployment (QFD)—A technique that helps organizations translate the product attributes the customer wants into tangible, measurable requirements that the project team can deliver. QFD, which is also known as voice of the customer, makes use of a product planning matrix, commonly referred to as the House of Quality, as well as technical and competitive benchmarking to establish target values for each product design requirement (ASQ n.d.).

RACI chart—A type of responsibility assignment (RAM) matrix. Also known as a linear responsibility chart. The name “RACI” is an acronym of “responsible, accountable, consult, and inform.”

recovery manager—Term used by Todd C. Williams in Rescue the Problem Project to refer to a consultant brought in from the outside to audit a failing project, and, if possible, get it back on the path to success (17-19).

recovery plan—A plan that defines the areas to fix and recommends changes in the project and product to achieve the desired result (Williams 2011, 82).

reference class forecasting—A method of predicting outcomes by setting aside the outcome you and your team predict and instead analyzing the actual outcomes of similar projects.

reliable promise—In Lean and the Last Planner System, a formal commitment between team members. As defined by the Lean Construction Institute, “A promise made by a performer only after self-assuring that the promisor (1) is competent or has access to the competence (both skill and wherewithal), (2) has estimated the amount of time the task will take, (3) has blocked all time needed to perform, (4) is freely committing and is not privately doubting ability to achieve the outcome, and (5) is prepared to accept any upset that may result from failure to deliver as promised” (Lean Construction Institute n.d.).

request for proposal (RFP)—A “document that describes a project’s needs in a particular area and asks for proposed solutions (along with pricing, timing, and other details) from qualified vendors” (Peters 2011).

residual risk—The risk that persists even after all reasonable and practicable measures to eliminate risk have been implemented.

resource—“Any personnel, material, or equipment required for the performance of an activity” (Project-Management.com 2016).

resource allocation—The “process of assigning and managing assets in a manner that supports an organization’s strategic goals” (Rouse n.d.). On the project level, resource allocation still involves making choices that support the organization’s strategic goals, but you also have to factor in your project’s more specific goals.

resource capacity management—The practice of “planning your workforce and building a skill inventory in exact proportion to the demand you foresee. It lets you optimize productivity and as a concept perfectly complements the Agile methodology” (Gupta 2017).

resource leveling— An approach to project scheduling that aims to avoid over-allocation of resources by setting start and end dates according to the “availability of internal and external resources” (ITtoolkit n.d.).

resource management—See resource allocation.

resource parsimony—“Deploying the fewest resources necessary to achieve the desired results” (Gibbert, Hoegl and Välikangas 2007).

resource smoothing—“A scheduling calculation that involves utilizing float or increasing or decreasing the resources required for specific activities, such that any peaks and troughs of resource usage are smoothed out. This does not affect the overall duration” (Association for Project Management n.d.).

responsibility assignment matrix (RAM)—A type of organizational breakdown structure in the form of a grid that typically lists project tasks in the first column, and stakeholders across the top row, with tasks assigned to the various stakeholders. You can use it to determine if you have enough resources for a project and to record who is responsible for what. See also RACI chart.

risk—The probability that something bad will happen times the consequences if it does. The likelihood of a risk being realized is typically represented as a probability value from 0 to 1, with 0 indicating that the risk does not exist, and 1 indicating that the risk is absolutely certain to occur.

risk management—“The process of identifying, quantifying, and managing the risks that an organization faces” (Financial Times).

risk matrix—A risk management tool in which the probability of the risk is multiplied by the severity of consequences if the risk does indeed materialize.

root cause—“The core issue—the highest-level cause—that sets in motion the entire cause-and-effect reaction that ultimately leads to the problem(s)” (American Society for Quality n.d.).

root cause analysis— “A collective term that describes a wide range of approaches, tools, and techniques used to uncover causes of problems” (American Society for Quality n.d.).

satisfice—A term devised by Nobel Prize winning economist Herbert Simon (by combining “satisfy” and “suffice”) to describe a realistic form of decision-making, in which people accept “the ‘good-enough’ solution rather than searching indefinitely for the best solution” (Little 2011).

schedule—A specific, time-based map designed to help the project team get from the current state to successful project completion. A schedule should build value, have an efficient flow, and be driven by pull forces.

scope change request—A document that describes a proposed scope change, including its potential benefits and the consequences of not implementing the change. A scope change request must be signed by all affected stakeholders prior to implementing a scope change. Also known as a project variation request (PVR).

scope creep—Changes to a project’s scope without any corresponding changes to the schedule or cost. The term is typically applied to changes that were unapproved or lacked sufficient knowledge about the project and potential assessment of risks and costs when they were approved. Simply put, scope creep is unmanaged change.

scope evolution— An alteration to the project scope that occurs as the project participants learn more about the project. Scope evolution results in an official change in the project scope, and therefore to the project budget or schedule, as agreed to by all project participants. In other words, scope evolution is managed change.

scope statement—A document that defines the project’s scope (or requirements).

self-organizing team—As defined in Agile, a “group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions, and readily adapt to changing demands” (Mittal 2013).

service-level agreement (SLA)—“A contract between a service provider and its internal or external customers that documents what services the provider will furnish and defines the performance standards the provider is obligated to meet” (TechTarget n.d.). An SLA is an example of a document that can be used to codify an agreement between an organization and external vendors (that is, an external contract), or between departments within an organization (that is, an internal contract).

set-based concurrent engineering—An approach to project selection that relies on not filtering projects too quickly, but rather developing multiple solutions through to final selection just before launch. This approach is expensive and resource-hungry, but it is argued that the costs of delay by narrowing to a single solution too soon—which subsequently turns out not to be viable (or sub-optimal)—is greater than the resources expended on multiple, parallel developments.

single-sourcing—The practice of using one supplier for a particular product.

slack—“Calculated time span during which an event has to occur within the logical and imposed constraints of the network, without affecting the total project duration” (Project-Management.com 2016). Or put more simply, slack, which is also called float, is the “amount of time that a task can be delayed without causing a delay” to subsequent tasks or the project’s ultimate completion date (Santiago and Magallon 2009).

sprint—In Agile project management, a brief (typically two-week) iterative cycle focused on producing an identified working deliverable (e.g., a segment of working code).

stakeholders—The people who will be affected by or who can affect a project.

stationarity—A fundamental assumption of engineering that presumes “past environmental conditions are good predictors of future ones.” Until relatively recently, using past conditions to predict the future enabled engineers to “plan, design and deliver long-lived infrastructure, confident that projects would be safe, reliable and efficient” (Wallace 2018).

strategic inflection point—As defined by Andrew Grove, CEO of Intel from 1997 to 2005, “a time in the life of a business when its fundamentals are about to change. That change can mean an opportunity to rise to new heights. But it may just as likely signal the beginning of the end” (1999, 3). A strategic inflection point in an individual project is a time in the life of a project when its fundamentals are about to change.

strategy—According to Merriam-Webster, “a careful plan or method for achieving a particular goal usually over a long period of time.”

sunk cost fallacy—The tendency “to continue investing in a losing proposition because of what it’s already cost” (Warrell 2015).

supply chain management—All the “activities that must take place to get the right product into the right consumer’s hands in the right quantity and at the right time – from raw materials extraction to consumer purchase” (Mays Business School n.d.).

sustainable procurement—Procurement that emphasizes goods and services that minimize environmental impacts while also taking into account social considerations, such as eradicating poverty, reducing hazardous wastes, and protecting human rights (Kjöllerström 2008).

Taguchi loss function—A measure of “the cost of quality as a function of deviation from the standard” (Schenkelberg n.d.).

target value—The output stakeholders want the project to generate.

target-value design—A design process that focuses on value as defined by the customer, with the project’s overall design involving stakeholder engagement and collaboration.

task—See activity.

team—A “small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable” (Katzenbach and Smith 1993, 45).

threat—A potential hazard that could affect a project. A threat is not, in itself, a risk. A risk is the probability that the threat will be realized, multiplied times the consequences.

tolerable risk—The risk you are willing to live with in order to enjoy certain benefits.

top-down estimates—Estimates that “usually are derived from someone who uses experience and or information to determine the project duration and total cost. However, these estimates are sometimes made by top managers who have very little knowledge of the component activities used to complete the project” (Larson and Gray, 134). A top-down estimator generates a total for the entire project and then divides up that total among the various project tasks.

total cost of ownership (TCO)—All the costs associated with owning a particular asset, throughout the lifetime of the asset.

triple bottom line (TBL)—Term introduced by John Elkington as a way to broaden corporate thinking about the cost of doing business to include social and environmental responsibilities. He argued that rather than focusing solely on profit and loss, organizations should pay attention to three separate bottom lines: profit, people, and the planet. “It aims to measure the financial, social and environmental performance of the corporation over a period of time. Only a company that produces a TBL is taking account of the full cost involved in doing business” (The Economist 2009).

value—In ordinary conversation, a generic term that refers to the overall worth or usefulness of something. But in Lean, value is only meaningful “when expressed in terms of a specific product (a good or a service, and often both at once) which meets the customer’s needs at a specific price at a specific time” (Womack and Jones 2003, 16). In other words, value is defined by the customer.

value of a statistical life—An “estimate of the amount of money the public is willing to spend to reduce risk enough to save one life” (Craven McGinty 2016).

variable resource—A resource that changes “in tandem with output” (Reference n.d.).

virtual distance—The “psychological distance created between people by an over-reliance on electronic communications” (Lojeski and Reilly 2008, xxii).

waterfall model—A push plan model used for software that breaks the development process into a set of discrete, sequential steps. It presumes a predictable project outcome, with little or no opportunity for adjustments as the project unfolds.

work breakdown structure (WBS)—A description of the tasks associated with project deliverables, often in the form of a tree diagram. A work breakdown structure “displays the relationship of each task to the other tasks, to the whole and the end product (goal or objective). It shows the allocation of responsibility, and identifies resources required and time available at each stage for project monitoring and management” (Business Dictionary n.d.).

work package— A “group of related tasks within a project. Because they look like projects themselves, they are often thought of as sub-projects within a larger project. Work packages are the smallest unit of work that a project can be broken down to when creating your Work Breakdown Structure (WBS)” (Wrike n.d.).