Contents

Cover

Title Page

Copyright

Dedication

Foreword

Preface

Introduction

The Nature of Project Complexity and Uncertainty

The Risk Mitigation and Business Value Roles of the Senior Management Team

Organizational Culture and Velocity

How to Carefully Manage the Creative Process

About this Book

Who Should Read this Book

Part I: Challenges to Supporting Complex Projects

The Project Landscape (Chapter 1)

Project Management Life Cycle Models (Chapter 2)

The Complex Project Team (Chapter 3)

Chapter 1: The Project Landscape

The Nature of Project Complexity and Uncertainty

Goal and Solution Clarity

Through the Eyes of Senior Management Team Members

Putting It All Together

Chapter 2: Project Management Life Cycle Models

Traditional Project Management

Agile Project Management

Extreme Project Management

Emertxe Project Management

How to Choose the Best Fit Project Management Life Cycle

Putting It All Together

Chapter 3: The Complex Project Team

What Is a Complex Project Team?

Complex Project Team Position Family

Complex Project Manager Use of the Complex Project Team Profile

Senior Management Team Applications of the Complex Project Manager Position Family Profile

Putting It All Together

Part I: Summary

Organizational Challenges and Mitigation Strategies

Executive Bookshelf

Part II: Improving Project Success With Human Resource Strategies and Processes

Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional Integration (Chapter 4)

Professional Development Model (Chapter 5)

Integrating the Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional into the Project Landscape (Chapter 6)

Chapter 4: Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional Integration

Position Families

An Historical Perspective

Complex Project Team and Complex Projects

Putting It All Together

Chapter 5: A Professional Development Model

The Professional Development Plan

Role of the Senior Management Team in the Personal Development Program

Putting It All Together

Chapter 6: Integrating the Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional into the Project Landscape

Project Complexity Assessment

Generalists Versus Specialists

Project Manager, Business Analyst, Business Process, and Information Technology Skill Profile

Mapping the Project Managers and Business Analysts into the Project Landscape

Putting It All Together

Part II: Summary

Organizational Challenges and Mitigation Strategies

Executive Bookshelf

PART III: Improving Project Return on Investment (ROI) Using Agile Project Portfolio Management

The Project Birth and Death Process (Chapter 7)

Agile Project Portfolio Management Process (Chapter 8)

An Agile Portfolio Strategy (Chapter 9)

Chapter 7: The Project Birth and Death Process

Project Birth Process

Project Maturation Process

Project Death Process

Putting It All Together

Chapter 8: Agile Project Portfolio Management Process

What Is a Project Portfolio?

What Is Agile Project Portfolio Management?

Putting It All Together

Chapter 9: An Agile Portfolio Strategy

Adapting the Project Management Life Cycle Models to the Agile Project Portfolio Management Model

Problem/Opportunity Prioritization

Strategic Alignment Model

Alternatives to the Strategic Alignment Model

Putting It All Together

PART III: Summary

Organizational Challenges and Mitigation Strategies

Executive Bookshelf

PART IV: Establishing and Maturing an Enterprise Project Support Office

Organizing and Defining your Project Support Office (Chapter 10)

Growing and Maturing your Project Support Office (Chapter 11)

The Future of the Project Support Office (Chapter 12)

Chapter 10: Organizing and Defining Your Project Support Office

Definition of a Project Support Office

Spotting Symptoms that You Need a Project Support Office

Organization and Placement of a Project Support Office

Steps to Establishing a Project Support Office

Putting It All Together

Chapter 11: Growing and Maturing Your Project Support Office

Project Support Office Stages of Growth

A Step-by-Step Plan

Challenges to Implementing a Project Support Office

Putting It All Together

Chapter 12: The Future of the Project Support Office

Hub and Spoke BP^4SO

Putting It All Together

PART IV: Summary

Organizational Challenges and Mitigation Strategies

Executive Bookshelf

Epilogue: Next Steps

Define Your Role in Supporting Complex Projects

How Will You Make It Happen?

Final Thoughts on the Book

About the Author

Index

Copyright © 2011 by Robert K. Wysocki. All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey.

Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the Web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging-in-Publication Data

Wysocki, Robert K.

Executive's guide to project management : organizational processes and practices for supporting complex projects / Robert K. Wysocki.

p. cm.

Includes index.

ISBN 978-1-118-00407-4 (hardback); ISBN 978-1-118-08924-8 (ebk); ISBN 978-1-118-08925-5 (ebk); ISBN 978-1-118-08926-2 (ebk)

Printed in the United States of America

1. Project management. 2. Executives. I. Title.

HD69.P75W954 2011

658.4'004—dc22

2011007520

To all of those executives in my client organizations who have
reached out for help with understanding and establishing a
supportive environment for managing complex projects.

Foreword

Kathleen B. Hass

This outstanding work closes a huge and costly gap in our 21st-century business practices, that of managing and capitalizing on complexity. It represents a real-world, practical guidebook for senior managers and executives to furnish and continually nurture the environment for success in the 21st-century global economy. If you are a member of senior management and you want to prepare yourself to handle complexity in this competitive global ecosystem, this book prepares you to take responsibility and to take action.

Executives of standout companies, businesses that have flourished in spite of the financial crisis of late, have learned to capitalize on complexity. The first thing they did was to admit to the following six points:

1. Projects execute strategy by implementing the changes needed to react to the relentless dynamics of the marketplace.

2. Successful projects are critical to our economic survival.

3. As executives, strategy execution is our job; therefore, diving into the world of projects is our job!

4. Projects are investments and part of a portfolio that has an investment strategy that needs our attention, support, and expertise.

5. Complexity is here to stay; it is only going to get worse; and we must learn to not just manage complexity, but also capitalize on it to remain competitive.

6. It is through creativity and innovation that we will enable a company to capitalize on complexity.

This work is groundbreaking in that it deals with establishing an organizational infrastructure to accommodate the challenges faced by senior management to effectively support complex projects. Implementing the business practices needed to support complex projects is a learning process that demands an understanding of complexity, a focus on creativity, and business practices that are adaptive and flexible. For senior management teams, the objective is clear: risk reduction and increased return on project investments.

Literally every organization is in a discovery mode as it attempts to converge on the most effective structures, processes, and practices for executing complex projects. However, the need is critical, and we must not shy away from the challenge because we don't have the total solution. As Wysocki says, “It's time for the senior management team to take back control of their investments in projects and programs.” The role of the senior manager is changing significantly. Senior managers possess power and influence; and only they can provide the empowering organizational culture and flexible infrastructure needed to deploy complex, creative, innovative solutions.

In these pages, Wysocki presents a straightforward, enlightening, pragmatic guide for senior managers to begin to transition to an organization that thrives on complexity. Each section of the book is organized in a similar manner, with an overview of contents, followed by material that presents practical tools, templates, and processes that provide an infrastructure to support the needs of complex innovation projects. Each section concludes with a summary of the challenges facing senior management in providing the necessary infrastructure and support. The strategies presented here are relatively easy to explore intellectually, but they will require diligence on the part of the senior leadership team to customize them to “fit” in your environment, to implement them, and to continually refine and improve them so that they remain effective.

Of particular interest is a groundbreaking approach to staffing complex projects that consists of a framework referred to as a complex project manager position family, consisting of the convergence of the four professional disciplines critical to the success of complex projects: Project Management, Business Analysis, Business Process Management, and Information Technology. This framework for complex project leadership includes these professionals at all levels, from individual-contributor staff positions, to professional positions in each discipline, and finally, to executive-level process and practice directors. Using this straightforward framework allows senior executives, resource managers, portfolio and program mangers, as well as complex project managers to ensure the complex project team is appropriately skilled and balanced across the four disciplines based on the complexity of the project. Through a real collaborative effort relying on the synergies of the four professionals each with a differing expertise and perspective, the complex project team will have the technical skill base and leadership prowess to succeed.

Also of considerable interest to me as a member of the International Institute of Business Analysis (IIBA) is a proposed new definition of a requirement, one that relates to the need of a requirement to generate business benefits, either in the form of value to the customer or wealth to the organization. Once it is understood that business benefits are the only real measure of project success, it becomes much easier to establish the critical business requirements early in the project—those referred to as “firm basic requirements” by the Standish Group that are not expected to change. Approaching business requirements in terms of business value makes it appreciably easier to make important decisions about the project scope and approach.

This work makes a significant contribution to our quest to manage and capitalize on complexity. It is the only discussion I have found that concentrates exclusively on the role of the senior management team in fostering the supportive and adaptive environment needed for success in this complex, ever-changing world we find ourselves in. This new leadership approach involves changes in the behavior of the senior team relating to three entities:

1. The Project. Once the complexity of a project is well understood, there are a number of specific activities that senior management can engage in, from matching expertise to the complexity profile, to giving the complex project team the physical space that is needed for the team to collaborate and interact, to minimizing distractions and other assignments to the key team leaders, to understanding and accepting that as more is learned the team will adapt their approach.

2. The Project Portfolio. To manage the portfolio of complex projects, the same flexible, adaptive approach is needed. On a regular basis, the portfolio is assessed and appropriate decisions are made, often resulting in significant changes to the portfolio of complex projects. This is the “sweet spot” of the senior management team when they are striving to capitalize on complexity to achieve innovation, for it is through these complex project portfolios that strategy is executed, value is added for the customer, wealth is earned for the organization, and competitiveness is maintained or advanced.

3. The Project Support Office. The executive teams of standout organizations maintain and support an entity that provides a collection of services to complex project teams. The senior team tolerates and encourages different project support models, depending on the complexity of the team structure and the number of different business lines and applications that are impacted by the complex project, program, or portfolio.

My conclusion: This is a must addition to the reference library for members of the senior management team.

Kathleen B. Hass, PMP
Principal Consultant, Kathleen Hass & Associates, Inc.
Director, International Institute Of Business Analysis
award-winning author of
“The Business Analysis Essential Library” and
Managing Complex Projects:
A New Model, the 2009 PMI Book of the Year

Preface

The contemporary project environment is characterized by a high degree of complexity, uncertainty, and risk. There is a never-ending stream of books, articles, webinars, podcasts, and blogs offering a variety of solutions for managing these projects and quick fixes for everything from requirements gathering to change management. Everybody seems to have a silver bullet to offer the project manager. The best I can say about the present plight of the project manager is that he/she is expected to perform in an environment that even the best among them is struggling to succeed in. Let's face it, we are in the midst of an evolution in project management and only the best and most effective organization-wide approaches have any chance of success. Unfortunately the much-needed help has not yet come to the rescue.

Executives, directors, and senior-level managers (a.k.a. senior management team, [SMT]) are expected to tolerate all of this ambiguity and no one is offering them any silver bullets. Well, first of all, there aren't any silver bullets for them or their project managers either. But there are strategies for the SMT that can improve the plight of their project managers and establish an environment to contribute sustainable business value. These strategies are the focus of this book. This will be the first “how to” book written specifically for the SMT. It is written to be your guide and constant companion.

Introduction

The contemporary world of projects and project management is racing ahead without constraint. Project and program managers are faced with a continuously changing array of tools, templates, and processes. Everyone seems to have their own approach with little in the way of standards or best practices. Performance comparisons across projects are difficult at best. Learning opportunities are not shared in any organized way. It would not be unfair to say that the project world of most organizations is spinning out of control.

The business world is the beneficiary of this unbridled change. Time to market has never been more critical than it is now. And an organization's ability to achieve that speed is dependent on their ability to be flexible and creative. Every critical process must align and must be lean and mean. Supporting the design and implementation of those processes from the perspective of the senior management team (SMT) is the topic of this groundbreaking book.

The Nature of Project Complexity and Uncertainty

The state of complexity and uncertainty at the project level exacerbates the management of programs and portfolios and the supporting infrastructure on the part of the SMT. You are a member of your organization's SMT and have clearly been taken out of your comfort zones. This book will share infrastructure and processes you need to take back control of your project environment. Understand at the outset that this will be a daunting task but it is a necessary task. The continued success of your organization depends upon it. Despite the best intentions and efforts of you and the rest of the SMT, it won't happen by next Tuesday. It is in fact a continuous process improvement effort.

The Risk Mitigation and Business Value Roles of the Senior Management Team

Complex projects are high-risk projects and require a great deal of creativity to be completed successfully. That calls upon you as a member of the SMT to assume a role that may be new to you and that you might not be comfortable with. You need to understand the risks and how best to mitigate them. You need to understand the creative process and how to support it but not interfere with it. Every member of the SMT must be sensitive to the creative and flexible environment needed to support complex projects. As you consider the templates, tools, and processes that you support in this effort, avoid making the following demands on complex project managers:

- Requiring rigid adherence to defined processes

- Regularly scheduled meetings with no action items

- Written status reports

- Forcing them to use specific tools, templates, and processes

- Micro-management

Instead, leave room for the following:

- Empower your project managers to take exception to defined processes with justification

- Meetings called for a specific purpose with a timed agenda and action items

- Passing information in documents rather than meetings

- Discussing problems with affected parties in meetings rather than documents

- Utilize exception reports whenever possible

- Empowerment accompanied by responsibility and accountability

- Use of tools, templates, and processes when their use adds value not just work

Risk Mitigation

Complex projects are wrought with many risks some of which are not known until well into the project. Many of them can be mitigated by the SMT. Chapter 2, Project Management Life Cycle Models, offers some help.

Business Value

The best way to assure maximum business value from complex projects is to take the client, project manager (PM), and business analyst (BA) at their word. If they say a specific deliverable will be realized and its value will be X, take their word for it and stay out of their way as they work to achieve it. But hold them accountable for planned deliverables and the expected business value at the appointed project review times. If they fail to deliver on this project, they will not get the same treatment from you on the next project. My management philosophy is to offer project managers and teams a “long rope” first and only when they have not lived up to expectations to “shorten the rope.” Empowerment is earned!

Organizational Culture and Velocity

The familiar nursery rhyme “Jack be nimble, Jack be quick” was never more appropriate to the business world as it is today. If your organization is to be successful, it must be flexible and adaptive and do it quickly. If you can't quickly do something that needs to be done to protect or enhance your market position, there is an existing or new competitor out there who will. So you have to cultivate a culture of quick change response!

How to Carefully Manage the Creative Process

Being creative is one key to succeeding in the world of complex and uncertain projects. Creative people have a difficult time conforming to process and procedure. They have a strong desire to go with their flow with the expectation that something good will come of it. They might be right on or out in left field but that is the uncertain nature of what they do. Your job is to establish an environment and portfolio of support services in which they can operate, but to the extent possible, hold them accountable for what they do. So, like Jack, you have to be nimble and be quick.

About this Book

The book is organized around four major topics:

- Understanding the challenges to managing complex projects

- Improving project success through HR staffing processes and practices

- Improving project Return on Investment (ROI) using agile project portfolio management

- Establishing and maturing an enterprise project support office

Each of the four topics is presented as a standalone part. Whatever your position within the SMT you can focus on the parts of the book that are in your area of interest. Each topic is discussed from the perspective of the organization and how its SMT can establish the infrastructure and processes to support the management of complex projects, programs, and portfolios.

There are several books that describe the management of complex projects. They range from the definitive work of Kathleen B. Hass (Managing Complex Projects: A New Model, Vienna, VA: Management Concepts, 2009) to an earlier groundbreaking book by Jim Highsmith (Agile Software Development: A Collaborative Approach to Managing Complex Systems, New York, NY: Dorset House, 2000). The focus of these and all the other current books about complex project management is the project. None deal with establishing an organizational infrastructure to accommodate the challenges to senior management of effectively supporting complex project management. How best to support complex projects is a learning process and few organizations have made much progress. The history of project failures and the underlying causes are testimony to that lack of progress. Complex projects by nature are high-risk projects and this book is the first to discuss practical mitigation strategies that can be supported and implemented by the SMT. Their objective is risk reduction and increased return on investment. Complex projects are usually high-risk, high-business-value, mission-critical projects and for that reason alone the SMT should be making every effort to establish an environment for the realization of that business value through a marked improvement to the successful execution of complex projects, programs, and portfolios.

This is the first book that examines the management of complex and uncertain projects from the perspective of the SMT. It is a practical, self-contained “how to” guide for executives and senior managers like yourself. It should be your constant companion and desk reference because it collects in one place the relevant “how to” information for understanding and establishing an environment for improving complex project performance. There are two perspectives that I will share with you:

- The Present Perspective The infrastructure that is needed today is well-defined. It consists of the four major topics listed previously that define this book. The complete “how to” description is described so that a clear path to implementation is given to the SMT.

- The Future Perspective Even with today's infrastructure defined and implemented, the SMT's work is not done. Implementing the most effective infrastructure will always be a work in progress. Each organization is different and so is their infrastructure. Literally every organization is in a learning and discovery mode as it attempts to converge on the most effective structure, process, and practice for succeeding with complex projects. In each Part of the book I will share with you what I foresee as the infrastructure of the future and why your SMT should embark upon a long-range plan to achieve that future.

My writing style is conversational. I want you to feel like we are sitting across from one another in front of a roaring fire enjoying a fine wine and discussing how you can make a difference to your organization's support of complex projects.

My writing style is also practical. I do not offer theory or academics although what I have to say is grounded in experience and practice that works. If the practices I am sharing here are not theoretically sound, someone needs to re-examine the theory. I speak from the perspective of having directly experienced the semblance of ideas that I am advising you to consider in constructing your organization of the future.

My writing style supports implementation. I want to give you enough of a head start to be able to implement this infrastructure. That will not be easy but at least you will have the beginnings of a roadmap. What I have to offer in this book is practical and, at the same time, theoretically sound. In addition in most cases I will give you a sufficient start on implementation.

Why I Wrote this Book

I am in the somewhat unique position of having over 45 years of progressive experience in information technology, business systems design and development, and project management. From my vantage point I have seen history repeat itself several times, I have seen several disruptive innovations in technology launched and become critical and pervasive in the organization. I can see trends that others of less experience cannot. Right now we are experiencing a confluence of rapid change, complexity, and the emergence of global competition from the dining room tables of startup companies in every corner of the planet. Many CEOs have lost control of their organization and don't know how to regain it. That conclusion is documented in a recent study by IBM and is discussed in Chapter 1, The Project Landscape.

It's time for the SMT to take back control of their investments in projects and programs. To do that you need to cultivate your part of the organization so that it can respond to a changing project environment with flexible and adaptive tools, templates, and processes, as well as the infrastructure to support the project and program investment decisions.

I intend to demonstrate just how the SMT as the leadership team can make that happen.

Overview of the Book

The following abbreviations are formally defined later in the book:

- Project manager (PM)

- Business analyst (BA)

- Business process professional (BPP)

- Information technology professional (ITP)

The major parts of the book include:

Part I: Challenges to Supporting Complex Projects

- Chapter 1: The Project Landscape

- Chapter 2: Project Management Life Cycle Models

- Chapter 3: The Complex Project Team

- Part I Summary:

Part II: Improving Project Success with Human Resource Strategies and Processes

- Chapter 4: Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional Integration

- Chapter 5: A Professional Development Model

- Chapter 6: Integrating the Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional into the Project Landscape

- Part II Summary

Part III: Improving Project Return on Investment (ROI) using Agile Project Portfolio Management

- Chapter 7: The Project Birth and Death Process

- Chapter 8: Agile Portfolio Management Process

- Chapter 9: An Agile Portfolio Strategy

- Part III Summary

Part IV: Establishing and Maturing an Enterprise Project Support Office

- Chapter 10: Organizing and Defining your Project Support Office

- Chapter 11: Growing and Maturing your Project Support Office

- Chapter 12: The Future of the Project Support Office

- Part IV Summary

Each Part is organized in the same way. The Part is introduced with an overview of its contents followed by three chapters of content material that presents tools, templates, and processes that provide an infrastructure to support the needs of projects, programs, and portfolios. The Part concludes with a summary of the challenges facing the SMT in providing the needed infrastructure and support. A bibliography of selected materials is provided for more in depth reading for those who have that interest.

Who Should Read this Book

The primary market for this book is the SMT that I have already mentioned with the formal definition given below.

Definition: Senior management team

The senior management team comprises every executive, director, and senior manager at all levels in the organization with management responsibility for the design, development, support, and stewardship of:

- The project and program portfolio of the organization

- The human resources who manage and staff all types of projects

- The tools, templates, and processes used to support all projects

- Standards, performance measurement, and compliance monitoring

This includes all of those who manage the managers of projects, programs, and portfolios as well as those who support those who manage projects, programs, and portfolios.

For the purposes of this book, I will separately identify executive, director, and senior manager level professionals when I need to refer to them specifically. Collectively I will refer to them as the SMT. The executives are C-level professionals who have responsibilities at the enterprise level. The directors own processes and lines of business that support managers of project, program, and portfolio managers. The senior managers have direct roles and responsibilities for managing project, program, and portfolio managers. So whenever I use the titles executive, director, or senior manager I am referring to these individuals. The titles project manager, program manager, and portfolio manager will further differentiate managerial positions below the SMT level.

- Executives C-level professionals who have responsibilities at the enterprise level. For example, Chief Information Officer or Chief Technology Officer

- Directors Own processes and lines of business that support managers of project, program, and portfolio managers. For example, Director of Human Resources, Director of Project Management Office, or Director of Business Process Management

- Senior managers Direct roles and responsibilities for managing the managers of project, program, and portfolios. For example, Manager of Capital Acquisition Programs or Manager of Applications Development

Those who consult to the SMT or have the ear of the SMT are this book's secondary target market. This book will give them the entry they need to partner with the SMT for the benefit of the organization.

The trends are clear. SMT focus is shifting from the business value promised by the individual project to maximizing the return on investment from a portfolio of projects. Every manager above the level of project manager who is interested in protecting that investment will find great value in this book.

Part I

Challenges to Supporting Complex Projects

There is no simple accepted definition of a complex project. The best we have to offer are some of its characteristics from the proceedings of the 2008 NASA Project Management Challenge Conference (Mulenburg, Jerry, “What Does Complexity Have to do With It? Complexity and the Management of Projects,” 2008):

- Details: Number of variables and interfaces

- Ambiguity: Lack of awareness of events and causality

- Uncertainty: Inability to pre-evaluate actions

- Unpredictability: Inability to know what will happen

- Dynamics: Rapid rate of change

- Social Structure: Numbers and types of interactions

Complex projects are filled with uncertainty and unexpected change. Complexity, uncertainty, and the pace of the project all contribute positively to project risk. Risk increases as any of these three variables increases. In most cases these projects are trying to find solutions to critical problems whose solutions have evaded even the most creative professionals. These projects can also be seeking to take advantage of heretofore untapped business opportunities without a clear path as to how to do that. If organizations are to be successful in this environment they must:

- Employ management processes that are flexible.

- Empower the client and the project team.

- Provide an open environment in which creativity can flourish.

- Base decisions on what is best for adding business value.

- Avoid encumbering project managers with non-value-added work.

These are significant challenges because they require senior managers to step outside of their comfort zone and embrace frequent change and high risk.

The Project Landscape (Chapter 1)

It is not sufficient to simply say that complex projects are filled with uncertainty, risk, and unexpected change. That does not give a senior manager anything concrete to help them support such projects. In order to act intelligently senior managers need some structure that defines complex projects and stipulates strategies for dealing with different types of complex projects. The purpose of Chapter 1 is to define a simple but intuitive project classification scheme that can be used as an infrastructure to organize and discuss senior manager support strategies.

Project Management Life Cycle Models (Chapter 2)

Accompanying the complex project landscape are several Project Management Life Cycle (PMLC) Models. These models map to the project landscape and provide an intuitive senior management strategy and approach to generating business value. Chapter 2 defines these models and summarizes their characteristics, strengths, weaknesses, and when to use them.

The Complex Project Team (Chapter 3)

The complex project manager is not your father's project manager. The most effective among them are a multidisciplinary professional who can adapt to the uncertainty, unexpected change, and risk they are asked to manage. In Chapter 3 you will learn about those disciplines and the goal of the human resource executive to develop such professionals.

Chapter 1

The Project Landscape

The first bit of business for you as a member of the senior management team (SMT) is to understand the project environment within which your project, program, and portfolio managers and their teams must work, and within that environment, the challenges you will face in establishing and supporting an effective project management environment. The needs of that environment have changed dramatically in the last 15 years especially with respect to the tools, templates, and processes that support it. The result is confusion and the introduction of yet another silver bullet every Tuesday. Those silver bullets appear very enticing but let me make it clear that there are no silver bullets now nor have there ever been. There are strategies and you are going to learn them from this book but they will require work on your part in order to implement them and continuing attention from your office for them to become and remain effective in your organization. I recognize your dilemma in the faces and through the reactions of my client organizations as they attempt to support complex project management and offer you what I have learned over the years.

Let me try to put this in a context that relates directly to the SMT. A recent worldwide survey (IBM, “Capitalizing on Complexity: Insights from the Global Chief Executive Officer Study,” 2010) conducted by IBM from September 2009 through January 2010 reported that over half of the 1541 executives from the 60 countries that they interviewed admitted that they were not prepared to support the complex and uncertain environment in which they were forced to conduct business and they didn't know what to do about it. If that isn't a wake-up call to action, I don't know what is.

The following quote from that IBM report highlights the efforts of standout organizations to manage complexity. Their efforts provide a roadmap for us.

The effects of rising complexity call for CEOs and their teams to lead with bold creativity; connect with customers in imaginative ways, and design their operations for speed and flexibility to position their organizations for twenty-first century success. To capitalize on complexity, CEOs:

- Embody creative leadership: CEOs now realize that creativity trumps other leadership characteristics. Creative leaders are comfortable with ambiguity and experimentation. To connect with and inspire a new generation, they lead and interact in entirely new ways.

- Reinvent customer relationships: Customers have never had so much information or so many options. CEOs are making “getting connected” to customers their highest priority to better predict and provide customers with what they really want.

- Build operational dexterity: CEOs are mastering complexity in countless ways. They are redesigning operating strategies for ultimate speed and flexibility. They embed complexity that creates value in elegantly simple products, services, and customer interactions.

The messages from this survey are clear and validate the goal of this book. The solution offered herein is a logical approach to mitigating the complexity problem that over half of the CEOs interviewed admitted having. Which half of the population do you align with? If you want to prepare yourself to handle complexity, this book is mandatory reading and prepares you to take action. If you are a standout organization, congratulations but you should still read this book because in these pages you will find some gems to help you stay on top of changing complexity and uncertainty.

There was a time when you may have distanced yourself from projects. Your feeling was that projects were operational level activities and of little importance to someone at your management level. In the past 20 years you've probably rethought that position and now see projects as investments and part of a portfolio that has an investment strategy. You may in fact be the manager that determines that strategy. For that reason you are challenged to do what you can to maximize the return on investment (ROI) to your organization from the projects you recommend for the portfolio and that you support directly. How you have responded to this situation depends on your roles and responsibilities with respect to the project, the project teams, and the portfolio. You may have primary responsibility for supporting or managing project managers or have a role supporting those who do have primary responsibility for supporting or managing project managers. In any case, this book offers you the advice you will need to help you and your organization succeed.

The business environment has changed significantly in the last 20 years and has ushered in new project management challenges that the old ways simply cannot support. Business as usual with respect to projects no longer works and may have never worked. Contemporary projects are projects of high complexity and great uncertainty and you must deal with them under those conditions. All of the simple projects have been done! Specifically:

- Complex project managers need the confidence and support of their management.

- Complex project teams must be empowered so they can be successful.

- Complex project portfolios must be aligned with staff resources.

- Complex projects are unique and so are their management approaches.

- Complex projects are high-risk projects.

- Complex projects require a creative approach to discovering solutions.

- Complex projects require meaningful client involvement.

- Complex projects require flexible support services.

In the pages that follow you will see just how you can and must positively impact all of these challenges. So let's get started with a brief introduction to the complex project environment. Understanding that environment is the foundation on which you will be able to build your support strategy.

The Nature of Project Complexity and Uncertainty

Kathleen B. Hass (Managing Complex Projects: A New Model, Vienna, VA: Management Concepts, 2009) offers the most in depth treatment of complexity that we have. She describes complexity in terms of:

- Time, cost, and size

- Team composition and performance

- Urgency and flexibility of cost, time, and scope

- Clarity of problem, opportunity, and solution

- Requirements volatility and risk

- Strategic importance, political implications, multiple stakeholders

- Level of organizational change

- Risks, dependencies, and external constraints

- Level of IT complexity

In a paper written shortly after her book was published (presented at the 2010 PMI Global Congress Proceedings, Washington, DC) she updates the complexity definition with a four-point scale (Independent Projects, Moderately Complex Projects, Highly Complex Projects, and Highly Complex Programs) and displays the values for a specific project in the form of a spider chart. Figure 1.1 is a hypothetical example adapted from her updated definition and published with her permission.

Figure 1.1 Project Complexity Spider Chart

Adapted from: Project Complexity Model 2.0, Kathleen B. Hass © 2010, Kathleen B. Hass & Associates, Inc.

The project illustrated in Figure 1.1 is highly complex as indicated by the project complexity score on Level of IT Complexity and Clarity of Problem, Opportunity, and Solution. At the Enterprise Level the complexity scores on Level of Organizational Change, Requirements Volatility and Risk, and Strategic Importance, Political Implications, and Multiple Stakeholders are suggestive of a very complex project. All five of these factors should alert senior managers that corrective actions on their part should be in place to mitigate the potential adverse effects. This book offers infrastructure and support advice to that end.

Goal and Solution Clarity

I like simple and intuitive models and I spent a lot of time defining and redefining project categories before I found a classification scheme that met my criteria and my specific needs. The one I am using here I have used for almost 20 years. It works and has never failed to live up to my expectations.

Every project has a goal and hopefully there is a plan that defines how you will reach that goal (a.k.a. a solution). So I define the project landscape around the two fundamental project variables: goal and solution. In my classification scheme these two variables can have only one of two values: clear or not clear. I experimented with more than two values for each variable but that only added complication without adding value. Those two values for each variable generate the four-quadrant matrix shown in Figure 1.2.

Figure 1.2 The Four Quadrants of the Project Landscape

I don't know where the dividing line is between clear and not clear but that is not important to this landscape anyway. These values are conceptual not quantifiable. A given project can exhibit various degrees of complexity and uncertainty that position it in one of the four quadrants at a particular point in time. As a project is undertaken the complexity and uncertainty originally associated with it will often change. That could justify changing its quadrant and also changing how the project is managed. The implications of that change can be significant and you will want to be involved. In Chapter 2 this situation is discussed.

If you impose a quantitative metric on each factor represented in the spider chart in Figure 1.1, you can create a project complexity score and an enterprise complexity score on every project and rank them in terms of complexity. That would be an interesting academic pursuit but is beyond the scope of this book. At this time I prefer a qualitative interpretation of a single project's complexity. Knowing each project's complexity extends to the complexity level of the project portfolio. In Part III, Improving Project Return on Investment (ROI) Using Agile Project Portfolio Management, we discuss the alignment of portfolio complexity with staff resources. In this book my interest will be on Enterprise Complexity and how the SMT can take action that will mitigate the impact of project and portfolio complexity.

Traditional Projects

Traditional projects are the simplest of the four types and are the ones you probably think about when you first envision a project. You assume there is a nice, neat, and clean statement of the goal, and a statement of how that goal will be achieved, and that all the relevant players have the same understanding of what that means. Nice but not too likely. Testimonial data that I have collected from all over the world suggests that about 20% of all business projects are of this type. Does that surprise you?

Until recently you probably haven't paid much attention to these projects. You viewed them mostly like operational projects and not worthy of your time or attention. Let the appropriate business unit managers worry about them. That attitude is no longer appropriate because these projects are at last recognized as investments and part of a portfolio of other similar projects. There is now an ROI component to projects and portfolios and someone has to be responsible for protecting the investment and assuring the delivery of business value. This applies to projects in all four quadrants.

Traditional projects are well-defined and low risk and generally follow a fixed methodology. The plan is developed along with a schedule of deliverables and other milestone events. A formal change management process is part of the game plan. Progress against the planned schedule is tracked and corrective actions are put in place to restore control over schedule and budget. These projects often take advantage of templates that have been developed over the course of repeating similar projects. A nice neat package, isn't it? All is well until the process gets in the way of product development. For example, if the business situation and priorities change, and result in a flurry of scope change requests to accommodate the new business climate, an inordinate amount of time will then be spent processing change requests at the expense of value-added work. The schedule slips beyond the point of recovery. The project plan, having changed several times, has become a contrived mess. Whatever integrity there was in the initial plan and schedule is now lost among the changes. Had this situation been a possibility, a better choice of management approaches could have been made.

Agile Projects

Next in the order of complexity are those projects whose goal is clearly documented and understood, but how to achieve that goal (the solution) is not. Maybe only minor features of the solution are not yet decided and no one is too worried. On the other hand, maybe most of the solution has evaded discovery and everyone is (or should be) worried. Testimonial data that I have collected from all over the world suggests that about 70% of all business projects are of this type. Does that surprise you? Is that a call to action for you? To further complicate the situation suppose the project is a critical mission project and an acceptable solution (one that delivers a specific level of incremental business value) must be found.

These are called agile projects and you have probably depended on the business managers and technical staff to craft management approaches to find these elusive solutions. Without senior management intervention there will be dozens of management approaches with little coordination or standard practices linking them. Such a situation is chaotic from a management perspective and certainly contributes to the conclusions reached in the IBM study quoted previously. This is not a hands-off situation for you. It is very much a hands-on situation requiring your attention. There is a management role for you with significant responsibilities. A major focus of this book is to help you understand those roles and responsibilities and how to take charge. I hope I have your attention.

Agile projects are all together different than Traditional Projects. Managing an agile project is really nothing more than organized common sense. So when the process you are using gets in the way, you adapt. The process is changed in order to maintain focus on doing what makes sense to protect the creation of business value. Unlike traditional projects, agile project management processes expect and embrace change as a way to a better solution and as a way to maximize business value within time and budget constraints. That means choosing and continually changing the PMLC Model to increase the business value that will result from the project. Realize that to some extent scope is a variable in these types of PMLC Models.

Extreme and Emertxe Projects

Next in the order of complexity are those projects whose goal is not clearly defined and whose solution is either not known (extreme projects) or known (emertxe projects). Emertxe is not a nonsense quadrant but is a new term for you and is defined in Chapter 2. Emertxe is a type of research and development project where the solution is known but its application to a business goal is not. These two quadrants are discussed together because the roles and responsibilities of the SMT are the same regardless of which quadrant we discuss. These two quadrants house a variety of research and development projects. It is a world that demands creativity and bold ventures. Both types of projects are very complex, they present a great deal of uncertainty and are high risk. They exhibit a high failure rate. The role and responsibilities of the SMT members in extreme and emertxe projects are very different from the agile projects and even more different from the traditional projects.

Significance of Project Type to the SMT

Every project that ever existed or will exist falls into only one of these four quadrants at any point in time. This landscape definition is robust and is not affected by external factors or change of any kind. It is a landscape that will remain in place regardless of technology or its impact on the business environment. The quadrant in which the project lies will be an initial guide to the project team when choosing a best fit PMLC Model and adapting its tools, templates, and processes to the specific project. As the project work commences and external factors are at play, the goal and solution may change or become clearer and the project's quadrant may change and perhaps the PMLC Model will then change as well, but the project is always in one quadrant. The decision to change the PMLC Model for a project already underway may be a big change and needs to be seriously considered. The SMT will want to understand that there are the costs of change, abandonment, benefits, advantages, and disadvantages associated with a mid-project change of PMLC Model. More on that in Chapter 2.

Beyond goal and solution clarity and completeness there are several other factors to consider in choosing the best fit PMLC Model and perhaps modifying it to better accommodate these other factors. By way of example, one of those factors is the extent to which the client has committed to be meaningfully involved. If the best fit PMLC Model requires heavy and meaningful client involvement, as every agile, extreme, and emertxe project does, and the project team doesn't have their meaningful involvement, you may have to ask the project manager to fall back to an approach that doesn't require as much client involvement. Alternatively you may want to recommend a workshop or other strategy to encourage that client involvement before the project begins. In such situations I have had good results imbedding the client orientation and involvement training into the project work itself.

Regardless of the type of projects the question you need to answer is “On which of these projects am I going to invest my resources?” I'll help you answer that question in Part III, Improving Project Return on Investment (ROI) Using Agile Project Portfolio Management. For the human resource executive the question is “How can I build a cadre of professionals to continuously align with the demands of the project portfolio?” I'll help you answer that question in Part II, Improving Project Success with Human Resource Strategies and Processes. If you are a project support office director the question is “What functions and services must I provide in order to improve the likelihood of the portfolio achieving its ROI?” I'll help you answer that question in Part IV, Establishing and Maturing an Enterprise Project Support Office.

Through the Eyes of Senior Management Team Members

I suspect that for many of you this chapter was your first exposure to just how broad and deep the world of projects can be. It never ceases to amaze me that even after more than 40 years of practicing project management I am still encountering new challenges and learning wondrous things about this amazing and evolving discipline of project management. It all starts with a project and they can be as varied as anything you can envision. I've been involved in a three-month project where I was the project manager, the client, and the entire project team. At the other extreme I have participated in a project where the project team was over 10,000 members spread out over a seven-year timeline. Projects are unique and you should begin to appreciate the fact that their management is also unique and that means that the infrastructure and support of the SMT must be flexible so that it can adapt to a variety of changing situations. Project management is not just a matter of blindly following processes and procedures, or routinely filling in forms and writing reports, but rather it is a challenging world where project managers and clients may be called upon to function at the limits of their creativity and to be courageous at all times. It is a world in which you will continually face situations you have never faced before and will have to look inside your toolkit and concoct workable strategies to support projects and project portfolios. It is a project world filled with risk.

For those of you who were once project or program managers it's no secret to you that the project management landscape has changed and continues to change. With the change comes a constant challenge to the project team and their clients to reassess project conditions and adjust their approach to managing the project. While you are no longer in that role the challenge extends to your office. You live in a world where the characteristics of the project, the portfolio, and the environment within which these take place are constantly changing and those changes should inform senior managers as to the tools, templates, and processes that will be most effective in meeting their infrastructure and support needs. Resign yourself now to the reality that you are going to have to pay attention all the time and be ready to respond with changes that will continue to support the project managers, teams, and clients and keep success within their grasp.

We are not in Kansas anymore! The discipline of project management has morphed to a new state; and as this book is being written, that state has not yet reached a steady one. It may never reach a steady state. The business world is in a constant state of flux and change and that will always be a factor influencing the effective management of the accompanying projects. That will continue to influence how you approach supporting projects and the project team. Expect your approach to also be in a constant state of flux and change. Take courage; it's not as grim as it may seem. In this book I am going to clearly point the way for you. I want to imbue you with some basic principles that should transcend change and protect you from the latest silver bullet. If you really understand what I am presenting, you will have an enduring strategy for delivering effective project management support for every type of project.

A Creative Environment Must Be Flexible

Burdening the project manager or portfolio manager with excessive meetings, reports, and formal documentation does not add business value and may in fact adversely compromise the likelihood of success. The new environment is one of greater trust and empowerment of the project manager and their client. Give them the flexibility to succeed and stay out of their way. Their efforts must be spent on value-added work and they must avoid wasting time on non-value added work.

This does not mean they have complete freedom to do as they please. They don't. If you are a senior manager directly responsible for their performance, request them to state the progress they expect at milestone events and hold them responsible for delivering it. Chapter 2, Project Management Life Cycle Models, and Part III, Improving Project Return on Investment (ROI) Using Agile Project Portfolio Management offer more details for your consideration.

Flexibility here refers to the project management process. If you are imposing a one-size-fits-all approach on your project teams, they have no flexibility. Complex project failure is almost a dead certainty. The process is the process is the process. Not a very comforting situation if the process gets in the way of common sense behaviors and compromises your project manager's ability to deliver value to your client. Wouldn't you rather be following a strategy that allows your project managers to adapt the project management process to the situations rather than being bound to a process that just gets in the way? One of my clients allows their project manager to submit their reason to management and the client for not following a required process and they are held responsible for the outcome. This empowerment has increased team morale and improved project success. Rather than follow a management by exception rule wouldn't it be better to have a process that includes these management choices as built-in features and then depend on the competency of the project manager to make the right choices? Then you can fairly hold them accountable for the results.

Adaptability Is the Key to Project Success

The less certain you are of project requirements, functionality, and features the more you will have to be adaptable with respect to process and procedure. Adaptability is directly related to the extent to which the team members are empowered to act. The ability of the team to adapt increases as empowerment becomes more pervasive. Remember make it possible for the team members to be productive by staying out of their way as much as possible. One way to stay out of their way is to clearly define and agree with them about what they are to do and by when but be careful not to overstep your role as an effective manager of project managers by telling them how to do it. Don't impose process and procedure that stifles team and individual creativity! This would be the death knell of an agile project. Rather create an environment that encourages that behavior. Don't encumber the team members with the need to get sign-offs that have nothing to do with delivering business value. Pick them carefully and trust them to act in the best interest of the client.

Change Is Essential

Plan-driven project management approaches like those used for traditional projects are not designed to effectively respond to change. They are change intolerant. Change upsets the order of things as some of the project plan is rendered obsolete and must be redone. Resource schedules are compromised and may have to be renegotiated at some cost. The more that change has to be dealt with the more time is spent processing and evaluating those changes. That time is forever lost to the project. It should have been spent on value-added work. Instead it was spent processing change requests.

Agile and extreme projects are different. For those projects to succeed there must be change and it must be frequent. Remember the project team and clients are searching for something that does not presently exist. The journey to find that missing solution must continually adapt to learning and discovery, and that won't happen in the absence of change.

Meaningful Client Involvement Is a Critical Success Factor

As the project type changes from traditional to agile, to extreme, and to emertxe meaningful client involvement changes from nice to have, to critical, and even essential. The most recent Standish Group CHAOS Report (“Chaos Summary for 2010,” The Standish Group International, Inc.) lists lack of user input as the major factor that causes projects to become challenged. In that same report the three major reasons why projects succeed are:

- User involvement

- Executive management support

- Clear statement of requirements

These three themes run continuously through this book.

Putting It All Together

So in this chapter you gained some insight into the contemporary world of projects. This may be enough depth for you to effectively discharge your role and responsibilities to supporting the project environment. If you support those who support project and program managers, you should read Chapter 3, The Complex Project Team. If your role and responsibility is to directly support project and program managers, you should read Chapter 2, Project Management Life Cycle Models, and then read Chapter 3.

Chapter 2

Project Management Life Cycle Models

The purpose of Chapter 1 was to define the project landscape. There you were introduced to the four types of projects that populate the project landscape. Every project that ever existed or will exist fits into one and only one of the four quadrants in that landscape at any one time. That landscape gives you a high-level understanding of the range of complexity and uncertainty associated with projects. Above all it is intuitive and gives you a framework within which to understand the various project management life cycle (PMLC) models and how the senior management team (SMT) interacts with them. Even though there are dozens of specific approaches you may have heard of (Waterfall, Rational Unified Process [RUP], Scrum, Dynamic Systems Development Model [DSDM], Spiral, Evolutionary Waterfall, Adaptive Software Development [ASD], Prince2, Microsoft Solution Framework, Feature Driven Development [FDD], Crystal, and Extreme Programming [xP] are but a few of the more popular ones) you don't need to burden yourself with knowing any of them. If you feel compelled to know about them, be my guest. I've included some appropriate references in the bibliography at the end of Part I. All of these models group into the five different types of PMLC models discussed in this chapter. These five types of models will not change and you need to have a conversational knowledge of them. Once you understand these five models, when to use them, and their strengths and weaknesses, you will be armed with all that you will need to discuss the options with the project and program managers and others who are close to the projects. If you are a director that supports the infrastructure for those who directly manage project and program managers, you will understand the environment in which they must perform and how best to support them and you will understand how the tools, templates, and processes they use will vary as project type varies.

To create a cadre of successful project and program managers every SMT member has a role to play in creating and supporting an environment conducive to the process and practice of exemplary project and program management. This chapter defines that PMLC environment and your role in supporting it.

Figure 2.1 shows how the five PMLC Models are distributed across the four quadrants of the project landscape defined in Chapter 1. Once a project has been classified into a quadrant the project manager will decide which of the five PMLC Models provides the best fit. As an SMT member you will want to validate the project manager's decision. Once the PMLC Model has been approved the project manager will decide from a list of specific PMLC approaches the one that is a best fit for managing that type of project. As an SMT member you need not concern yourself about that decision except to know that there is a process that the project manager follows to make that decision.

Figure 2.1 Project Management Life Cycle Models

Traditional Project Management

Testimonial data that I have gathered from over 10,000 project managers worldwide suggests that not more than 20% of all projects require some form of traditional project management (TPM) approach. TPM is the first and oldest of all the approaches. Modern TPM dates from the mid-1950s. The engineering and construction industries use TPM approaches almost exclusively. The waterfall systems development model and some of its variations are also based on TPM. The Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) is also based on those traditional models. The two models discussed in the following sections are special cases of the TPM approach.

Linear PMLC Models

Every PMLC Model discussed in this book comprises five processes:

- Scope

- Plan

- Launch

- Monitor and control

- Close

Let's start with the simplest TPM approach—the Linear PMLC Model. Figure 2.2 illustrates the linear approach to project management.

Figure 2.2 Linear PMLC Model

Note that in the Linear PMLC Model the five processes are each executed once in the order shown in the figure. There is no looping back to repeat a process based on learning from a later process. This is a major weakness of all Linear PMLC Models in that knowledge gained from one process, such as Launch, cannot be used to revise and improve the deliverables from a previously completed process, such as Scope. There is no going back to improve deliverables. Even though you might successfully argue that going back and improving the solution is in the best interest of the client. It probably is, but if that is the possibility you are willing to accept, you should make the decision at the beginning of the project and choose a PMLC Model that includes repeating processes as a result of learning and discovery during project execution. And there are several to choose from. Many of the more popular ones are identified in this chapter.

Definition of Linear PMLC Models

A Linear PMLC Model consists of a number of dependent phases that are executed in a sequential order with no feedback loops. The complete solution is not released until the final phase is complete.

Examples of the Linear PMLC Model include:

- Standard Waterfall Model

- Rapid Development Waterfall Model

- Feature-Driven Development Model (parallel variation)

Characteristics of Projects that Use a Linear PMLC Model

In order to use a Linear PMLC model a project should:

- Have a clearly defined goal, solution, and requirements.

- Expect few scope change requests.

- Be a routine and repetitive project.

- Use established templates.

Strengths of Linear PMLC Models

Projects that correctly use a Linear PMLC Model will:

- Allow the entire project to be scheduled

- Know all of the resource requirements and when they are needed

- Not require the most skilled resources

- Scale to large projects

- Work well even if the team members are geographically distributed

Weaknesses of Linear PMLC Models

On the other hand there are a few weaknesses that come with the choice of using a Linear PMLC Model. The weaknesses you should be aware of include:

- Plan and schedule do not accommodate change very well

- Costs too much compared to other models

- Takes too long

- Requires detailed plans

- Must follow a defined set of processes

- Is not focused on customer value

- Deliverables are not available until the end of the project

Incremental PMLC Models

On the surface, the only difference between the Linear and Incremental PMLC models is that the deliverables in the Incremental Model are released according to a schedule. That is, a partial solution is initially released and then at some later point in time additional parts of the solution are added to the initial release to form a more complete solution. Subsequent releases add to the solution until the final increment releases the complete solution. The decision to use an Incremental PMLC Model over the Linear PMLC Model is a market-driven decision. In both models the complete solution is known at the outset. Getting a partial solution into the market is viewed as a way to get an early entry position and therefore create some leverage for generating increased market share.

All of this incremental release happens in a linear fashion, as shown in Figure 2.3, so that in the end the solution is the same as if a Linear PMLC Model had been followed. Ideally the project ends with the same deliverables and at approximately the same time. There is some additional management overhead associated with the Incremental PMLC Model and so those projects will finish later than the Linear PMLC Model.

Figure 2.3 Incremental PMLC Model

The sequence Launch Increment through Next Increment is strung out in series over time. They are expressed using a feedback loop in Figure 2.3 for economies of space. The entire process is still a variation of a linear model.

Definition of Incremental PMLC Models

An Incremental PMLC Model consists of a number of dependent phases that are repeated in sequential order with no feedback loops. Each phase releases a partial solution.

Examples of Incremental PMLC Models include:

- Staged Delivery Waterfall Model

- Feature Driven Development Model (sequential variation)

Characteristics of Projects that Use an Incremental PMLC Model

Projects that otherwise would use a linear model but must deliver business value earlier in the development life cycle can modify the model to take advantage of the incremental approach. In order to use an Incremental PMLC Model a project should:

- Be of low complexity

- Have few scope change requests

- Use a well-understood technology infrastructure

- Be low risk

Strengths of Incremental PMLC Models

Incremental PMLC models are the first that we discuss that are customer-facing. That is they consider what brings value to the customer as the overarching driver for the strategies. I count among the strengths the following:

- Produces business value early in the development life cycle

- Able to better use scarce resources through proper increment definition

- Can accommodate some change requests between increments

- More focused on client value than the linear approaches

Weaknesses of Incremental PMLC Models

On the other hand there are a few weaknesses that come with the choice of using an Incremental PMLC Model. The weaknesses I have identified and are worth mentioning include:

- Requires heavy documentation

- Must follow a defined set of processes

- Encourages scope change requests

- Must define increments based on function and feature dependencies

- Requires more client involvement than the Linear PMLC Model

- Partitioning the functions and features into increments may be problematic

Agile Project Management

What about those cases where what is needed is clearly defined but how to produce it isn't at all that obvious? These types of projects occupy a space in the landscape somewhere between traditional and extreme projects. Many managers have observed that the vast majority of their projects are a closer fit to agile project management (APM) projects than TPM projects. Clearly TPM won't work when the solution is not known. For TPM to work you need a detailed plan; and if you don't know how you will get what is needed, how can you generate a detailed plan?

Two model types fall into the APM quadrant. The first is the Iterative PMLC Model. The second is the Adaptive PMLC Model.

Iterative PMLC Models

As soon as some of the details of a solution are not clearly defined or perhaps are even missing, you should favor some form of Iterative PMLC Model. The Iterative PMLC Model is shown in Figure 2.4.

Figure 2.4 Iterative PMLC Model

You might notice that this is quite similar to production prototyping. That is, a working solution is delivered from every iteration. The objective is to show the client an intermediate and perhaps incomplete solution and ask them for feedback on changes or additions they would like to see. Those changes are integrated into the prototype and another incomplete solution is produced. This process repeats itself until either the client is satisfied and has no further changes to recommend or the budget/time runs out. The Iterative PMLC Model differs from the Incremental PMLC Model in that change is expected. In fact, change is a necessary part of this model.

Iterative PMLCs definitely fall in the class of projects that provide opportunity to learn and discover. In Figure 2.4 the learning and discovering experience takes place as part of each feedback loop. With each iteration, more and more of the breadth and depth of the solution is produced. That follows from the client having an opportunity to work with the current solution and give feedback to the project team. The assumption is that the client learns and discovers more details about the solution from the current iteration. In the prototyping mode the development team usually takes client input and presents alternatives in the next version of the prototype. You can see then that there is a strong collaborative environment in APM approaches that is usually not present and not required in TPM approaches.

Definition of Iterative PMLC Models

An Iterative PMLC Model consists of a number of phases that are repeated in groups with a feedback loop after each group is completed. At the discretion of the customer the last phase in a group may release a partial solution.

Examples of Iterative PMLC Models include:

- Evolutionary Waterfall Model

- Prototyping

- Rational Unified Process

The definition allows for several types of iteration. Iteration can be on requirements, functionality, features, design, development, solutions, and others.

Characteristics of Projects that Use an Iterative PMLC Model

An Iterative PMLC Model is appropriate when most but not all of the solution is clearly known. This strategy requires a solution that broadly covers the requirements but may be missing some of the details. The missing details will come to light as the client works with the most current solution in a prototyping sense. The use of intermediate solutions is the pathway to discovering the details of the complete solution.

In order to use an Iterative PMLC Model a project should:

- Have a nearly complete solution

- Have known alternatives for missing solution parts

Strengths of Iterative PMLC Models

Iterative PMLC Models depart from the linear and incremental models in that the complete solution is no longer defined. What is defined is a solution whose breadth spans the expected solution but whose depth does not. This affords some breathing room for change that is not provided by linear and incremental strategies. Iterative PMLC Models do have a number of strengths that encourage their use as long as they satisfy the necessary conditions. I count among the strengths the following:

- Customer can review current solution for suggested improvements

- Can accommodate scope changes between iterations

- Adapts to changing business conditions

Weaknesses of Iterative PMLC Models

On the other hand there are a few weaknesses that come with the choice of using an Iterative PMLC Model. The weaknesses I have identified and are worth mentioning include:

- Requires a more actively involved client than TPM projects

- Final solution cannot be specified at the outset of the project

- Risk of losing team members between iterations

Adaptive PMLC Models

At some point where even less is known about the solution an Iterative PMLC Model will no longer be a good fit and an Adaptive PMLC Model will be used instead. Here the missing pieces of the solution extend to functionality that is missing or not clearly defined. The most extreme APM projects are those projects where almost nothing about the solution is known. In other words the less you know about the solution the more likely you will choose an Adaptive PMLC Model over an Iterative PMLC Model. The decision to use an Adaptive PMLC Model instead of an Iterative PMLC Model is a matter of fit and feel and not the result of any quantitative indicator. Unfortunately all of the current Adaptive PMLC Models were designed for software development projects. Since not all projects are software development projects that left a serious gap in the PMLC Model continuum. In my consulting practice this was a serious shortcoming in the agile space and led me to develop the Adaptive Project Framework (APF) for application to any type of APM or extreme project management project. APF is an APM approach that spans the gap between TPM and extreme project management approaches for all types of projects. I have successfully used APF on product development, business process design, process improvement, and research and development (R&D) projects.

Figure 2.5 is a graphic portrayal of how the Adaptive PMLC is structured. At the process group level it is identical to the Iterative PMLC model. Within each process group the differences become obvious.

Figure 2.5 Adaptive PMLC Model

There are a host of iterative and adaptive approaches to managing APM projects that can be used when the goal is clearly defined but how to reach the goal—the solution—is not. Imagine a continuum of projects that range from situations where almost all of the solution is clearly and completely defined to situations where very little of the solution is clearly and completely defined. This is the range of projects that occupy the APM quadrant. As you give some thought to where your projects would fall in this quadrant, consider the possibility that many, if not most, of your projects are really APM projects. If that is the case, shouldn't you also be considering using an approach to managing these projects that accommodates the goal and solution characteristics of the project rather than trying to force fit some other approach that was designed for projects with much different characteristics?

Definition of Adaptive PMLC Models

An Adaptive PMLC Model is one that proceeds from iteration to iteration based on very limited specification of a solution. Each iteration learns from the preceding ones and redirects the next iteration in an attempt to converge on an acceptable solution. At the discretion of the customer an iteration may release a partial solution.

Examples of Adaptive PMLC Models include:

- Adaptive Project Framework (APF)

- Adaptive Software Development (ASD)

- Scrum

- Dynamic Systems Development Method (DSDM)

Characteristics of Projects that Use an Adaptive PMLC Model

In addition to a clearly defined goal and not clearly defined solution, projects that correctly use an APM approach have several defining characteristics including:

- A critical problem without a known solution

- A previously untapped business opportunity

- Meaningful client involvement is essential

- Adaptive projects use small co-located highly skilled teams

Strengths of Adaptive PMLC Models

Adaptive PMLC Models bring some unique strengths to the project. I count among the strengths the following:

- Do not waste time on non-value added work.

- Provide maximum business value within the given time and cost constraints.

- Current solution is a production-ready solution.

Weaknesses of Adaptive PMLC Models

On the other hand there are a few weaknesses that come with the choice of using an Adaptive PMLC Model. The weaknesses I have identified and are worth mentioning include:

- Must have meaningful customer involvement

- Cannot identify exactly what will be delivered at the end of the project

Extreme Project Management

The third project type are those projects whose solution and goal are not known or not clearly defined. Here you are in the world of pure research and development, new product development, and process improvement projects. These are high-risk, high-change projects. In many cases they are also high-speed projects. Failure rates are often very high.

When so little is known about the goal and solution one might be concerned about how to approach such projects. What tools, templates, and processes will work in these cases? Will any of them work? This can be a high anxiety time for all but the most courageous, risk-taking, flexible, and creative project teams. Very heavy client involvement is essential. When you are venturing into the great unknown you won't get very far unless the subject matter expert is on your team. At the same time the generalist will help keep your options open. Both the generalist and the specialist are critical members of the extreme project team.

What do you do if what is needed is not clearly defined? What if it isn't defined at all? Many have tried to force fit the traditional approach into these situations and it flat out doesn't work. Extreme Project Management (xPM) is designed to handle projects whose goal can only be fuzzily defined or really not defined at all. Building a business-to-business (B2B) Web site with no further specification is an excellent example. Much like the early stages of an R&D project, building the B2B Web site starts out with a guess, or maybe several guesses. As the project commences the client reflects upon the alternatives chosen and gives some direction to the development team. This process repeats itself. Either the partial solution converges on a satisfactory solution or it is killed along the way. In most cases, there is no fixed budget or timeline. Obviously, the client wants it completed ASAP for as little as possible. Furthermore, the lack of a clear goal and solution exposes the project to a lot of change.

The Extreme PMLC Model is shown in Figure 2.6. By its very nature, xPM is unstructured. The theme here is that the learning and discovery take place between the client and the development team in each phase—thus moving the project forward. Note that the major difference between APM and xPM PMLC Models is the use of the Scope Process Group. In an APM project, scope is done once at the beginning of the project. That flows mostly from the fact that the goal is clearly defined. In the xPM project, scope is adjusted at each phase. That follows from the fact that the goal can change.

Figure 2.6 Extreme PMLC Model

Similar to APM PMLC Models, the extreme PMLC Model is iterative. It iterates in an unspecified number of short phases (one- to four-week phase lengths are typical) in search of the solution (and the goal). It may find an acceptable solution, or it may be cancelled before any solution is reached. It is distinguished from APM in that the goal is unknown, or, at most, someone has a vague but unspecified notion of what the goal consists of. Such a client might say, “I'll know it when I see it.” That isn't a new revelation to experienced project managers; they have heard that many times before. Nevertheless, it is their job to find the solution (with the client's help, of course).

xPM is further distinguished from APM in that xPM requires the client to be more involved within and between phases. In many xPM projects the client takes a leadership position instead of the collaborative position they took in APM projects. Drug research provides a good example. Suppose, for example, that the goal is to find a natural food additive that will eliminate the common cold. This is a wide-open project. Constraining the project to a fixed budget or fixed timeline makes no sense whatsoever. More than likely, the project team will begin by choosing some investigative direction or directions and hope that intermediate findings and results will accomplish two things:

- The just finished phase will point to a more informed and productive direction for the next and future phases. In other words, xPM includes learning and discovery experiences just as APM does.

- Most important of all is that the funding agent will see this learning and discovery as potentially rewarding and will decide to continue the funding support.

Definition of Extreme PMLC Models

An Extreme PMLC Model is one that proceeds from iteration to iteration based on a very limited specification of goal and solution. Each iteration learns from the proceeding ones and redirects the next iteration in an attempt to converge on an acceptable goal and solution. At the discretion of the client an iteration may release a partial solution.

Examples of Extreme PMLC Models include:

- Adaptive Project Framework

- INSPIRE

Characteristics of Projects that Use an Extreme PMLC Model

The Extreme PMLC Model lies at the outpost of the project landscape. It serves the needs of those development projects where very little is known about the details of the development effort. The following are the five characteristics of these projects:

- Goal and solution not known

- The xPM project is an R&D project

- The xPM project is very high risk

- Critical mission projects

- Typical of R&D projects whose goals are not clear

Strengths of Extreme PMLC Models

The Extreme PMLC Model may be the last resort. You have reached the point where both goal and solution are not defined enough to use any of the previous strategies. There is nothing left. I count among its strengths the following:

- Keeps options open as late as possible

- Offers an early look at a number of partial solutions

Weaknesses of Extreme PMLC Models

On the other hand there are a few weaknesses that come with the choice of using an Extreme PMLC Model. The weaknesses I have identified and are worth mentioning include:

- May be looking for solutions in all the wrong places

- No guarantee that any business value will result from the project

Emertxe Project Management

The solution is known but the goal is not. Don't be tempted to dismiss this as the ranting of those professional service firms who claim to have the answer to your problem whatever your problem might be. They are out there and you probably know who they are. All you have to do is state your problem and they will come to your rescue armed with their solution! That is not where I am going with this discussion.

Definition of Emertxe PMLC Models

An Emertxe PMLC (MPx) Model is one that proceeds from iteration to iteration based on a very limited specification of goal and solution. Each iteration learns from the proceeding ones and redirects the next iteration in an attempt to converge on an acceptable goal and solution. At the discretion of the client an iteration may release a partial solution.

Examples of Emertxe PMLC Models include:

- Adaptive Project Framework

- INSPIRE

Characteristics of Projects that Use an Emertxe PMLC Model

These approaches are for those MPx projects whose solution is completely and clearly defined but whose goal is not. This sounds like nonsense but actually it isn't. Trust me for now. I find it easiest to think of these projects as a backwards version of an extreme project, hence the name “Emertxe” (pronounced a-mert-see). The solution or some variant of it is used to help converge on a goal the solution or a variant of it can support and that hopefully has business value. So rather than looking for a solution as in the xPM project, we are looking for a goal. The PMLCs for both xPM and MPx projects have a lot in common.

MPx projects are a type of R&D project but with the time scale reversed. When you think of an R&D project you think of some desired end state and the project has to figure out if and how that end state might be reached. In so doing, it might be necessary to modify the end state. The final question to be answered is whether or not acceptable business value will be realized? For the MPx project you reverse the R&D situation. You have some type of solution but you have not yet discovered an application for that solution (unknown goal). You hope to find an application that can be achieved through some modification of the solution. You are successful if the application you find has business value.

Note here that each phase is a complete project in its own right. Scoping starts each phase and the decision to begin another phase ends the current phase. In an MPx project, phase and project are basically identical.

You have the solution now all you need is to find the problem it solves. This is the stuff that academic articles are often made of. But that's OK. It's a type of R&D project but in reverse. Post your solution and hope somebody responds with a problem that fits it. It has happened. Take the 3M Post-it Note saga for example. The product sat on the shelf for several years before someone stumbled onto an application. The rest is history. My client Novartis, as well as every other major drug research firm, encounters these projects often.

In addition to a goal that is not clearly defined and solution that is clearly defined, projects that correctly fall into MPx have several identifying characteristics such as:

- A new technology without a known application

- A solution out looking for a problem to solve

Strengths of Emertxe PMLC Models

Same as Extreme PMLC Models.

Weaknesses of Emertxe PMLC Models

Same as Extreme PMLC Models.

How to Choose the Best Fit Project Management Life Cycle

The five PMLC Models bear a closer look and comparison. If you have been counting, you expected to see six PMLC Models. Since the xPM PMLC and MPx PMLC Models are identical there are really only five distinct PMLC Models. Figure 2.7 gives us that view.

Figure 2.7 The Five PMLC Models

The project manager, in collaboration with the client, must choose the specific PMLC Model they will use to manage the project. You need not concern yourself with their choice except to have a perspective on the process they should follow. Figure 2.8 summarizes what we have discussed thus far.

Figure 2.8 The Process of Choosing a PMLC Model and Best Fit Project Approach

The approval of the Project Overview Statement (POS) is a statement that indicates the project merits further investigation in the form of gathering requirements. The resulting analysis of the requirements for completeness and clarity, is input to the process of determining the project type, the appropriate PMLC Model, and choice of best fit project approach.

For the SMT, having incomplete requirements is quite unsettling. Unless you want your project teams to take guesses about what is missing and what will be delivered you will have to abandon the traditional project management practices you are used to, like:

- Defining deliverables

- Estimating time and cost to completion

- Being able to define resource requirements

- Knowing the solution that will be delivered

- Knowing the business value that will be delivered

Obviously the rules of the game have changed. But to what? And further to the point what is the role and responsibility of the SMT in this new game? I promise you that by the time you get to the end of this book you will be able to answer those questions for yourself and you will be able to implement the answers too.

Putting It All Together

These four types of projects and the five PMLC Models that support them have been defined to the depth that the SMT requires for guidance reviewing the decisions made by the project managers.

“One size does not fit all.”

That is perhaps my signature statement when it comes to project management. There are any number of factors that affect the best choice for staffing models and staffing decisions for project teams. An initial decision regarding models and decisions can even change as the project progresses and the project environment changes. Beyond staffing considerations, the best practices regarding tools, templates, and processes are subject to many of the factors discussed in this chapter. The best practice decisions will also change as the project and its environment changes. The bottom line is that project management decisions all boil down to one simple fact: Project management is nothing more than organized common sense!

Chapter 3

The Complex Project Team

Understand as we begin this chapter that the complex project team (CPT) is a very different team than the project teams of old. We are early in our experiences of forming effective CPTs. The CPT is more an accident of choice than a carefully designed unit. To effectively understand and practice the profession of complex project management requires a team with a multi-disciplinary skill set. They will be the successful teams of the future in those organizations that expect to succeed in the complex business environment defined by Samuel J. Palmisano, the Chairman, President, and CEO of IBM, in his 2009 study “Capitalizing on Complexity.”

What Is a Complex Project Team?

Ideally a CPT is a team of 6–10 co-located and experienced professionals who are assigned 100 percent to the project and who can work without supervision. In practice these conditions are seldom met for several reasons:

- The project scope is too broad and complex to be adequately staffed by 10 person project team.

- Experienced professionals are distributed across several geographies.

- Many professionals possess scarce skills necessitating multiple project assignments.

- Some of the professionals will need management oversight.

- CPT professional development programs are not adequate.

- The supply of CPT managers and members is not aligned with complex project staffing needs.

- Complex project portfolios are too aggressive.

Leading the CPT is a complex project manager (CPM). The CPM is already a critical player in the complex global business community. Their profession is evolving into a rich profession whose competencies extend beyond the discipline of project management to a set of competencies that range from beginner to expert in related disciplines such as business analysis, information technology, and business processes. Not every CPM can be so endowed nor would it be reasonable to expect that to be the case nor would it be reasonable to try to develop such professionals. They are generalists or specialists and everything in between. And so that means the CPT position family must be broad and deep. This chapter will set out a definition of that family and how the senior management team (SMT) can support the development of the CPT and the CPM.

I don't want you to think that I have a silver bullet solution for you. I don't. But what I do have is extensive experience in practical professional development programs that I know work and that I will share with you in this book. Implementing my advice in your organization will be another challenge altogether. That is the topic of Part II.

The point of view that I am taking is more of a futurist point of view. It is my contention that the world of the generalist is upon us we just haven't prepared for it yet. In that sense what you will learn here is groundbreaking information for your consideration. It is my expectation that you will begin to think about the potential value that the CPT position family can bring to your organization and to begin a planning process for their growth and professional development.

Complex Project Team Position Family

Simply put, a position family is a collection of related positions. The positions can be related by a similarity of skill profiles or a similarity of work assignments or both. For the purposes of the CPT I am going to define a very comprehensive position family that integrates project management (PM), business analysis (BA), information technology (IT), and business processes (BP). Figure 3.1 illustrates the skills profile of a single professional from the CPT position family. This position family is sufficiently robust to include any professional who might be considered for a spot on a complex project team.

Figure 3.1 The Position Profile of a Complex Project Manager

For the hypothetical position described by the closed quadrangle in Figure 3.1 this professional is skilled at all three manager levels in all four disciplines but strongest in the PM (Senior Manager) and BP (Senior Manager) disciplines and lesser skilled in BA (Manager) and IT (Associate Manager) disciplines. This is truly an outstanding professional. The profile is more the result of extensive experience than training and education.

Note that the position family has two dimensions—discipline, which is discussed in the next section, and level, which is discussed in the section following that.

Complex Project Team Position Family Disciplines

It is beyond the scope of this book to offer much detail on these disciplines but for your need as a member of the SMT the following high-level definitions are sufficient:

- Project Management Professional. The PM discipline includes knowledge and experience of the five process groups (Scoping, Planning, Launching, Monitoring and Controlling, Closing) and applying them to form project management approaches for traditional project management (TPM), agile project management (APM), extreme project management (xPM), and emertxe project management (MPx) projects. The project management professional will be denoted PM.

- Business Analysis Professional. The BA discipline includes knowledge and experience in six knowledge areas (business analysis planning and monitoring, requirements elicitation, requirements management and communications, requirements analysis, enterprise analysis, solution assessment and validation). Notice that this discipline does not include knowledge of any specific business process nor is that knowledge expected. The business analysis professional will be denoted BA.

- Information Technology Professional (ITP). For the purposes of this position profile the IT discipline includes a working knowledge of systems development processes, hardware/software systems, databases, data communications, and internet/intranet applications. Experience using various development tools is not expected or required in this position profile. For the purposes of this book, the information technology professional will be denoted by ITP.

- Business Process Professional (BPP). The BP discipline includes a working knowledge and experience with one or more specific business processes. This discipline does not expect or require any knowledge or experience in the BA discipline. For the purposes of this book, these professionals will be denoted by BPP.

Complex Project Team Position Family Position Levels

In addition to the four disciplines the position family includes eight position levels. These position level descriptions are robust and apply equally to all four disciplines. In order to fit your organization you might define more or fewer position levels. I have chosen eight position levels because I believe that is justified by the needs of complex projects. However you define your position levels, I would suggest that you preserve the staff, professional, and executive distinctions in your classification scheme.

Staff Positions

There are two staff positions: team member followed by task leader. The Team Member is the entry level into the CPM position family. (NOTE: CPM is used for both complex project manager and complex project team. The context will make clear which meaning is intended.) Both team member and task leader positions are individual contributor positions. They are highly structured and depend on close supervision. They are not considered professional level positions. In a typical project both positions can report to an associate manager. Once the staff person has acquired the experience and skills that qualifies them as a professional, they are ready for entry into the professional positions at the associate manager level.

Team Member

This is an entry-level position into any of the four disciplines. No prior knowledge or experience in any one of the disciplines is expected or required. A person entering this position will often come directly from completing a two or four-year program with no full-time job experience in any business unit. At most they will have limited experience as an intern or in a related part-time position as a PM, BA, ITP, or BPP. In some cases they may have as much as 18 months of full-time experience completely outside the four disciplines. An IT programmer would be a typical example.

Typical team member positions will be assigned to a project in a structured and supervised role. In order to be productive carrying out their first assignment, they will have to have completed initial training in using the appropriate tools, templates, and processes, in order to be able to carry out their assigned responsibilities. Once they have acquired that working knowledge and minimal experience they are expected to organize and plan their work to meet specified performance criteria under less direct supervision. They will quickly develop the skills to plan, schedule, and monitor their own work as well as absorb new technical information as it is presented to them.

Example position titles include documentation specialist, data analyst, and quality assurance tester.

Task Leader

This is the upper-level staff position for those who are familiar with the scope of their tasks. After 18 to 24 months experience as a team member with experience in one or more of the four disciplines, they should be qualified for promotion to task leader. As task leader they will perform tasks they are qualified for and supervise the work of team members assigned to their area of task responsibility. So a task leader is a working supervisor position. Their position is distinguished from the team member by the depth and complexity of their technical knowledge base and the extent to which supervision is required. Task leaders work with little supervision and are expected to meet the requirements of their assignment under their own initiative. They will often be required to provide initial guidance and training for the less experienced team members assigned to their task.

Task leaders generally work unsupervised and seek advice and support only when they feel the need for such help. Their assignments are given to them with the necessary specifications for satisfactory completion and are expected to use the tools, templates, and processes needed for successful completion. They will have developed effective communication and problem-solving skills. They will begin to acquire skills and competencies related to their primary task assignments, as a broadening experience, in preparation for wider areas of responsibilities. They should begin to see the application of their tasks to broader functional areas and the business in general.

Example position titles include business process analyst, risk analyst, acceptance test lead, requirements elicitation facilitator, and change request intake specialist.

Professional Positions

There are five professional positions: associate manager, manager, senior manager, consultant, and senior consultant. The career path continues in the professional level from associate manager through the senior manager positions. As a senior manager the professional will make a career choice to follow an individual contributor path as a consultant and senior consultant and finally as a process director or to a general management position at the executive level as a practice director.

Associate Manager

This is the entry-level position into the Professional Level. It is the lowest of three manager positions at the professional level. It will normally be achieved after clear evidence is available of full competence in a specialized role. At this level, full technical accountability for work done and decisions made is expected. The ability to give technical or team leadership will have been demonstrated as well as a high degree of technical versatility and broad industry knowledge. An associate manager will often manage small projects, or major parts of larger projects, and be responsible to the project manager. They work unsupervised and are accountable for specific results.

The typical candidate will have about 12 to 18 months of successful experience in the role of task leader and will have demonstrated the capacity to effectively manage simple projects and provide team leadership. They are responsible for managing the work of staff assigned to their project but do not have direct people management responsibility.

Example position titles include associate project manager and business analyst.

Manager

This is the mid-level manager position in the professional level. It will normally be achieved after two to four years experience as an associate manager. The candidate will have demonstrated the capacity to manage projects of intermediate complexity and size. Complexity and uncertainty will characterize their assignments.

Example position titles include project manager, financial systems business analyst, and business process improvement analyst.

Senior Manager

This is the most senior of the three manager positions at the professional level. It will normally be achieved after several years experience as a manager. Service time as a manager is important but more important is the candidate's demonstration of full competence in a specialized role. At this level, full technical accountability for work done and decisions made is expected. The ability to give technical or team leadership will have been demonstrated as well as a high degree of technical versatility and broad industry knowledge. The candidate will have demonstrated a capacity to manage the most complex of projects and programs and often be responsible for managing the activities of managers and associate managers who function as project and sub-project managers.

Example position titles include senior project manager, program manager, senior business analyst, and business process owner.

Consultant

This is the entry-level position to consulting in specialized areas of expertise across the organization. Candidates for this position are generally senior managers. The Consultant will often join a project team for a limited engagement as an advisor and perhaps offer training to project team members in their area of specialization. They are recognized professionals having earned that respect as senior managers. They work unsupervised and receive only general directions and objectives from their manager (a Process Director). If the consultant's discipline is project management, they are probably assigned to a project support office (PSO) and report to the PSO Director.

My recommendation is that the PSO of the future should formally support the CPM position family. (See Chapter 12 for more detail.).

Example position titles include enterprise architect, business intelligence consultant, and business architect.

Senior Consultant

This position differs from its more junior counterpart in that the senior consultant is called upon to advise the most senior-level executives regarding the strategic aspects of their technology specialization. This strategic advice may be shared at large project or program levels as well as at the enterprise planning levels. In either case the senior consultant is recognized as “the expert” by their colleagues and by executive management.

Example position titles include senior enterprise architect, business intelligence consultant, and senior business architect.

Executive Positions

There are two executive positions: process director and practice director. In most organizations these two positions may be part of the SMT. Senior manager or senior consultant positions are an entry point to either of these positions. The process director position manages all consulting and architecture practices for the enterprise in a specific discipline. The practice director manages the project assignments of all professional and even staff positions in a specific discipline.

Process Director

This position represents the level associated with the mature, relevantly experienced, and fully capable consulting professional. Such a person is fully accountable for work quality as a technical specialist. He/she possesses the background knowledge and experience to make informed and responsible decisions, which are technically sound and also take the needs of the organization fully into account. They will be expected to advise executives on strategic matters related to their technical expertise.

In small organizations there may be only one process director position with director responsibilities for all business processes. As organizations grow in size and complexity there may be one process director position for each major business process group or each business process for the largest organizations. When there are multiple process directors, their manager, VP of business processes will be a member of the SMT.

Example position titles include director enterprise architecture, director of knowledge management, and chief business architect.

I would have expected there to be positions called VP Business Process Management and Chief Business Architect by now but I have not found any at least not by that title. Maybe it's too early to have such a position but it is not too early to begin preparing candidates for such a position.

Practice Director

This is the most senior people management level position in the CPM position family. It is the level occupied by the most senior manager of a business function or unit in organizations where operating effectiveness (and possibly survival) is heavily dependent on the function or unit, and where large numbers of practitioners are deployed. A wide and deep practical knowledge base is called for, accompanied by mature management qualities.

Example position titles include PSO director, director of projects, and director of IT project portfolio.

The Complex Project Team Skills Profile

One use that I have made of a similar profiling schema is to describe the project team. If you think of the envelope that encloses the skill profiles of all the team members taken collectively, you have a profile of the team skills. Figure 3.2 is an example of a team skill profile.

Figure 3.2 A Team Skill Profile

Taking this idea one step further the team skill profile could be matched against the project profile using the same four disciplines to profile the project as were used to profile the team. The result is a measure of how well the team skill profile aligns with the needs of the project. Figure 3.3 is an example of the alignment of a team skill profile and a project profile.

Figure 3.3 Alignment of a Team Skill Profile and a Project Profile

The needed project skill profile is shown with a dotted line and is a composite of the staffing skills needs identified in the project plan. In the example the team requires additional skills in project management and secondarily in IT to meet the requirements of the project.

Complex Project Manager Use of the Complex Project Team Profile

The CPM is the primary beneficiary of the CPT profile especially using the data shown in Figure 3.3. Professionals with consultant and senior consultant skills can be important seconds for the CPM. For a complex project, requirements-gathering is particularly challenging. There are two team members whose skills in BA are at the consultant level. Those persons may be the ideal pick for planning and gathering requirements especially since the project profile suggests that the team is lacking in that area. While this is obvious from the figure, it may not be otherwise obvious unless the CPM has had previous experience with and knows the BA consultant.

The one characteristic not shown in the profile is the generalist/specialist composition of the CPT. For each relevant discipline the CPT needs members who are specialists and members who are generalists. This will be most important for those disciplines that are at the heart of the complexity present in the project.

Senior Management Team Applications of the Complex Project Manager Position Family Profile

Figures 3.1 through 3.3 are of interest to the following members of the SMT for the reasons cited:

- Human resource directors. Your objective is to create and sustain an alignment between the skill profiles required by the projects and the skills profile of the team members. Your major responsibility is to keep the managers informed of the professional development plans of their staff as compared to the future staffing needs of the organization. More on that in Chapter 5, A Professional Development Model.

- Training directors. Your objective is to make the most effective use of your training budget, in keeping the supply of skilled staff in alignment with the demand for skilled staff. That will involve offering a training portfolio that supports the professional development plans of the staff.

- Portfolio managers. Your objective is to make best use of available staff resources in choosing projects for the portfolios. That will involve comparing staff resources over time against the project staffing needs over time to decide which projects can be staffed with available resources and which projects will have to be revised in order to be staffed. More on that in Part III, Improving Project Return On Investment (ROI) Using Agile Project Portfolio Management.

Meeting these objectives is difficult. In all three cases you will be aiming at a moving target and there are lots of variables whose values are continuously changing making it even more difficult. Let's take a look at each of the three SMT members and see what they can do to meet their objectives.

Human Resource Directors

Aligning supply with demand is a never-ending process. The supply side of this equation requires professional development plans for every potential team member. The demand side of the equation requires knowing the staffing requirements of every project in the pipeline as well as some idea of those not yet in the pipeline. Let's look at each of those.

Professional Development Plan

Part II discusses professional development plans in detail so that isn't the focus here.

Project Staffing Requirements

Few organizations can really claim to be doing an exemplary job here. The situation requires repeatable interactions between the supply and demand sides of the equation. At best a project proposal specifies the skill needed, from start date to end date, and the percentage of time needed. So for example, the project needs a senior consultant data base architect for 0.5 full-time equivalent (FTE) for one month beginning on 10/1/11. Suppose there isn't such a professional available. How would the project manager be willing to compromise the request? There are several variables to consider. Is there a resource management system with the capability to suggest the compromise alternatives? I don't know of one.

Aligning Supply and Demand

One of the biggest challenges for an organization is the resource management issue that emanates from aligning supply and demand. Recent survey results from Project Management Solutions suggest that most organizations do a poor job for one or more of the following reasons:

- Resource capacity planning is poor

- Not enough appropriately skilled resources

- Too many unplanned requests for resources

- Resource use is not optimized

- Effort estimation is inaccurate

Training Directors

Aligning the supply of skilled staff with the demand for skilled staff is a never-ending process. The difference between the demand and the supply is what I will call the skills gap. That is not a static gap but a dynamic one that changes over time. Projects enter their life cycle and are approved. Projects leave their life cycle because they are completed or terminated. Staff skill profiles change for a variety of reasons most of which can be forecasted and planned. The plan to remove those gaps will also be a dynamic plan.

The bottom line is for training directors to schedule courses and workshops to continuously address the skills gap.

Portfolio Managers

It is clear that the portfolio managers depend on the effectiveness of the human resources and the training directors to maintain constant alignment of the supply of skilled staff with the forecasted demand for skilled staff, so that strong portfolios with expected business value can be built. In the absence of that alignment, portfolio managers have to constantly adjust the portfolio to use available resources as effectively as possible.

Putting It All Together

The CPM and CPT of the future is clearly multi-disciplined as described in this chapter. Adding the dimension of generalist and specialist has also been shown to be a critical part of an effective cadre of CPMs and CPT members. The profession is far richer than most managers have considered. The real strength of a professional development program lies with the HR executive's ability to implement a broad program of development and support.

Part I

Summary

Organizational Challenges and Mitigation Strategies

We are not in Kansas anymore! The discipline of project management has morphed to a new state; and as this book is being written, that state has not yet reached a steady state. It may never reach a steady state. Your business world is in a constant state of flux and change and it will always be that way. To expect otherwise is folly. That change will continue to influence how we approach managing complex projects but more importantly how the SMT will establish and support the needed infrastructure. Like a process improvement program, your infrastructure will be in a constant state of flux and change. So my best advice at this point is to think in terms of designing an infrastructure that lends itself to flexibility of application and adaptability to changing in unpredictable business conditions.

Complex Project Failure Isn't Your Father's Project Failure

Complex project failure has to be looked at in a different light than maybe you have looked upon project failure before. Defining failure for a complex project isn't that easy. We live and work in a complex ever-changing business environment and if a project is terminated early because the business situation has changed and the original project can no longer deliver the expected business value, has that project failed? Recognizing that business value can no longer be attained and having the political courage to terminate the project and reinvest the resources elsewhere may be considered a success and not a failure. Deliverables from a project that maybe didn't deliver expected business value could have value at some later point in time on another project. The future can never be known and failure can all of a sudden be termed a success.

When Failure Is Good

Research and development projects are prime examples of failure that is good. That failure puts the research team one step closer to a solution by eliminating a whole range of possibilities that now are seen to be non-productive and not worthy of further investigation under the present conditions. If the situation changes, terminated research and development projects might later be re-opened for further consideration.

Because of the volatile business environment we have to look for the learning value in every project. What is discovered in one project might be useful in another. What may not solve a problem today could well solve a problem tomorrow. The Post-It Note product history at 3M is a great example. After sitting on the shelf for seven years an application for the once-failed glue development project gave rise to a multi-billion dollar product.

When Failure Is Not Good

Failure is not good if the project became a needless drain on resources that could have been avoided with a better performance monitoring process. As a member of the SMT you need to pay particular attention to this situation. The caution I offer is for you not to get too wrapped up in a project you have sponsored and to have your judgment clouded because you have become politically wedded to your project. It is hard to be objective about your own portfolio, but you must. That is the major reason for there to be an objective performance metric and monitoring process in place.

PMLC Model Choice Versus Environment

Despite all of the SMT efforts to put an objective model selection process in place it is not possible. Even using the best of objective criteria there will always be subjectivity involved in the final model choice decision. Some of that subjectivity is discussed in the following sections.

Team

The pundits are in close agreement that to successfully execute a complex project requires a small co-located team of senior level subject matter expert (SMEs). That's nice but that's idealistic. Does that mean that a complex project should not be attempted if the team is distributed across the planet? I can't see you agreeing with that decision. Rather, you should be telling the project manager to adapt and that the project goes forward in the face of that constraint. The frequency of complex projects as compared to traditional projects continues to increase and that aggravates an already unbalanced inventory of senior versus junior-level professionals. If you compromise and use junior level professionals when senior level professionals were required, project risk increases. That's a given and you have to deal with it until the supply of human resources comes more into balance with the demand. In the meanwhile the pressure on the project portfolios will persist.

Co–Project Managers

For the 20 plus years that I have been in business I have insisted on using a co-PM model with my clients. I am one of the co-PMs and my client appoints the other co-PM. Together we share responsibility for the project. Decisions are joint decisions and we are each empowered to speak for the other. Obviously the client's co-PM must have decision making authority for the client organization. This model establishes ownership by the client and contributes to implementation success too.

Rotating Phase Managers

Multiple team projects occur frequently in enterprise-wide projects. A multiple team project is one in which there are several independent teams all working concurrently on the same project. I'll restrict the discussion to situations where the teams all come from the same organization but the situation applies equally to cases where the teams come from different organizations. Managing such projects is a challenge because each team is likely to have its own tools, templates, and processes designed for best fit in their part of the organization. On the negative side is the challenge of integrating disparate and perhaps conflicting practices into a single practice. On the positive side you might consider using a practice from one of the teams where the practice is clearly better than that of any other team and letting someone from that team manage that practice for the project. I've been successful doing that with requirements elicitation, risk management, and acceptance test procedures. I'll have more to say on this in Chapter 12: The Future of the Project Support Office.

Meaningful Client Involvement

Client types range from those that want nothing to do with technology-based complex projects to those who think they have the solution. In addition to using the co-PM model I have insisted on meaningful client involvement. There have been a few cases where I have refused to take responsibility for managing a complex project where meaningful client involvement was clearly not going to be present. The way out of this seeming dilemma is to conduct workshops with the client usually concurrently with the project to teach them the importance of their involvement and to actually get it as a deliverable from the workshop.

Staffing Models

The basic tenets of an APM, xPM, or MPx project are that the team is comprised of a few experienced technical professionals and that the team is co-located. That's nice in theory but is difficult in practice. Even in mid-sized organizations professionals are often geographically distributed. When they have specialized and scarce expertise, and a project requires their participation in a co-location model, problems arise. The cost of relocating them to the project is prohibitive. What if they are concurrently needed on more than one project? The airlines get rich and the project suffers from the non-value added work of just getting to the office from some distant location. So we have to give in to the reality that while co-location is the ideal staffing model, it just isn't going to happen very often.

Sabbaticals

The pressures of being on the firing line and continuously in harm's way can be telling on the project manager. The sabbatical (basically a vacation from the project management battle lines) can be used quite productively. It is a good way for project managers to recharge their batteries and rebuild their motivation but it has another and equally valuable reward. They can work on a special project that they proposed or they can provide consulting services to other project managers. Both can be motivating experiences.

Organization

My model of the complex project organization is an inverted triangle. The SMT is at the bottom of the triangle because they are the support infrastructure. Projects, programs, and portfolios lie in the middle layers. The CPMs and CPTs lie at the apex of the triangle.

Market

The market won't stand still just because you are managing a project that interacts with the market. The dynamic nature of a market is justification for project management approaches that are flexible and are of short duration or consist of two- to four-week increments. At the completion of each increment the market is reassessed and adjustments made to the project plan for the next increment. These agile strategies are examined in Part III, Improving Project Return On Investment (ROI) Using Agile Project Portfolio Management.

Project Termination

It is easy for you to get attached to a complex project you are sponsoring and let your judgment get clouded. The best advice I have is to agree to use an objective process in evaluating a project and making an unbiased business decision regarding its future. That topic will be taken up in Part III.

Executive Bookshelf

Here are some references that you may find useful. I have included those that reinforce the material introduced in Part I as well as material that gives you more detail on each of the topics discussed.

Center for Project Management. Managing Advanced IT Projects. San Ramon, CA: Center for Project Management, 1995.

DeGrace, Peter, and Leslie Hulet Stahl. Wicked Problems, Righteous Solutions. Englewood Cliffs, NJ: Yourdon Press Computing Series, 1990.

Eckstein, Jutta. Agile Software Development in the Large. New York: Dorsett House, 2004.

Hass, Kathleen B. Managing Complex Projects: A New Model. Vienna, VA: Management Concepts, 2009.

Highsmith, James A. III. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York: Dorset House, 2000.

Highsmith, Jim. Agile Software Development Ecosystems. Boston: Addison-Wesley, 2002.

Highsmith, Jim. Agile Project Management: Creating Innovative Products. Boston: Addison Wesley, 2004.

Kerzner, Harold. In Search of Excellence in Project Management. New York: John Wiley & Sons, 1998.

Kruchten, Philippe. The Rational Unified Process: An Introduction. 2nd Edition Boston: Addison-Wesley, 2000.

Poppendieck, Mary and Tom Poppendieck. Lean Software Development: An Agile Toolkit. Boston: Addison Wesley, 2003.

Schwaber, Ken. Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004.

Stapleton, Jennifer. DSDM: Dynamic Systems Development Method. Harlow, England: Addison-Wesley, 1997.

Wysocki, Robert K. Managing Complexity and Uncertainty in Software Projects. Cutter Consortium, 2005, Vol. 6, No. 7.

Wysocki, Robert K. Effective Software Project Management. New York: John Wiley & Sons, 2006.

Wysocki, Robert K. How to be Successful in an Ever-Changing Project Landscape. EII Publications, 2006.

Wysocki, Robert K. “ Are You a Cook or a Chef?: Succeeding in the Contemporary World of Project Management” Cutter Consortium, 2008, Vol. 9, No. 10.

Wysocki, Robert K. Effective Project Management: Traditional, Agile, Extreme, 5th edition. New York: John Wiley & Sons, 2009.

Wysocki, Robert K. “ A Requirements Management Lifecycle that Works for Every Project” Cutter Consortium, 2010, Vol. 11, No. 3.

Wysocki, Robert K. Adaptive Project Framework: Managing Complexity in the Face of Uncertainty. Reading, MA: Addison Wesley, 2010.

Part II

Improving Project Success with Human Resource Strategies and Processes

One of the biggest problems the senior management team (SMT) faces is to keep the human resources inventory current and its future profile in alignment with the changing project demands for those resources. Both the supply side and the demand side are variables and are at least partially controlled by the SMT. In this Part we will examine the supply side of the equation. The demand side will be discussed in Part III. The challenges are great. First of all, we know that projects are unique and will never be repeated under the same conditions ever again. That point is not debatable. What is also not debatable is that the complex project management approach is also not unique. In Part I, Challenges to Supporting Complex Projects, you learned about the project landscape and the project management life cycle (PMLC) Models and you know that a “one-size-fits-all” approach simply does not work. It needs to adapt to the changing project situation. That same argument pertains to the project manager (PM) and the team members. They also need to be adaptable. One type of PM cannot align with every project. As the project changes should we change the PM? That would be chaos! The only conclusion is that the PM must be adaptable to changing project conditions. My point is that the PM needs to possess a broad set of skills in anticipation of the needs of a complex project. I believe that the skill profile of the modern complex project manager must include not only project management but also business analysis (BA), business processes (BP), and information technology (IT). The nature of that skills profile was the topic of Chapter 3: The Complex Project Team. The actual mix of those skills should align with the needs of the project for those same skills. Despite our best efforts it would be unlikely that one person could possess the ideal skills profile for the project. The project team will have to complement the skills profile of the project manager to adequately cover the needed management skills.

Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional Integration (Chapter 4)

In this chapter we examine the interaction of the four disciplines that define the complex project management position family. The four disciplines are mapped into the deliverables from each project phase to show the dependence of the typical project on each discipline. A new definition of requirements is proposed in order to relate requirements to success criteria and the resulting business value.

Professional Development Model (Chapter 5)

A Professional Development Plan (PDP) is introduced and shown to be the best fit tool for managing the gap between the supply and demand for a skilled cadre of complex project managers and team members.

Integrating the Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional into the Project Landscape (Chapter 6)

In addition to the four disciplines that define the skills profile of the complex project manager and team members the need for both generalists and specialists on the team is explored.

Chapter 4

Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional Integration

First some observations from my consulting experiences. I don't know of any organization that can truthfully claim to:

- Have consciously developed a cadre of skilled professionals that can continuously meet the staffing needs of the complex projects proposed for their portfolios

- Have a human resource management system (HRMS) that effectively assigns their cadre of skilled complex project team (CPT) professionals to projects (software vendors take note!)

- Sustain an alignment between its cadre of skilled CPT professionals and its strategic plan

- Build balanced project portfolios while effectively using available human resources

The sad situation described above is unfortunate but true. If my list describes your organization, your SMTs will have a difficult time managing the complexity talked about in the IBM report mentioned earlier. My objective in this chapter is to begin defining the human resource infrastructure and processes you will need and to set the stage for addressing the problems reflected in the above list. Understand that the tasks before you to correct this situation will not be easy. What I am going to propose will be a challenge to implement. You might want to think of it as a goal to converge towards but not necessarily attain.

In practice I frequently observe two behaviors that are very unsettling. The first is that availability seems to be a skill. Harry is an inexperienced database analyst (DBA) and not currently assigned to any project. Project Alpha needs a senior level DBA. There is no senior DBA available and so Harry is assigned to Project Alpha. His manager assures Harry that he will be given the support he needs to take on this challenging assignment. That support never comes and Harry is left to do the best he can. Is it any wonder that such assignments often lead to schedule slippage and even project failure? Even worse is the case where Harry has the proper experience and skills and is assigned to Project Beta. There is no one else qualified for the DBA task in Project Alpha so Harry's manager is pressured into assigning Harry to Project Alpha with the encouragement that Harry is resourceful and will find a way to get both assignments completed according to schedule. Both of these situations can benefit from SMT intervention. My advice is to respect the plans that have been approved for Projects Alpha and Beta. Sit down with the involved parties and negotiate an acceptable revision of both projects. To defer to Harry's resourcefulness and his projects manager's (PM's) management skills to stumble into a solution isn't good strategy.

Part II, Improving Project Success with Human Resources Strategies and Processes (the supply side of the equation) and Part III, Improving Project Return On Investment (ROI) Using Agile Project Portfolio Management (the demand side of the equation) puts out a clarion call to business systems software vendors to satisfy the unmet HRMS needs of virtually every organization.

Position Families

The CPT position family defined in Chapter 3, The Complex Project Team, sets the stage for developing and assembling the CPT. The CPT is uniquely different than the project teams you might be familiar with. The first difference is that in its formation consideration must be given to the balance across the four disciplines of the team with respect to the project profile. Someone on the team must possess a profile that adequately meets the project profile for the most demanding discipline skill. For example, suppose the project requires senior level IT consultant skills. At least one member of the team must be skilled at that level or the team may be exposed to unnecessary IT risk. The second difference is that the team must really be a team rather than just a group of professionals that happen to be assigned to the same project. The complex project manager (CPM) bears the responsibility of seeing that the team really develops as a team. That means the CPT must be open, honest, flexible, and adaptive to the changing needs of the project. Co-location of the CPT members helps a great deal but as we know co-location isn't always possible. Only through a real collaborative effort and the resulting synergy that can be created, will the CPT be successful.

An Historical Perspective[1]

The birth of the information age in the 1950s planted the seeds that would quickly give rise to a contention between the business sides and the technical sides of an enterprise. It originally arose out of:

- Ignorance of the other's domain

- Lack of a common language

- Lack of meaningful client involvement

The contention has changed over the years but persists to this day. Unfortunately it has a harmful effect on complex project risk and contributes to the high rate of complex project failure. A few words about each will be useful.

Ignorance of the Other's Domain

It wasn't too long ago that the “throw it over the wall” mentality was pervasive. What today is called a project wasn't recognized as such in a stovepipe organization. Each business function did its part and passed the effort on to the next business function in the process. The four disciplines were practiced pretty much independently of one another. There was no collaboration. No one functioned as the overseer so there was no control over the total effort. Projects were poorly defined if at all. Failure was almost a certainty. Fortunately that has changed and the business environment of today is characterized by multidisciplinary teams working together on the same project. Collaboration is still a complex issue though and is discussed in more detail in what follows.

Over the past 60 years we have seen the emergence and maturation of the systems analyst from a high-tech professional housed in the IT department to a BA housed in a business unit of the organization. Those who migrated into the IT department are highly skilled development professionals, with their knowledge of business functions the result of having worked on business function applications, with the added experience of managing development projects as well. Some will be very experienced and others much more limited. Those who remained in the BA function can be found in Centers of Excellence (COE) and Communities of Practice (COP). They are squarely placed between the project manager and the information technology professional (ITP) and therefore in the middle of that contention. As we will discover the BA role is challenging and demanding. It is not a static role but a dynamic role that changes as the project, business environment, and market environment changes. Some systems analyst has matured into the professional that I am calling a business process professional (BPP). The BPP is housed in a line of business and has special skills in the design, development, and maintenance of one or more business processes. They are the subject matter experts (SMEs) for those processes. They provide a link between the business unit and the IT department.

During that same 60 years the ITP has matured from a technical professional to one who understands how to apply their technical skills to the business side of the enterprise. In many organizations their systems development life cycle (SDLC) substituted for a PMLC. Since there was only one SDLC at that time (Waterfall Model) there was only one PMLC. The ITP is also placed squarely in the middle of that contention.

To the extent that it still persists we have a contention among the PM, BA, BPP, and ITPs who now find themselves on the same team trying to execute complex projects. That contention is somewhat nullified because each professional has some knowledge and practice skills in the other three disciplines. The more profound the mix of those skills that is possessed by one person, the more effective they will be in working with their fellow team members. During project launch as part of team formation the CPM is responsible for bringing these professionals together to decide on the appropriate team operating rules to minimize any future contention.

Lack of a Common Language

It was very obvious at the beginning of the computer age that the techies spoke a language totally unintelligible to the rest of the world. Other than the techies everyone else was technically challenged. These technically challenged business professionals didn't want to understand. I've lost count of the number of times I have heard the client say: “Oh, that's a technology project and I don't know much about technology. Just do the project and give it to me when you are done.” By some means they told the techie what they wanted, signed a functional requirements document prepared by the techies that translated their wants into a language they didn't really understand, and hoped what they got did the job. Sometimes it did—mostly it didn't.

That barrier is no longer as serious a concern as it once was, but it still exists. The client has learned a lot about technology in the past 50 years and the conversation is somewhat more sophisticated. But the challenge of establishing a common language still exists. It is incumbent on the BA, BPP, ITP, PM, and the client professionals to verify that they each understand the language of the other. If that is not a common practice in your organization, do something about it immediately. It is interesting to speculate just how much of the project failure rate can be ascribed to the language barrier especially as it impacts the requirements gathering and change management processes. For years I have used a process called conditions of satisfaction (COS) (shown later in Figure 4.1) to mitigate the language barrier. I know from personal experience that the COS works.

Figure 4.1 Conditions of Satisfaction

Lack of Meaningful Client Involvement

The Standish Group has been tracking the reason for project failures for several years now. Their 2010 report listed the top ten reasons projects become challenged (shown in Table 4.1). I have added the four disciplines and mapped these professionals' responsibilities into those reasons. Notice how important the roles of the BA and BPP are in neutralizing so many of these reasons. For the first time meaningful client involvement (expressed as user input) was at the top of the list. We've always had client involvement but until quite recently it amounted to little more than signing an arcane functional specification document under threat of project delay if the document was not promptly signed. That characterized the relationship between the techie and the client in the 1950s and even into the 1960s. The techie's toolkit has evolved and now includes joint applications design (JAD), rapid applications development (RAD), prototyping, requirements gathering, use case scenarios, business process diagramming, and a host of other processes that bring the client into active involvement beginning with the scoping phase of the project and continuing through to completion and implementation. The BA has been instrumental in facilitating the meaningful involvement of the client and surely helped increase the likelihood of complex project success.

Table 4.1 Top 10 Prioritized Reasons for Complex Projects to be Challenged (Standish Group CHAOS Report 2010)

Source: Standish Group.

Complex projects are characterized by a high degree of uncertainty and risk. We know that these projects cannot succeed without meaningful client involvement. How to attain that involvement and maintain it over the project life cycle is not an easy matter. Each of the four disciplines is a critical part of that effort and it extends over the entire project life cycle. The best advice I have to offer is for all CPT members to use the language of the client. Anything else will take the client further outside of their comfort zone. It is not realistic to expect the client to adopt the language of the PM or the ITP.

Complex Project Team and Complex Projects

Complex project management is nothing more than organized common sense. If your project management process requires the CPM to do something that doesn't make sense to them given the project situation, then they should have the authority to not do it. They should simply offer their rationale for their decision to skip or adjust the task and move on. Few organizations allow the CPM that much latitude. One of my client organizations does allow the CPM that latitude. All the CPM has to do is state their reasons for not using or for modifying a process step. Management gives them the benefit of the doubt. If the project appears to have been compromised or failed because of that decision, the CPM may be asked to defend their action. For my client organization vesting the CPM with that responsibility and the authority has empowered the CPM and has most assuredly improved team morale.

Discipline Relationships across the PMLC

Table 4.2 is the RASCI Matrix for the responsibilities of each professional over the life of the project. RASCI is an acronym that stands for Responsible, Approves, Consults, Informs, and Supports. The combined skill profiles of the four disciplines must be sufficient to meet all project responsibilities. In this book those skills might be shared between professionals or those skills might be possessed by a single professional who has all of the skills needed to effectively execute the project.

Table 4.2 PM, BA, BPP, and ITP RASCI Matrix.

As you will note in the table, the deliverables are either the responsibility of the PM or the BA. Their performance goals are different. The PM focuses on process, time, cost, and resource management. The BA focuses on the deliverables from the process, and meeting client needs, requirements, and expected business value. These can be at odds with one another but it is that healthy contention that produces success. The goal of their project is to find a solution that meets the expected business value that initially justified doing the project. That project goal is the driving force that helps the PM and BA resolve the contention between their performance goals.

As the PM and BA disciplines continue to mature I'm certain we will see an integration of other professionals such as systems developers, portfolio managers, business architects, and others. This is inevitable because to effectively leverage technology for business value we will need to infuse the practice of these disciplines and create a collaborative business-centric environment.

Problem Definition and Solution Validation

This is a critical deliverable because it sets the tone for the entire project. A solution cannot be defined until the problem is clearly and completely defined. The PM and BA share responsibility for problem definition and solution validation. The major issue here is to drill down into the client request to define the problem. In these sessions there is always the question of wants versus needs. I have often found that what the client wants is not always what the client needs. Clients are often driven to formulate a solution to their unstated problem and offer that as what they want when in fact it is not what they need. The BA is responsible for questioning the client in an attempt to discover the real problem and hence what is needed to solve the problem. In other words, they have to convince the client that what they want is what they need. A Root Cause Analysis or Force Field Analysis can be effective aids to the BA in defining the problem. Both the appropriate BPP and ITP should be consulted because they will often have related experiences that will assist in both problem statement and solution formation.

. . . what the client wants is not always what the client needs. Clients are often driven to formulate a solution to their unstated problem and offer that as what they want when in fact it is not what they need.

Armed with a definition of the problem the BA and the PM can begin to formulate a solution or an approach to finding the solution. If an approach to finding the solution is indicated, that approach can be decided upon once requirements have been documented. Ultimately both the BA and the PM have to assure themselves that what is done in the project will align with client needs and deliver a solution that meets expected business value.

The process of defining the needs works best by using the COS which is a face-to-face meeting with the client. The COS establishes a common language among PM, BA, BPP, ITP, and the client. In most cases the PM and the BA can conduct the COS without the need to include the BPP and ITP professionals. This is a judgment call. The COS process is a structured conversation that may involve all four disciplines using the steps described in Figure 4.1.

The deliverable from the COS session is a definition of what the solution must contain in order to meet client needs. It is documented in the Project Overview Statement (POS) and is the input to requirements elicitation.

Project Overview Statement (POS)

The POS is a one-page document developed by the PM and BA, or the PM and client representative (BPP for example), and signed by the parties who drafted it. It is the first document produced for a potential project and is documented output from a COS session. The POS will often be your first exposure to the proposed project. It contains the high-level description that you should use to decide if the proposed project makes enough business sense to warrant allocating the resources needed to plan the project details.

POS Contents

The POS is always a one-page document written in the language of the business so that anyone who has a reason to read it will understand it. Think of the POS as a two-minute elevator speech to sell an idea to the SMT. I first designed the POS based on a project request document used in the annual planning process at Texas Instruments in the 1960s. Its purpose was to organize the hundreds of requests for new products/processes and to prioritize them for possible investment. Executive management had to read several hundred such requests and they didn't want to be burdened by having to read a 50-page document to make their go/no go decisions. So the POS was strictly limited to one page. It became the filter to reduce the number of product requests and solicit more detail on those requests that passed the filter test.

There are five parts to the POS as described in the following sections. Each part is designed to entice the executive to read on or to reject the request at that point.

Problem/Opportunity Statement

It is most important that this statement be recognized by the enterprise as a problem that has not yet been solved or an untapped business opportunity to pursue. It is a statement that does not need to be defended. The POS will be submitted to the project approval process and the proposer will not be there to defend this statement. Whether or not the project is important enough to warrant a high priority for an investment consideration is decided later. At this point the executive will have an opinion as to the importance of the problem/opportunity statement and decide whether or not to even continue reading the POS.

Project Goal

This is a brief statement of what is being proposed to do about the problem or opportunity. If it is a problem, there should be a statement of what is being proposed to do about it such as to solve the entire problem or just some part of it. If it is an untapped business opportunity, what is being proposed to be delivered through the project?

Project Objectives

These are the boundary conditions for the project goal. A good format for these objectives is the SMART format (Doran, George T. “There's a SMART Way to Write Management Goals and Objectives.” Management Review, November, 1981, pp. 35–36):

- Specific. Be specific in targeting an objective

- Measurable. Establish a measurable indicator(s) of progress

- Assignable. Make one person responsible for completion

- Realistic. State what can realistically be accomplished

- Time-related. State the duration of the objective

I like to think of each project objective as a statement of some part of the project goal. Taken together the project objectives form a necessary and sufficient set of objectives. If all project objectives are met, the project goal is achieved. Every project objective must be accomplished in order to achieve the project goal and no project objective is superfluous. To put it another way, think of the project goal as a pie and the project objectives as all the pieces that make up the pie.

A project objective contains four parts: an outcome, a time frame, a quantitative measure of success, and an action. In many cases the complete statement of a project objective may be spread across several parts of the POS. This is especially true for the timeframe and the success criteria.

Success Criteria

The COS is the foundation of the success criteria and the project objectives offer guidance as to what quantitative measures those criteria should include. Project success is defined as having met all of the success criteria. Some of those criteria may not be realized until long after the project has been completed. A criteria that speaks to a restoration of market share to a previous level, for example. That can't be expected to happen for several quarters.

Success criteria can be of several types. You might be familiar with the acronym “IRACIS”:

IR = Increase Revenue

AC = Avoid Cost

IS = Improve Service

The important thing to keep in mind is that the success criteria must be complete. It must reflect business value that results from the project. By that I mean if the success criteria are all met, the project is deemed a success from a business value perspective. The success criteria are part of solution validation. In other words, achieving the success criteria will result in achieving the expected business value, which is often expressed as part of the goal statement.

The client and their BA and BPP are primarily responsible for establishing the success criteria. They have proposed the project on the basis that if the project is successful it will deliver the business value that follows from achieving the success criteria. This is the return on investment (ROI) for the project. Contrary to senior management thinking, the PM is not responsible for ROI. They are responsible for successfully completing the project as scoped by the client, the BA, and the BPP.

Assumptions, Risks, and Obstacles

There are factors that will affect the outcome of the project. These factors could be:

- Technological (i.e., you will be using a breakthrough technology for which there is not a lot of company experience)

- Environmental (i.e., the market is volatile and there is a lot of new competition)

- Interpersonal (i.e., there is a lot of resistance from some of the business units to the project)

- Cultural (i.e., the project has global impact that is not well understood at this time).

These are all high-level factors and should not be confused with the more detailed risk identification and planning yet to be done. For the purposes of the POS some of these high-level factors should be brought to the attention of the SMT who might have occasion to read the POS. These factors could be show stoppers in which case the project will not get their approval. What you are hoping is that the SMT might be able to mitigate some of these factors and improve the likelihood of project success.

PM, BA, BPP, ITP, and Client POS Responsibilities

All four parties have responsibilities with respect to the POS. The POS is the guiding document for the project team when it comes to scope discussions so the PM must be comfortable that the POS describes a project that they can manage. The BA is a bridge between the PM and the client. The BP adds detailed expertise on the business processes impacted by the project. During the COS session the BA can help clarify understandings and should be the caretaker of the “As Is” and the “To Be” business process(es) that will be affected by the project. The client has to defend the business value that will result from the successful completion of the project. The client has to sell the project to their management and so the contents and presentation of the POS is critical to that defense and they should have a vested interest in its creation.

For a more detailed discussion of the COS process and its deliverable the POS, see my book Effective Project Management: Traditional, Agile, Extreme, 5th Edition (New York: John Wiley & Sons, 2009).

Requirements Breakdown Structure

Requirements define things that a product or service are supposed to do to satisfy the needs of the client. The commonly accepted formal definition of requirements is given by the International Institute of Business Analysis (IIBA) in “A Guide to the Business Analysis Body of Knowledge”:

A requirement is:

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.

2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.

3. A documented representation of a condition or capability as in (1) or (2).

That is all well and good and I'm not going to challenge the definition. I assume it does what it is supposed to do. But let me offer a different perspective for your consideration and practical application. I believe we do a complex project to solve a critical problem heretofore unsolved or take advantage of an untapped business opportunity. Two things link these two types of deliverables:

- The need to deliver business value—the more the better

- Complexity and uncertainty—all of the simple projects have been done

Generating business value is really the only measure of project success. With these goals in mind let me offer a completely different definition of a requirement.

Definition: Adaptive Project Framework Requirement

An Adaptive Project Framework (APF) requirement is a desired end-state whose successful integration into the solution contributes specific, measurable, and incremental business value to the organization.

It is important to see just how different these two definitions are. Using the IIBA definition, a complete list of requirements cannot be generated at the beginning of the project except in very simple traditional project management (TPM) situations. Using my definition will almost certainly result in a complete list of requirements at the beginning of the project. The detailed descriptions of APF requirements will seldom be completely known at the beginning of the project.

APF requirements are linked to business value, which is not the case with the IIBA definition. That is significant because now you are able to prioritize APF requirements with respect to their expected business value. That is not the case with the IIBA definition.

I've long felt that the criterion for defining project success as meeting a specification within the constraints of time and cost is misdirected. It really ignores the business, the client, and organizational satisfaction. My criterion is that project success is measured by delivering expected business value. After all isn't it expected business value that justified the need to do the project in the first place? There are of course some exceptions in the case of mandated and otherwise required projects regardless of whether they deliver business value or not.

So you are probably wondering if this is a better definition and whether using it in your organization makes business sense. Here are five reasons I've put on the table for you to think and talk about.

- Reduces the number of requirements from hundreds or thousands to six or eight. I think of requirements at a higher level than most professionals. Using the IIBA definition it is unlikely that requirements can be complete at the beginning of a project. In fact, most professionals would agree that a complete and documented set of requirements cannot possibly be generated at the beginning of a project except in the simplest of projects. They can only be learned or discovered as part of project execution. That is the approach I take in my APF. On the other hand, using my higher order definition I expect to generate a complete set of requirements at the beginning of a project. Through experience I have found that my higher order definition gives the client and the project team a more holistic view of the project and enables much better business decisions that impact the solution.

- Identifying the complete definition of most requirements happens only through iteration. The requirements list will be complete using my higher order definition. The challenge arises in identifying the component parts of each requirement—the requirements breakdown structure (RBS). These details can only be documented as part of project execution. The criterion for inclusion in the solution is that the component part must either directly contribute business value or support a higher order component part that does contribute business value. This tends to eliminate frivolous additions to the solution that have no obvious business value.

- Simplifies the search for a solution with acceptable business value. If you are emotionally attached to some component part of the solution and cannot demonstrate that it contributes to business value, don't expect to see it in the solution. That eliminates the expenditure of time, money, and resources on something that adds no business value to the solution.

- Choosing among alternative solution directions is simplified. Business value is the great tie breaker when faced with competing alternatives from which choices must be made. I have had experiences where a component part didn't seem to generate business value early on and so wasn't included but at some later iteration the team or client learned that it did and so was included. So “when in doubt, leave it out” is a good practice as you build out the details of a solution. If a component part can contribute business value it will be discovered later in the project.

- Provides for better use of scarce resources (money, time, and people). Using this higher order definition of a requirement there is a return on investment from every part of the solution. The complex project is filled with uncertainty and risk and knowing that your approach uses available resources effectively and efficiently is assuring to the client and your management.

I have always strived for simplicity and intuitiveness in all the tools, templates, and processes that I use. I find that my higher order definition of a requirement meets that goal for me and makes sense too.

The RBS is a hierarchical description of the client's needs as expressed through their requirements document. There are at most six levels of decomposition in the RBS as shown in Figure 4.2:

Level 1: Client statement of a requirement

Level 2: Major functions needed to meet the requirement

Level 3: Sub-functions (for larger more complex functions)

Level 4: Processes that describe a sub-function

Level 5: The activities that describe a process

Level 6: Feature(s) of an activity

Figure 4.2 The Requirements Breakdown Structure

The six levels are not all present in every requirement. The ones that are used are those that are needed to describe each requirement to the appropriate level of detail. So the depth of the structure is not the same for each requirement. The RBS defines what is to be done and can be thought of as the start of a deliverables-based work breakdown structure (WBS). Further decomposition of the RBS actually produces a deliverables-based WBS, which defines not only what must be done but also how it will be done. There is however a fundamental difference between the two. The RBS may not be a complete decomposition of what will be done whereas the WBS must be complete in order for the traditional linear approaches to project management to be appropriate. There is an obvious disconnect here. The temptation is to speculate on the future to fill in the gaps in the RBS. If you endorse this approach, you are planting the seeds for failure.

It is this lack of completeness as portrayed in the RBS that drives the choice of PMLC and the SDLC for software development and other computer-based projects. The two life cycles are inextricably linked. Any project that produces an incomplete RBS at the outset must use some type of agile approach to managing the project. In these situations the obvious conclusion is that the professional who manages requirements gathering and management over the life of the project must be expert at both business analysis and project management. The learning and discovery of heretofore unidentified requirements occur in the iterations that make up an agile approach. In other words, requirements discovery takes place throughout the entire project life cycle and is fully integrated in the management of the project. This is not a situation where a hand-off from a BA to a PM will work. The complexity and uncertainty of the solution and the processes for its discovery negates that approach. A collaborative effort by the PM and BA is needed for maximum impact. My recommendation is that they share project responsibilities as co–project managers.

The RBS is usually the PM's last opportunity to present information in a way that is intuitive to the BA and the client. After years of experimenting with the RBS, I find the hierarchical presentation to be the best choice. It is a dynamic document that will be updated as an artifact of the chosen PMLC.

Project Management Life Cycle Selection

The degree to which the RBS is considered complete will be the guide to selecting the best fit PMLC. The PM is responsible for making this decision with the participation of the BA. The PM's concern is picking the best fit PMLC that available staff, client past behavior, and the environment can support. The BA's input to this process is the extent to which they can garner the requisite client involvement and what they need to do to assure that involvement. So the choice of best fit PMLC has a number of factors to consider.

Project Plan

If a complete WBS is in place the most difficult part of project planning is done. What remains is to estimate task duration, resource requirements, and task dependencies. Using that information an initial project schedule can be built. It might have to be adjusted to accommodate deliverables deadlines and resource availability. The BA can be helpful in revising deliverables deadlines and release schedules based on their having determined requirements priorities with the client.

If the WBS is not complete, an agile approach will be used and the role of the BA will be a more central role. First of all they will be the co–PM. Their added responsibility is to take the lead in updating and re-prioritizing requirements in preparation for each iteration so that the PM can plan the contents of each iteration.

Team Operating Rules

When the project is approved for funding the complete project team is recruited and comes together for their first meeting. In some settings a core team would have been assembled to do project planning and the team membership completed only after funding approval. In any case the first team meeting may be the first time the entire team membership will have been brought together on this project. Initially these people are not a team but just a group of people who share a common goal. They must become a team and the journey to becoming that team begins by having them decide how they are going to work together. Some processes that must be agreed to are:

- Decision making

- Problem solving

- Conflict resolution

- Team meetings

Requirements Change Request

The BA is the clearinghouse for receiving and processing client scope change requests. The BA and the PM will have agreed on the rules of engagement regarding the requirements change request process. I have personally experienced clients who constantly submit change requests with little regard for the impact on the project team. Many expect their requests to be honored with little or no impact on schedule, cost, or resources. The BA is an excellent buffer to protect the PM and the project team from such client behavior. The BA can provide an intake service and review and prioritize such requests before they even get to the desk of the PM. A good BA will filter these requests and only submit them to the PM if and when they make sense to do so.

Agile project management (APM) and extreme project management (xPM) projects do not use the scope change management process you may be familiar with. Instead these projects make use of a scope bank. The scope bank is the depository of all learning and discovery that took place during project iterations. At the end of an iteration, the scope bank contents are analyzed and prioritized for inclusion in the solution. The highest priority items are candidates for the next iteration.

Change Management

Requirements change requests are input to the change management process. The PM and BA are jointly responsible for defining and managing the change management process. Some of the issues to resolve include when to schedule the implementation of the change into the project plan. The BA's interest is how the release schedule will be impacted. The PM's interest will be how to accommodate the change to minimize the impact on cost, schedule, and resource requirements. The PM may present a prioritized list of alternatives they can accommodate and the final decision for implementation made by the BA.

Risk Management

Risk management is important across the entire PMLC. As the project becomes more complex and uncertain risks go up significantly. The collaboration of the PM and the BA heightens with every increase in complexity or uncertainty. Chapter 6 provides the details for risk identification, risk assessment, risk response planning, and continuous monitoring of project risk.

Performance Reporting

The PM is in the best position to identify and track the metrics that will be used to periodically measure project performance. If performance falls below nominal or displays trends that if continued will seriously compromise project deliverables or lead to outright project failure, then the BA may be responsible for identifying and recommending corrective measures to the PM.

Putting It All Together

So the challenge to the CPM is to mold the CPT into a lean, mean fighting machine. By its nature the project is risky and filled with uncertainty. Only the very best effort that can be put forth will be sufficient. As a member of the SMT you bear much of the responsibility of providing infrastructure and support services that make that effort possible.

Note

1. The remainder of this chapter is an adaptation of materials from Chapter 1 of my earlier book The Business Analyst/Project Manager: A New Partnership for Managing Complexity and Uncertainty (Hoboken, NJ: John Wiley & Sons, Inc., 2011). That book discussed collaboration from the perspective of the PM and the BA. In this book that collaboration is expanded to embrace the collaboration of all four disciplines that describe the CPT position family. It is also repurposed to discuss collaboration for your benefit as a member of the SMT.

Chapter 5

A Professional Development Model

Professional development planning processes all reduce in one way or another to answering the following questions:

- Where am I?

- Where do I want to go?

- How will I get there?

- How well am I doing?

These questions form a repeating sequence as the individual progresses along a defined career path to short-term and long-term positions. It is expected that changes in career direction will occur as the individual develops a better understanding of the job market and the opportunities it presents to them. If the individual is employed, there will be opportunities for advancement with their current employer too.

The senior management team (SMT) has a very definite role to play in this model. In coaching, mentoring, and developing the supply of professionals to staff complex project teams (CPTs), and to align with the demand for such professionals. It becomes clear how valuable the SMT's role will be to fulfilling the strategic goals of the organization.

In addition to your role in advocating and participating in professional development, you have a very self-serving role too. Qualifying for a position in the SMT is usually not an accidental event. It has to be planned for. Don't expect to get these promotions just because you are a nice person and happened to be hanging around the office when the opportunity arose. It can happen but it's like investing in the lottery. Since you own your career no one is going to do this for you. You will have to develop and maintain a plan that will result in your achieving the professional development targeted to your goal position. That requires a concerted and diligent effort with the support of one or more mentors. Most mentors will be members of an SMT for some organization.

Since you are already a member of the SMT you might ask: why should I be interested in preparing others to compete for a position in the SMT. I recall a colleague who was passed over for promotion to a director level position and couldn't understand why. She was fully qualified for the position she sought and there were no competing candidates. The reason given by the HR Department was that she had not prepared someone to take her place so that she could accept the promotion when it arose. The bottom line is that you need to invest in the future of the SMT by supporting the development of its future members. And don't be hesitant in preparing someone to take your place when you are ready to move on.

Even though you are a member of the SMT you may still have future career and professional development goals that you are working towards. So this chapter is for you as a manager of your own career and professional development goals, and for you as a manager of professionals who have their own career and professional development goals.

The Professional Development Plan

A Professional Development Plan (PDP) is a document drafted by the individual in collaboration with their manager, one or more mentors, and perhaps a career counselor from the HR department. As a member of the SMT it is highly likely that you will be invited to help an individual with one or more of these roles.

The PDP planning horizon usually spans a full year with reviews on a quarterly basis or as requested by the individual. When used in a job situation the temptation is to schedule a PDP planning session in conjunction with an annual performance review process. In practice it is usually better to schedule PDP development/updating and the performance review processes at different times. Scheduling the performance review and career planning sessions six months out of phase with each other is my recommendation. Conducting a performance evaluation and career planning session concurrently is strongly discouraged. The performance review is not a safe harbor for the individual. In a performance review they are under pressure and often put in a defensive position. In a career planning session they are in dream mode and don't need any pressure imposed on them from some other conflicting activity imposed upon these sessions.

The structure of the PDP process is portrayed in Figure 5.1. First note that the PDP process is never ending. Well I suppose it does end but that will be at death or after winning the lottery. Note that the plan is defined by doing nothing more than continuously answering the same four questions. Between each round of answering the four questions the individual's professional life can take several turns that justify reconsidering answers from the previous round.

Figure 5.1 The PDP Planning Process

A PDP is the heart of every career and professional development effort. The SMT has a major role to play in PDP implementation and support and that is discussed in the next section. If your organization doesn't have such a process, don't use that as an excuse for not doing it. If I worked for such an employer, I would still seek out my manager to work with me on the PDP and to be my coach and advisor. I keep telling my mentees that their employer owns their job but they own their career. Burn that idea into their brain and don't let them ever forget it. Even though you are a member of the SMT, if you don't keep this in mind but default to your employer to take care of your career growth, you will be making a big mistake. Employers have already shown their lack of interest in loyalty to their workers so don't expect that to change anytime soon.

Seek out one or more professionals to be your mentors. Typically these will be people who have achieved professional goals not unlike your own. The fact that they have been there and done that, means there will be valuable experiences for them to share with you. I remember that several years ago while I was still in my 30s that my primary mentor was in his 80s and lived across the country and I only saw him once or twice a year even though we stayed in contact by phone and snail mail (the Internet was still someone's dream). Basically he was my hero and I wanted to emulate his professional accomplishments as much as I could. Mentors can change over time and you can have more than one at a time. Who are the people you admire and why do you admire them? Answer that question and you have a good start on identifying potential mentors.

A PDP should contain both short-term and long-term career goals. The short-term career goal should cover the next planning horizon—most likely one year. It will be a detailed description of what is planned in order to achieve the short-term goal. The long-term career goal will be a less detailed description of your ultimate goal.

By way of introduction, I think that a good PDP is a plan developed by you and your coach/mentor/manager and consists of the four phases as briefly defined in the following sections. While the following discussion is designed to help you as an SMT member understand the process, it applies equally well to you as a person with career and professional development goals of your own.

Where Am I?

In other words:

- What position do you occupy?

- What is your recent assignment history?

- What is your skills and competencies profile?

This is your resume and it puts you at a starting gate from which you can begin to put some short and long-term goals in place.

Where Do I Want to Go?

While it may seem trite, I like to ask everyone that comes to me for career advice “What do you want to be when you grow up?” Some of the answers are amusing:

- I don't want to grow up.

- Employed.

- I want your job.

In all seriousness, this is a basic question that must be answered before any PDP can be built. The answer isn't a lifetime decision either. Rather it is the place you would like to be for your next position and in the long-term based on what you currently know and understand and what the business situation is likely to be as your career and job preferences mature. You can change your mind every Tuesday if you like. The important thing is that you have a career goal. You know where you are and where you want to go and you can put a plan in place to work towards that goal. The long-term goal can be very specific: “I want to be the CIO at Wal-Mart before my 50th birthday.” Or it can be very general: “I want to be recognized by my colleagues as a thought leader in complex project management.”

The process for answering the question is through relaxed but serious conversations with your manager and mentors. Your manager is your best source for understanding where the opportunities lie for your short-term career prospects with your current employer and how best to prepare. You should seek them out for that advice. Longer-term prospects are best commented on by those who have a strategic perspective on the future and where the staffing opportunities are likely to be found. One of your mentors might be a person who occupies the position you seek as a career goal. You should seek their advice for working towards that goal. Arranging informational interviews with senior-level managers is also a good strategy. When you can get some time with them they usually love to talk about themselves.

What if your short-term career goal is to have your manager's job? A good manager would welcome that news. When it is time for their promotion they would like to have a subordinate ready and willing to step into their position so they are free to take that promotion.

What if your long-term goal is to work for another company in a senior executive position? Again a good manager should welcome that news too. They will have plenty of opportunities to find out what they need to do to remove the reasons you want to grow your career somewhere else. If there is a way they can correct the situation and you decide to stay, they know they will have a loyal executive manager.

Both your manager and any senior-level manager whose advice you seek should be able to translate your career goals into a position class or sequence of position classes that form a career path eventually leading to your ultimate career goal.

Your employer owns your job. You own your career. Don't ever forget that.

How Will I Get There?

At this point you know where you are (the position family you are in and the specific position in that position family that you occupy) and where you want to go (the position family of your career goal). So your next step is to build a career path for getting there. In fact you could build several career paths that all lead to the same destination. One of those many career paths will be the one you pursue in greater detail. That is what the PDP is all about.

And that is the answer to this question. The answer however will be given one step at a time. That first step will be the PDP for the next planning cycle—probably 12 months. In preparation for your next 12-month experience you will have put a four-part PDP together.

The PDP consists of:

1. Experience acquisition

2. On-the-job training

3. Off-the-job training

4. Professional activities

Each part is described in the following sections. Typically you will have reviews of the progress you are making. Those are often quarterly review sessions with your manager. With that thought in mind the PDP should be very detailed for the next quarter and have lesser detail for the outer quarters.

Experience Acquisition

This part of the PDP describes the acquisition of further experience mastering the skills and competencies needed in the current position. The further time in grade experience is also related to qualifying for entry into the next level position in the same or a comparable position family. There may be certain areas that should be the focus of that additional experience—perhaps an area of noted weakness that needs improvement. So this is a “do more of the same” part of the PDP with the above considerations taken into account.

Here are two examples of experience acquisition as they might be represented in the PDP:

- You are a project manager (PM) and would like to seek out project assignments that have more of a business analysis focus than you have been doing.

- Support complex project management (CPM) professionals who are more senior to you and have business analysis (BA) skills that you need to further develop in order to better meet current position requirements.

On-the-Job Training

First of all, training does not imply attending a formal course. Training can be very informal. For example, just attending an activity facilitated by an expert in the skill area of interest and observing what happens. Watching how someone does something is a learning experience. For some professionals, observation is the primary learning style.

On-the-job training is undertaken to increase the proficiency of skills and competencies needed to improve performance in the current position. If performance in one or more skill areas is below a nominal performance level, then training may be required to bring that performance up to acceptable levels. Training need not be expensive and certainly does not have to be time consuming. There are several opportunities right under your nose. For example:

- Offering to help a colleague with one of their tasks to improve your skill to perform that task on your assignment

- Attending a workshop to improve a current skill you are using on your job

- Volunteering to join a project team that will further challenge you to take a specific skill to the next level

You just have to pay attention and be on the outlook for them. For example, John is a BA manager and has just been assigned to manage an order entry/fulfillment process improvement project. John has had limited experience managing improvement projects and he wasn't too confident he could handle this project. There had been several projects in the past to improve the order entry/fulfillment process with little success to report. John's career goal was to become a senior PM and eventually a consultant to the order entry/fulfillment process. So John asked Michelle, a senior PM consultant, to help him improve his project management skills from the perspective of the BA on a process improvement project.

Off-the-Job Training

The purpose of off-the-job training is to increase skill proficiencies to the level needed to qualify for the next or some future position in your career plan. In other words, it is not relevant to meeting any current skill proficiencies associated with current job requirements.

For example, Harry is a BA task leader. His long-term career goal is to be a BA consultant. His short-term career plan was to become a BA associate manager. Since his project management skills are very limited he needs to get started on them. He is good friends with Larry who is a BA senior manager. Larry is respected among the BA community as one of the best complex project planners and Harry felt that Larry had a lot to offer him. Larry was more than willing to be Harry's mentor and also to help him learn project planning. Because he was so well respected for his project-planning skills, Larry was in high demand and always very busy. Harry approached Larry and asked him if he could help Larry out in some way in return for which he could observe Larry. To Larry that offer was a no-brainer and so he took Harry under his wing. Harry shadowed Larry and began learning project management from the ground up. When Larry retired Harry took his place as a BA senior manager and one of the organization's best planners. Harry was now one step away from his long-term career goal.

Professional Activities

This part of a PDP addresses participation in activities that are not necessarily related to any current or near-term career goal. Rather they are just experiences that relate to your long-term professional interests. They aren't necessarily directly related to these either. They might be related to gaining a better understanding of your company's business. For example:

- Reading the literature on your profession or your company's lines of business

- Obtaining a better understanding of your competitors and how you might leverage your project management and/or business analysis expertise to improve your company's market share

- Involvement in a related professional society at the chapter and national levels

- Conference attendance and networking with other professionals

How Well Am I Doing?

The PDP should be written so that it can be used to track progress. Just like someone would develop an acceptance test in the form of a checklist, so also should PDP performance tracking be in the form of a checklist. These checkpoints should be held quarterly with a career advisor and on an as-needed basis as well.

In addition to tracking progress against the plan on a quarterly basis so also should consideration be given to revising the plan on a quarterly basis. These could be as simple as taking advantage of an opportunity that wasn't known at the last checkpoint and which should be included in the PDP. Or they could be a little more comprehensive and focus on changing career paths or even career goals. In Figure 5.1 that is the feedback loop to “Where am I?” and the process starts all over again.

The PDP should be updated at least annually. Even though it is an annual plan there will be unexpected events that suggest revisiting and perhaps revising the PDP before the annual update date comes about. For example:

- The professional gets laid off.

- The job disappears.

- The company is acquired by a competitor.

- The company closes.

- An unexpected opportunity arises.

Given the new situation the career goal should be changed. The opportunity that gave rise to the current career goal might have disappeared or changed to the point that it was no longer attractive. Demand for the position might have changed or even disappeared altogether. For example, many programming jobs have been moved offshore and not likely to return. So a goal of becoming a director of application development is no longer as attractive as it once was.

Taking Charge of Your Career

There's more than one way to skin the cat and if you aren't comfortable implementing the PDP as described, then here is another way that you might find useful. I've used it for several years now for my own career and professional development planning and it works great so I'm sharing it with you. I have used some form of PDP for my entire professional career. The four-part PDP was most useful early in my career while I found the format shown in Figure 5.2 most useful later in my career. Use it or lose it!

Figure 5.2 A Variation of the PDP

We've all heard of vision and mission statements. I've added tactical plan to that and so Figure 5.2 is another version of a PDP. This is my 2011 PDP.

My vision statement hasn't changed in 20 years. I guess that means I figured out what I want to be when I grow up! The same can be said for my mission statement. I've changed the interpretation somewhat but not the statement. The tactical plan is a dynamic annual plan. I revise it in December of every year effective for the following year. So for 2011 I plan on making two public presentations. One presentation is done and the other is in planning. One executive report is finished and will be published soon. The other is in preparation and will be published in late summer. EII Publications has been formed and I'm just waiting on the legal processes to catch up with me before I go to the next step in my launch plan. The first product is planned for publication early in 2011. The book manuscript has been submitted to the publisher and will be published in October 2011. So I guess I'm on track to complete my tactical plan by the end of 2011!

Role of the Senior Management Team in the Personal Development Program

The SMT is the enabling factor in any effective PDP. First of all the organization has to demonstrate that it is committed to the professional development of its people. That commitment can be demonstrated in a number of ways as discussed below.

Even if your organization does not have a formal PDP process in place you as a member of the SMT can establish a process for your direct reports. Within the scope of your business unit you can advise and develop your staff. If you really believe in the PDP as a process for growing a cadre of CPMs and CPT members, sponsor just such a project!

Job Opportunity Bulletin Service

A job opportunity bulletin service (JOBS) should be implemented and actively interact with every employee. The service should include the following contents and features:

- Open positions

- Vacant position descriptions and application process

- Vacant sabbatical positions

- Projects open for work

- Volunteer opportunities

- Opportunities to observe an individual perform an assigned task

- Opportunities to assist an individual perform an assigned task

- Archives

- Project notebooks for completed projects

- Final project reports

- New additions to the professional reference library

- Meetings

- On-site lecture series

- Upcoming conferences and trade shows

- Local professional society meetings

- Other resources

- Managers who are available to be mentors

- Request for project proposals

SMT Mentor Program

Every member of the SMT should be available to serve as a mentor to at least one member of the professional staff regardless of their level in the CPM position family. While this will often be the individual's manager it could be anyone on the SMT. Being a mentor means you are willing to make yourself available to respond to your mentees whenever the need arises. This could be through regularly scheduled sessions, ad hoc phone calls, or email exchanges. Your mentees determine the agenda.

A mentor/mentee relationship is a very special and confidential relationship. The mentee is looking for guidance regarding their career goals and advice as to how best to achieve those goals. In many cases the mentor will be an individual who has achieved the position the mentee is seeking.

The PDP will often utilize the mentor as part of the preparation process.

Putting It All Together

The organization will never succeed in CPM without a comprehensive program for growing the professionals that will manage and be team members in complex projects. That program needs to align with the current and future staffing needs of projects. Understanding the relationship between supply and demand for CPMs and the relationship with the strategic plan is essential. All of the topics discussed in this book need the strong support of a PDP.

Chapter 6

Integrating the Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional into the Project Landscape

In Chapter 3, The Complex Project Team, we discussed the need for generalists as well as specialists on the project team. That led to the definition of a multi-discipline position family that included project management (PM), business analysis (BA), information technology (IT), and business processes (BP). In this chapter I want to discuss ways that professionals who are skilled in one or more of these disciplines can be used most effectively on complex project teams (CPTs).

Much like the earlier chapters, this discussion will be future oriented. human resource management systems (HRMSs) are not sophisticated enough to support the strategy that you will need to implement to be successful with complex projects. From a reading of this chapter you will clearly understand what needs to be done to effectively staff a complex project. For all of you I suspect that an HRMS with the needed functionality will have to be developed.

Project Complexity Assessment

In her award-winning book Managing Complex Projects: A New Model (Vienna, VA: Management Concepts, 2009) Kathleen Hass introduces a definition of a complex project. I have adapted her spider chart to relate complex projects to the senior management team (SMT) as initially shown in Figure 1.1 and repeated in Figure 6.1.

Figure 6.1 A Complex Project

Project Complexity Model 2.0, Kathleen B. Hass © 2010, Kathleen B. Hass & Associates, Inc.

The project profiled in Figure 6.1 is challenging from the project perspective as well as the enterprise perspective. From the project perspective, the problem and solution are moderate to highly complex, and that, coupled with the level of IT complexity, will be particularly challenging to the CPT. From the perspective of the enterprise, three of the four factors are moderate to highly complex.

So armed with this complexity assessment what can the complex project manager (CPM) do and what can the SMT do?

CPM Strategy

Beginning with team building, the CPM needs to elicit help from senior-level IT consultants. This project includes a high level of IT complexity. Perhaps it is the use of a new technology unfamiliar to the organization or that the solution requires a challenging design and application. In either case their specialist knowledge will help reduce some of the risk associated with discovering and integrating the appropriate technology.

The second area involves the client. A high level of meaningful client involvement will be needed to bring some clarity to the problem and especially the solutions that are suggested. This need is common to every complex project, and calls for a senior-level professional with a strong BP orientation in the business processes to be involved in the project. The business process professional (BPP) could be further supported by having a senior level BA professional also on the team.

SMT Strategy

In your role as a member of the SMT you need to address the three factors that are of moderate to high complexity for the project profiled in Figure 6.1:

- Level of organizational change

- Requirements volatility and risk

- Strategic importance, political implications, and multiple stakeholders

Is your organization and in particular your area of responsibility change tolerant or change intolerant? You will need to prepare it for complex change. Stay involved with the changing requirements details too. Continuously assess the impact of change on your business unit and convey an air of support and encouragement to your subordinates.

Understand that the challenge facing the CPM is daunting and your support of the CPT and CPM is critical. Project risk goes down dramatically if the CPT is really a team and not just a group of professionals. Specifically the SMT can collaborate and:

- Give the CPT a physical space that accommodates the entire team and that they own for the duration of the project.

- Equip the space with the equipment they will need to work effectively together.

- Minimize the other assignments and distractions of every team member.

- Minimize the number of meetings, formal reports, and approvals they will need, and generally stay out of their way.

- Support the efforts and requests of the CPM to build an effective team.

- Understand that the deliverables from a complex and uncertain project can only be estimated and that with your support the CPM will deliver the most business value possible given the time, cost, and human resource constraints.

- Empower the CPM with the authority to work unencumbered and so be as creative as needed.

- Hold the CPM accountable for what they have committed to do.

I recognize that reality steps in and some of these accommodations may not be possible. I just want you to be aware of the needs of the CPT as they take on the significant challenges of a complex project. The role of the SMT is to create as much of this environment as corporate policies and practices will allow. In some cases you might want to consider a temporary leasing of the off-campus facilities they will need.

Generalists Versus Specialists

I'm a firm believer in complex projects having a team comprised of both specialists and generalists. There is growing interest in how generalists and specialists can contribute to complex projects. The argument in support of the generalist is that they have the ability and skills to keep options open and may see solutions detail where a specialist is constrained to their span of knowledge and can easily miss a clue about the undiscovered parts of the solution.

Generalist/Specialist

We know that the PM as a specialist takes the lead in adapting and managing the process for defining and solving the problem; the BA as a generalist adapts the best fit tools and templates to the business processes in the project; the information technology professional (ITP) as a generalist integrates the best technology available; and the BPP as a specialist takes the lead in adapting the solution and installing the deliverables. See Table 4.2 in Chapter 4. If you hold to this, then it is obvious that all four disciplines are involved in the project from beginning to end. This brings up a discussion of the role of generalists and/or specialists on the project. Calling the PM a specialist, the BA a generalist, the ITP a generalist, and the BPP the specialist is too simplistic and not correct. A detailed discussion of generalists versus specialists is beyond the scope of this book but a few observations with respect to their roles on a complex project are within scope.

The Role of the Generalist on the CPT

In general (pardon the pun) the generalist's role is to view the project in the context of the organization. At the strategic level they should make sure that the direction of the project is in alignment with the direction the organization has defined in its strategic plans. At the tactical level their role includes:

- Assuring that the problem has been framed correctly and that its scope is not unnecessarily too limiting or conversely too optimistic

- Viewing the problem and its solution in the context of other problems they have experienced with a view towards incorporating best practices

- Looking for any learning from prior projects that they can leverage to the advantage of the current project

Every complex project must have at least one team member with this perspective.

By virtue of the fact that the PM will have broader experiences in the organization they will be aware of related projects, client behaviors, management strategies, and solution approaches that may be of value to their current project assignment. For the same reasons the BA and ITP will have this vantage point.

Further to the point, the PM and ITP are likely to have a broader and deeper understanding of the existing business processes and the systems that support them than would the BA or BPP. The PM is in the best position to bring these experiences and understandings into the current project. The ITP contributes the same with technology applications and experiences. As a generalist the PM must assure an organization-wide view of the problem. The solution needs to support that enterprise-wide view. BPPs are not expected to have an organization-wide view but rather a view whose scope is constrained to the particular business function(s) they are aligned to. The BA is the subject matter expert (SME) on the tools, templates, and processes as they apply to all business processes.

The typical BPP would have a much narrower view focused on the business process they support and perhaps a few directly related processes.

The Role of the Specialist on the Project Team

The PM is the SME for project management on the project team. The PM specialist can keep the organizational context and impact, front and center, and with the business unit they propose solutions.

As a specialist the BA brings the deepest understanding of a specific business process involved in the project and can be the most effective linkage between the PM and the client. If more than one business process is within the scope of the project, more than one BPP specialist may be needed. As a generalist the BA does not have SME capabilities for any particular business process rather they have a toolkit of templates and processes that can be applied to any business process. There are roles for both types of BAs. The type of project will dictate whether a BA specialist or generalist or both are needed.

Does Every Team Need Generalists and Specialists?

It all depends on the type of project.

Traditional Project Management Projects

A tradional project management (TPM) project whether it uses a linear or an incremental project management life cycle (PMLC) model, needs specialists for the product or process under consideration. Since the goal and solution are clearly and completely stated, a generalist is not needed.

Agile Project Management Projects

An agile project management (APM) project, whether it uses an iterative or an adaptive PMLC Model, needs generalists to keep the options open for solution discovery, and specialists in the product/process under consideration. Having both a generalist and specialist focus on the project team is critical for process/product design, development, and improvement projects. The two can interact to create a synergy as the solution is sought. The generalist can draw upon similar past experiences and their broad knowledge to suggest a solution component and the specialist can adapt the suggestion to the specific process under consideration.

Extreme Project Management and Emertxe Project Management Projects

These are the most complex of the projects an organization encounters. An extreme project management (xPM) or emertxe project management (MPx) project needs specialists in the product/process area under consideration. That means the PM needs to have more BPP expertise not project management expertise. A generalist may be of some help. The more critical the project the more I would depend on a co–project manager (co-PM) model. One of the co-managers is from the PM side and the other is from the client side. They share equal responsibility and authority for project success or failure.

Project Manager, Business Analyst, Business Process, and Information Technology Skill Profile

As generalists become more pervasive in the organization you should see more and more professionals whose skill profile includes more than one discipline. For example, you probably know several professionals in your organization that have both PM and IT skills in their profiles. Most PMs have some skills in BA as most BAs will have some skills in PM. The PM and BA disciplines are quite complementary of and dependent on each other. With the passage of time all PMs, BAs, and BPPs will have acquired some level of proficiency in IT. Through the assignments they are given all professionals will have some proficiency in BP in one or more specific business processes. The bottom line here is that every professional has the skills of a generalist to some extent. All four disciplines will be visible in their skill profile.

The specialist will always have a place in the complex project position profile. Their roles will be consultative and they will assist with the most complex projects. While they might have all four disciplines present in their skills profile they will have one discipline that stands out among the others. This will be the area where they can contribute the most to solution discovery and integration.

A PM and BA Profile

It is quite common for an individual to have a skills profile that is strong in these two disciplines. The PM and BA professionals are an interesting contrast in the sense that they are simultaneously generalists and specialists. They are generalists by virtue of their robust process knowledge of their disciplines. They are specialists in that they have seen applications of their discipline in specific business processes including both BP and IT.

So it opens an interesting and hotly debated topic. Could such an individual simultaneously assume responsibility for both disciplines on the same project? That answer is obvious. Yes they could. Perhaps the more important question is should they simultaneously assume responsibility for both disciplines on the same project. My answer is: It all depends. Let's explore that in more detail.

Combined PM and BA Roles on the Same Project

Obviously for small complex projects and in cases where these skills are scarce, combining the roles into one position may be the best or only alternative. I have had situations where I was that individual. My role was strictly as a generalist and so I used the co-PM model with a BPP as my co-manager. So the project leadership had both a generalist and a specialist focus partnering for project success.

Separate PM and BA Roles on the Same Project

The argument here is that there is so much to be done that separate professionals were needed. For large projects this is appropriate. The PM and BA need to decide how they can best share management roles and responsibilities for the success of the project. Among the questions they should answer are:

- Will they equally share project management responsibilities as co–project managers?

- Does the BA have the authority to make decisions for the client?

- What is the relationship of the client to the PM and the BA?

- How will the scope change process be managed?

- How will the project roles and responsibilities be assigned to the PM and the BA?

The more complex the project, the greater the need for both a PM and a BA each fully qualified to manage the project. So the PM should be fully capable of functioning as a BA and the BA should be fully capable of functioning as a PM. The ideal staffing is to have separate individuals in each role but there will be occasions where that is not advisable and one person will be simultaneously responsible for both roles.

There are projects whose successful completion has eluded the organization even in the face of repeated attempts. In some cases finding an acceptable solution to correct an anomaly in a product or a performance issue in a business process is critical to the success or even survival of the business unit. These projects are the most challenging a PM will ever encounter and the best staffing solution available must be put in place. That means having personnel on the team who have expertise in both project management and business analysis. Having these dual skill profiles in no way implies that these professionals will have dual project responsibility for both project management and business analysis. They might but that is the topic of another discussion.

Using the PM and the BPP as Co–project Managers

As the project becomes more complex I strongly advise that the co-PMs be a PM and a BPP. Both the PM and the BPP equally share responsibility for the outcome of the project. If the project is progressing well under this co-PM model, the management problems will be minimal and the co-PMs will be of one mind. Nothing breeds satisfaction and cooperation more than success. The problems arise when the project is not progressing as hoped. Assuming that the co-PMs are really equally responsible they must agree on all decisions and actions. If one of the pair digs in, the outcome could be disaster for the project. Rather than depending on a consensus decision I would favor some other type of tiebreaker. For example, defer to the judgment of the BPP for issues related to the product or business process and to the PM on matters related to the project management process. Alternatively the decision might be based on what is best in terms of delivering acceptable business value. I am assuming an open and good faith effort by both co-PMs.

How Will the Scope Change Process Be Managed?

It all depends on the type of project.

TPM Projects

Uncontrolled and frivolous change requests from the client are the bane of most PMs. In a TPM project they can completely disrupt all of the effort that went into creating the project plan. Conversely, in an APM or xPM project the reverse is true and the absence of change is disastrous. The project will never converge on an acceptable solution in the absence of client change requests. In both cases the change requests occupy team members in analyzing the request and its impact on the project plan. Schedule, cost, and resource requirements are affected. Too many change requests will seriously detract from time available to be spent on building the deliverables. For projects that will likely generate a steady flow of client change requests, having a BA on the team is indispensable. Their role with respect to change requests includes:

- Working with the BPP and the client to validate and document the change request

- Prioritizing the new change request with all other change requests from this client for this project

- Agreeing with the client on the change request submission strategy

- Collaborating with the BPP to choose the best alternative change action

- Proposing the change action to the PM

The BA should be senior enough in their discipline and have enough credibility with the BPP and the client to have full responsibility for managing the change process on the project. Scope change management will remain the responsibility of the PM as it should. The BA will be the intermediary between the client and the PM in negotiating and accepting change requests.

APM, xPM, and MPx Projects

For the complex project profiled in Figure 6.1 requirements change is expected and a good business process must be in place to manage scope change. Whatever quadrant the project happens to fall in, change is critical to success and so the change management process must be clearly documented and managed. For those CPTs that do not include a BA, that responsibility falls on the shoulders of the PM. The BP is generally not a good choice because of the need for objectivity in the decision making process. The role of the BP is to choose among alternative change actions recommended by the CPT. My preference is for the BA to be responsible for change request intake, processing, prioritizing, and submission. In the absence of a change control board, the BA on the team assumes responsibility for this function.

For APM, xPM, and MPx projects the scope change process you are probably familiar with is replaced with the scope bank. The scope change management process you are probably familiar with is not used outside of the TPM project environment. The scope bank houses all learning, discovery, and change ideas since the beginning of the project that have not been formally prioritized.

Mapping the Project Managers and Business Analysts into the Project Landscape

The mapping all depends on the type of project.

TPM Project Managers

Some of the TPM projects will be very simple. In such cases the project management and business analysis work can be managed by the same person. Perhaps they are projects that have been done repeatedly and for which a template work breakdown structure (WBS) exists and can easily be modified for the project at hand. There might be a parts list that can be adjusted accordingly. A well-defined risk management plan has been honed over the years with previous similar projects. The skills that the project team will require are established and so staffing is straightforward. Many of the team members will have worked together on previous projects, so their work styles and habits are known by the team. For example, installing a network in a field office would fit these conditions. Everything is defined and ready to start. These projects can be managed by a PM. Conversely, many BAs will have the minimal project management skills to effectively manage these simple projects. A BA with a career goal that includes project management would be well-served by gaining experience managing such projects. The business analysis content of these TPM projects is minimal. The assignment draws more on the BA's project management skills than their business analysis skills.

Projects that will be managed using a linear TPM model will be candidates for having a BA manage them. Projects that will be managed using an incremental TPM model are best managed by a PM.

APM Project Managers

APM projects can range from those whose solution is almost complete and alternatives to complete the solution are available, to those projects whose solutions are almost totally unknown. Projects at this level of complexity may have been attempted before without a satisfactory result. So APM projects have a significant range of complexity and uncertainty. To be effective in these projects the project managers must have a strong resume of successful APM experiences.

The product/process content of the project will determine whether a PM with minimal BA skills or a PM with extensive BA skills is a better fit for managing the project. APM projects can benefit from having co-PMs, for example one manager could be a strong PM and the other could be a strong BA or BPP. For those APM projects with little of the solution known at the outset and the project known to be very complex and having high uncertainty, the co-PMs should both have strong skills in PM and BA.

xPM and MPx Project Managers

All of the projects in these two quadrants are high-risk projects and require xPM project management models. Much of the risk can be aligned with “looking for solutions in all the right places” or undertaking a project that has no solution that is acceptable from a business value standpoint. The best mitigation strategy for these situations is to recruit as creative a project team as available and stay out of their way. The project team is a major determinant of project success and there should be no barriers to the team exercising their creativity. Depending on the criticality and importance of the project the CPM should have both project management and business analysis skills. Projects whose work plan is fairly well defined, could be managed by a BA with minimal PM skills. At the other extreme, when the work plan is not clear and the project content is quite uncertain a person with strong PM and BA skills is a better choice to manage the project. These are the majority of the projects in the xPM or MPx quadrants.

So the remaining question is whether the PM who is managing the project will also be responsible for managing the business analysis activities on the project. Someone on the team must be an SME for the product or process under consideration. That could be the BA or BPP or even the PM. So the conditions under which one person should have responsibility for both roles are:

- The business analysis content is the major activity in the project such as some APM and most xPM projects

- Scarce project manager resources

- Small and very simple TPM projects

I think the major consideration is the skills profile of the available project manager and business analyst candidates.

Putting It All Together

You should now appreciate the complexity of the CPM, BA, BPP, and ITP interactions and the options for their assignments. A one-size-fits-all division of roles and responsibilities will not work. Every question regarding their being assigned specific roles in a project is answered the same way: “It all depends.” Even that answer can change as the dynamics of the project play themselves out. The world does not stand still because you made a staffing decision and are now managing your project. Change is constant and don't think otherwise as you make staffing decisions. You don't know what changes will arise or when, and when they do occur you don't know what impact, if any, they will have on the team structure and the future of the project.

The major opportunity that this integration presents is to favorably impact project success. We know that the top reason for project failure is lack of client involvement. Permit me to change that reason to lack of meaningful client involvement. We've had client involvement for years but it was never meaningful involvement. It was more like token involvement. The relationship between the client, the project, and the project management team is critical to supporting or not supporting that involvement. That means that the management staffing decisions must be decisions that are most supportive of engendering that meaningful involvement.

So my final advice to every CPM, BA, BPP, and ITP is to always pay attention to the management dynamics of the project. Always! That attention is best if it includes constant communications among the four types of professionals to make sure that the best fit management approach is always used.

Part II

Summary

Organizational Challenges and Mitigation Strategies

We have defined the processes to be put in place in order to maintain the alignment between the demand for project teams and the supply of human resources needed to construct these teams. There are four major challenges that the SMT faces even with these processes in place.

Balancing Supply versus Demand of Skilled Professionals

The first and most complex challenge is to attain and maintain the balance between the skills inventory and the demand placed on that inventory by the continual stream of project proposals coming into the portfolios. This is not a static challenge but rather it is a dynamic challenge. The demand for skills changes as the stream of project proposals changes and even the best of processes can only forecast that demand. The available skills inventory changes as existing professionals gain in knowledge and experience and with turnover taken into account, the available skills inventory can only be forecasted too.

Strategic Project Gap

The strategic project gap is the difference between what we should do and what we can do. The Graham-Englund Selection Model is the foundation of this and Part III, Improving Project Return On Iinvestment (ROI) Using Agile Project Portfolio Management. I presented this in Chapter 6, Integrating the Project Manager, Business Analyst, Business Process Professional, and Information Technology Professional into the Project Landscape. What we should do is constrained by the available skills inventory. We might not have any of those needed skills and need to look to an outside source or we might not have enough of the needed skills and need to make some difficult choices. In either case, there will be a “gap” and the pain of that gap needs to be minimized.

Tactical Project Gap

The tactical project gap is the difference between what we can do and what we will do.

The Effective Use of “Bench Strength”

No matter how well we do managing the gaps there will be professionals who do not have a project assignment for some periods of time. They represent your “bench strength” and they must be deployed to some useful assignments. There are at least three possibilities.

Consulting and Mentoring

They can be assigned to the project support office (PSO) to offer consulting and mentoring support services.

Off-the-Job Training

They can engage in training and development activities in line with their professional development program (PDP).

Tools, Templates, and Process Maintenance

I have a client that places all of these maintenance projects in the backlog bucket of a Scrum-like maintenance project. Anyone on the bench can review the contents of the backlog bucket and choose a maintenance project that they can work on for the time they expect to be on the bench. If they finish, the project is removed from further consideration and the deliverables put in production status. If not, the project returns to the backlog bucket for someone else to complete.

Projects Are Excellent Sources for Training

I have always looked for the training opportunities that every project can provide. This can be a major component of both the on-the-job and off-the-job training programs with little or no cost and minimal incremental risk to the project. Two aspects of such a program are discussed in the following sections.

Shadowing

One of the four adult learning theories is reflective observation. Some people can learn very effectively by just observing experts practice the desired skill and processing the information they gathered from their observations. Once the person has acquired some minimal proficiency the expert will often allow them to assist in carrying out parts of the task but under close supervision. Eventually the person will be able to stand on his/her own and carry out the task.

Learn by Doing

Two more of the four adult learning theories are active experimentation and concrete experience. Active experimentation puts the person under the close supervision of a manager. The person is assigned responsibility for a task for which they are not prepared from a skills standpoint and for which they may have no previous experience. They are given the support and learning opportunities they will need to satisfactorily complete the task. In other words, they are given a challenge and the means to rise to the challenge.

Concrete experience is quite different. The best example I have is learning to swim. “Just throw me in the pool and I'll figure it out on the way down.”

Both active experimentation and concrete experience are valid ways to learn. In practice you should encourage the PM and even the CPM to look for such on-the-project learning opportunities. They will be tasks whose completion by a scheduled time is not critical to the overall project schedule. Learning takes time and using an on-the-project task will consume time that is non-value added for the learning experience to be played out.

Job Opportunity Bulletin Service

This was introduced in Chapter 5: A Professional Development Model. Years ago Texas Instruments had a JOBS to alert all employees of internal open positions. That worked quite well and maximized the benefits from their PDP by listing positions by position family and position title within the family. It placed the burden of initiating career advancement on the shoulders of the employee and they responded well. Consider expanding the scope of JOBS by:

- Including opportunities for observing tasks being performed by recognized experts on actual projects. The expert would be responsible for identifying these opportunities and by listing them on JOBS would be granting permission for observation only.

- Including opportunities for active experimentation or concrete experience on specific tasks within active projects. By posting such opportunities on JOBS they would be agreeing to support a person who needs to practice the skill perhaps for the first time. The successful candidates would become members of the project team for the duration of their assigned task.

HRMS that Can Schedule Resources to Projects

Commercial HRIS and HRMS packages are quite limited in their ability to align supply with demand and engage in the best use of human resources on projects. Understand that this is a very dynamic environment. Most offerings are static. That is, there are staffing requirements of the approved projects and the staff are chosen from those who are qualified for the opening and are not yet fully assigned.

To be fully effective in staffing complex projects the HRMS package must have the following characteristics:

- Accommodates project plans that identify the project name, project priority, project start and end dates, position titles needed, specific skill proficiencies, the start and end date of the assignment, the average number of hours needed per week.

- Accommodates the available professional inventory by person name, position title, skill profile, number of hours per week available by week, current project assignments by hours per week.

- Able to age the CPT members using their PDP and hence forecast the supply side of the professional inventory over time.

- Compares supply and demand over time and hence forecasts the supply gap.

- Allocates professional staff to projects and analyzes the unstaffed projects as compared to the unassigned professional staff.

There are only a handful of commercial HRMS packages that even come close to meeting these resource management needs.

Executive Bookshelf

Here are some references that you may find useful. I have included those that reinforce the material introduced in Part II as well as material that gives you more detail on each of the topics discussed.

Eckstein, Jutta. Agile Software Development in the Large. New York: Dorsett House, 2004.

Wysocki, Robert K. “ Managing a Multiple Team Project” Cutter Consortium, 2006, Vol. 7, No. 4.

Wysocki, Robert K. “ The Key to Managing “Fuzzy” Projects” Cutter Consortium, 2009, Vol. 10, No. 9.

Wysocki, Robert K. “ After a 40-Year Courtship, It's Time for the Business Analyst and the Project Manager to Get Hitched” Cutter Consortium, 2009, Vol. 10, No. 2.

Wysocki, Robert K. Business Analyst/Project Manager: A New Partnership for Managing Complexity and Uncertainty. New York: John Wiley & Sons, 2011.

Wysocki, Robert K. Building Effective Project Teams. New York: John Wiley & Sons, 2002.

Wysocki, Robert K. and James Lewis. World-Class Project Manager: A Professional Development Guide. Reading, MA: Perseus Books, 2001.

Part III

Improving Project Return On Investment (ROI) Using Agile Project Portfolio Management

Projects used to be the focus of some senior management team (SMT) members. Meet client specifications within the constraints of time and cost. Unfortunately that misses the boat and has led to a high rate of project failure. Even when the client specifications were delivered within the time and cost constraints the majority of clients were not satisfied. That is not as strange as it might seem. The problem is that the attention was misdirected. Fortunately those are the bygone days.

The contemporary SMT view of the project should be as an investment in business value much like a stock or bond is a financial investment. That is what I want you to think about when you think about a project or a program. Projects and programs return some incremental business value to the organization for their successful completion and that is the basis on which a project or program is undertaken. Decisions about projects and programs that are underway are made based on the impact on business value. No other criterion really makes any sense. There are of course exceptions for federally mandated and maintenance projects. The objective of the organization is to invest in projects with the goal of returning the maximum business value for the choice of projects in which an investment of time, money, and people has been made. The three major questions that I will answer for you in Part III are:

- What are the tools, templates, and processes that can be used to guide project investment?

- How are these tools, templates, and processes used to deliver maximum business value?

- How can your organization deliver maximum business value from its project investments?

The Project Birth and Death Process (Chapter 7)

We need to establish a foundation on which to discuss the life of a project. That is the purpose of Chapter 7. From its birth through its maturation and to its death a project can transition through as many as nine different states. These are defined in Chapter 7.

Agile Project Portfolio Management Process (Chapter 8)

The world of complex projects is a world of learning, discovery, and change. The world isn't going to stand still just because you are trying to deliver business value from your complex projects. That would be assuming a static world, but you live and work in a dynamic world. If you are to have any chance at making the best business value investment decisions possible, you will need to have an investment process that adapts to learning, discovery, and change. There are several strategies that you can adapt.

In Chapter 8 I'm going to share those that I have found most successful and help you decide which makes sense in your organization and then give you a planning template to adapt and use for your agile portfolio management process implementation project.

An Agile Portfolio Strategy (Chapter 9)

This may be the most important of the chapters in Part III. The portfolio strategy follows from the organization's strategic plan. Alignment of the portfolio contents to that plan is mandatory.

Chapter 7

The Project Birth and Death Process

With over 40 years of project management experience I can't help but conclude that despite the fact that projects are supposed to be finite efforts, there are some projects that will never die. After a while they take on a life of their own even though no one remembers why the project is being done. It has become institutional. With the exception of those projects, all projects follow a cycle of birth, maturation, and death just like any biological process or product life cycle. Up to the time of their birth (a.k.a. approval), projects are in a planning phase when the decision to undertake the project is made. Throughout their maturation phase (a.k.a. execution), projects are subject to change due mostly to random events whose likelihood was hopefully anticipated and planned but whose occurrence cannot be predicted. For all complex projects that maturation process includes the discovery, learning, and integration of functions and features into the solution. At some point in time the solution is deemed complete for the time and cost invested. The end of the project signals its death when the deliverables are produced and the project is completed successfully or acceptable deliverables are not produced and the project fails. Project success is measured by the deliverables having produced acceptable business value.

This is all well and good but the realities are often quite different. Are there active projects in your organization that are active only because their sponsor had the power and leverage to get them approved? If there ever was a valid business reason for the project, it has long since disappeared but the project hasn't. Terminating a project is difficult especially because of the impact on the sponsor and the reputation of the client.

Declaring a project a failure and then terminating it is often not as clear a decision as one might think. Failure is a temporal decision. Take for example the case of the sticky note. The project that produced the glue was declared a failure because the glue did not have the physical properties needed. The project results sat on the shelf for over seven years until an application for the glue was identified—result: the Post-It Note. So one man's failure may be another man's success. If the project was to cure melanoma and instead delivered a successful tanning lotion that totally prevented sunburn, was the project a success or a failure? I mention this to you so that you will be cautious because in the complex project world, failure is very difficult to define.

For the SMT each phase in the project life cycle requires continuous monitoring, adjustment, and stage-gate approval. These are described in the following sections. Figure 7.1 identifies the changing status of a project as it moves through the portfolio management life cycle (PMLC). The PMLC is described in Chapter 8. For now it is sufficient to know that there are eight different stages that a project may be in, during the portfolio life cycle. These are briefly described as they align with each of the three phases in the project birth, maturation, and death processes.

Figure 7.1 The Project Birth and Death Life Cycle

Project Birth Process

The project birth process begins with an idea and ends when the idea becomes an approved and funded project attached to the appropriate portfolio.

Project Proposed

All projects begin with an idea to address an existing problem or take advantage of a new business opportunity. It is the responsibility of the proposer or their staff to provide business validation that the proposed project makes good business sense.

The proposed project is documented with a one-page Project Overview Statement (POS) and submitted to the appropriate portfolio to be evaluated regarding its alignment to the portfolio strategy and its suitability for support. The POS originated at Texas Instruments as part of its new product research and development process. I started using it in 1963 while I was an employee at Texas Instruments and have continuously adapted it to the project proposal process that I also developed. It is invaluable. The POS is a five-part document which is discussed in the following sections.

Problem or Opportunity Statement

Every organization has a collection of known problems and untapped business opportunities. Several attempts to alleviate part of or the entire problem may have already been made but the problem persists. The POS gives proposers a way to relate their idea to a known problem and to offer a full or partial solution. If the problem is serious enough and if the proposed solution is feasible, further action will be taken. In this case, senior managers will request a more detailed solution plan from the requestor.

Untapped business opportunities abound. Technology fuels that. A statement that speaks to exploiting technology in order to improve an existing product or develop an entirely new one will certainly get the attention of the SMT.

Whichever the reason for the problem or opportunity statement, it must be written in the language of the business because it will be read by executives like you. So no techie talk allowed unless everyone who might have a reason for reading the POS speaks techie talk.

Project Goal

The second section of the POS states the goal of the project—what you intend to do to address the problem or opportunity identified in the first section of the POS. The purpose of the goal statement is to get the SMT to value the idea enough to read on. In other words, you should think enough of the idea to conclude that it warrants further attention and consideration. Several POSs might be submitted that propose projects addressing the same issue.

A project has one goal. The goal gives purpose and direction to the project. At a very high level, it defines the final deliverable or outcome of the project in clear terms so that everyone understands what is to be accomplished. The goal statement will be used as a continual point of reference for any questions that arise regarding the project's scope or purpose.

Just like the problem or opportunity statement, the goal statement is short and to the point. The goal statement does not include any information that might commit the project to dates or deliverables that are not practical. Remember that you do not have much detail about the project at this point.

Project Objectives

The third section of the POS describes the project objectives. Think of objective statements as a more detailed version of the goal statement. The purpose of objective statements is to clarify the exact boundaries of the goal statement and define the boundaries or the scope of your project. In fact, the objective statements you write for a specific goal statement are nothing more than a decomposition of the goal statement into a set of necessary and sufficient objective statements. That is, every objective must be accomplished in order to reach the goal, and no objective is superfluous.

Identifying Success Criteria

The fourth section of the POS answers the question, “Why do we want to do this project?” It is the measurable business value that will result from doing this project. It sells the project to the SMT.

Whatever criteria are used, they must answer the question, “What must happen for us and the client to say the project was a success?” The conditions of satisfaction (COS) will contain the beginnings of a statement of success criteria. Phrased another way, success criteria form a statement of doneness. It is also a statement of the business value to be achieved; therefore, it provides a basis for senior management to authorize the project manager (PM) and the client to do detailed planning. It is essential that the criteria be quantifiable and measurable, and, if possible, expressed in terms of business value. Remember that the proposer is trying to sell their idea to the SMT.

No matter how you define success criteria, they all reduce to one of the following three types:

- Increase revenue. As a part of the success criteria, the increase should be measured in hard dollars or as a percentage of a specific revenue number.

- Avoid costs. Again, this criterion can be stated as a hard-dollar amount or a percentage of some specific cost. Be careful here because oftentimes a cost reduction means staff reductions. Staff reductions do not mean the shifting of resources to other places in the organization. Moving staff from one area to another is not a cost reduction.

- Improve service. Here the metric is more difficult to define. It's usually some percentage of improvement in client satisfaction or a reduction in the frequency or type of client complaints.

These criteria are often recognized by the name IRACIS:

IR = Increase Revenue

AC = Avoid Cost

IS = Improve Service

The best choice for success criteria is to state clearly the bottom-line impact of the project. This is expressed in terms such as increased margins, higher net revenues, reduced turnaround time, improved productivity, a reduced cost of manufacturing or sales, and so on. This is the criteria on which the SMT will approve the project for further consideration and funding.

The SMT should look at the project's success criteria and assign business value to the project. In the absence of other criteria, this will be the basis for the decision about whether to commit resources to complete the detailed plan or not.

Assumptions, Risks, and Obstacles

The fifth and final section of the POS identifies any factors that can affect the outcome of the project and that should gain your attention as a member of the SMT. These factors can affect deliverables, the realization of the success criteria, the ability of the project team to complete the project as planned, and any other environmental or organizational conditions that are relevant to the project. The proposer wants to share anything that can go wrong and that the SMT might be able to favorably impact.

The project manager uses the assumptions, risks, and obstacles section to alert the SMT to any factors that may interfere with the project work or compromise the contribution that the project can make to the organization. The SMT may be able to neutralize the impact of these factors. Conversely, the project manager should include in the project plan whatever contingencies can help reduce the probable impact and its effect on project success.

Do not assume that everyone knows what the risks and perils to the project will be. Planning is a process of discovery about the project itself as well as any hidden perils that may cause embarrassment for the team. Document them and discuss them.

Attachments

Even though I strongly recommend a one-page POS, some business processes call for a longer document. As part of their initial approval of the resources to do detailed project planning, the SMT may want some measure of the economic value of the proposed project. They recognize that many of the estimates are little more than an order-of-magnitude guess, but they will nevertheless ask for this information. I have seen the following two types of analyses requested frequently:

- Risk analysis

- Financial analysis

The following sections briefly discuss these analysis types.

Risk Analysis

In my experience, risk analysis is the most frequently used attachment to the POS. In some cases, this analysis is a very cursory treatment. In others, it is a mathematically rigorous exercise. Many business-decision models depend on quantifying risks, the expected loss if the risk materializes, and the probability that the risk will occur. All of these are quantified, and the resulting analysis guides management in its project-approval decisions.

In high-technology industries, risk analysis is becoming the rule rather than the exception. Formal procedures are established as part of the initial definition of a project and continue throughout the life of the project. These analyses typically contain the identification of risk factors, the likelihood of their occurrence, the damage they will cause, and containment actions to reduce their likelihood or their potential damage. The cost of the containment program is compared with the expected loss as a basis for deciding which containment strategies to put in place.

Financial Analysis

Some organizations require a preliminary financial analysis of the project before granting approval to perform the detailed planning. Although such analyses are very rough because not enough information is known about the project at this time, they will offer a tripwire for project-planning approval. In some instances, they also offer criteria for prioritizing all of the POS documents that senior management will be reviewing. At one time, IBM required a cursory financial analysis from the PM as part of the POS submission. Following are brief descriptions of the types of financial analyses you may be asked to provide.

Feasibility Studies

The methodology to conduct a feasibility study is remarkably similar to the problem-solving method (or scientific method, if you prefer). It involves the following seven steps:

1. Clearly define the problem.

2. Describe the boundary of the problem—that is, what is in the problem scope and what is outside the problem scope?

3. Define the features and functions of a good solution.

4. Identify alternative solutions.

5. Rank alternative solutions.

6. State the recommendations along with the rationale for the choice.

7. Provide a rough estimate of the timetable and expected costs.

The PM will be asked to provide the feasibility study when senior management wants to review the thinking that led to the proposed solution. A thoroughly researched solution can help build your credibility as the project manager.

Cost and Benefit Analyses

These analyses are always difficult to do because you need to include intangible benefits in the decision process. As mentioned earlier in the chapter, things such as improved client satisfaction cannot be easily quantified. You could argue that improved client satisfaction reduces client turnover, which in turn increases revenues, but how do you put a number on that? In many cases, senior management will take these inferences into account, but they still want to see hard-dollar comparisons. Opt for the direct and measurable benefits to compare against the cost of doing the project and the cost of operating the new process. If the benefits outweigh the costs over the expected life of the project deliverables, senior management may be willing to support the project.

Breakeven Analysis

This is a timeline that shows the cumulative cost of the project against the cumulative revenue or savings from the project. At each point where the cumulative revenue or savings line crosses the cumulative cost line, the project will recoup its costs. Usually senior management looks for an elapsed time less than some threshold number. If the project meets that deadline date, it may be worthy of support. Targeted breakeven dates are getting shorter because of more frequent changes in the business and its markets.

Return on Investment

The return on investment (ROI) analyzes the total costs as compared with the increased revenue that will accrue over the life of the project deliverables. Here senior management finds a common basis for comparing one project against another. They look for the high ROI projects or the projects that meet at least some minimum ROI.

A project that does not meet the alignment criteria may be either rejected out of hand or returned to the proposing party for revision and resubmission. Projects that are returned for revision generally need minor revision and following the suggested revisions should meet the alignment criteria.

These four financial analyses are common. Their purpose is to help the financial analysts determine the risk versus reward for the proposed project.

As a member of the SMT you have the power of rank at your disposal. So my first caution to you is don't abuse your power by forcing your project idea into the portfolio. Staff below you in the organization has a difficult time saying no or pushing back on your idea. If your idea is valid from an expected business value perspective, sell it on its own merits, not on the power of your office. Clogging the process with frivolous ideas is a waste of time and resources and just adds confusion to a challenging portfolio management process.

Project Evaluated

The evaluation phase consists of determining which portfolio or portfolios the project is most closely aligned with. Three outcomes are possible from this evaluation:

- The project is not aligned and is rejected out of hand.

- The project is not aligned but revision and resubmission recommended.

- The project is aligned.

Alignment is often a quantitative measure. Once the project is determined to be aligned, the proposing parties should begin preparing a detailed plan. The plan will contain information like time, cost, and resource requirements that will help the portfolio manager make a final determination regarding the project support that will be needed from the portfolio.

Alignment is a complex task. The first decision the SMT needs to make is how to define the alignment process. Will you use a quantitative or qualitative metric? I'll defer that discussion to Chapter 9, An Agile Portfolio Strategy. The next decision is alignment with respect to what—a specific portfolio, several portfolios, one or more strategic objectives? That is also discussed in Chapter 9, and a few models are suggested.

Project Prioritized

All proposed projects for the portfolio will be ranked along with other projects proposed for the same portfolio. This is the final stage before the project is selected for the portfolio. If it is high enough in priority, it will be funded and included in the portfolio.

The big question for the SMT is what criterion should be used for developing that prioritized list? Among the quantitative metrics, business value is the most popular choice in the complex project world, although risk and return on investment have also been used.

While you could force one measure on all project proposals that might be too restrictive and force invalid conversions of success measures to a single metric, like bottom line dollars. So allowing any one of the three metrics defined in IRACIS to be used, the problem is reduced to comparing projects across all three measures of business value.

Among the qualitative measures a variety of rules such as MoSCoW are in common use:

- M = Must do

- S = Should do

- C = Could do

- W = Will not do now

Variations of A, B, and C or 1, 2, and 3 are also common. I personally prefer and exclusively use MoSCoW. The major reason is that each category contains a descriptor.

Project Selected

This is a temporary classification and assuming approval of the portfolio, this project will be supported. That support may come in the form of less time, money, and resources than were requested. In such cases a revised project plan and expected business value will be prepared.

It goes without saying that the request for money, time, and staff will always exceed what is available. To think otherwise is pure fantasy. The SMT is responsible for defining the model that drives how these selection decisions will be made. For example, for a given portfolio you could fully fund the first 10 of the 15 projects selected for that portfolio or you could partially fund the first 12. Which decision will you take? Is there a business rule here or will the decision be subjective? And don't forget that complex projects will only succeed in a creative environment. Does that creativity encompass the selection criteria? I would argue for your making room for some speculation but to continue being heavy handed on accountability.

As a portfolio manager there are some traps awaiting you. You can easily force a PM into a no-win situation by maintaining the originally proposed deliverables but in less time, for less money, or with fewer resources. Many PMs want their projects supported and will often agree to compromises that cannot be realistically attained. Be careful that you don't force them into such positions. Once the level of support has been awarded require the PM to finalize the project plan and deliverables in line with the support provided and then negotiate from that position to a realistic closure. Now the project team can be held accountable for the results they agreed to deliver. If you base individual performance reviews on project performance, you will have created a motivating environment.

As the sponsoring executive you are responsible for achieving expected business value. You sold the expected business value of the project to your SMT colleagues and they deferred to your judgment. The project team is responsible for completing the project as defined by your office. The project team is not responsible for the business value. They may contribute to increased business value but the sponsor is responsible for achieving the expected business value.

Project Maturation Process

The project enters the maturation process on the first day it becomes an active project. The successful conduct of a complex project is fraught with all sorts of challenges.

A selected project is active if it has received its funding authorization and is open for work. At this stage, the PM is authorized to proceed with the recruiting and assignment of team members, to prepare the final work schedule, and other activities associated with launching the project.

In a complex project environment the SMT needs to maintain control while being flexible and adaptive at the same time. Here are my suggestions for your consideration.

Understand the deliverable schedule and expect exception reports only. For myself, reports such as:

- Everything is going according to plan.

- There are some minor variances from plan but I have a get well plan in place that will bring the plan in compliance by the next report date. The details are attached for your information.

- There are major variances from plan and I need help implementing a corrective action plan. The details are attached for your action.

- The project is heading for failure and I do not have the authority or knowledge to restore the project to plan. The details are attached for your intervention.

Project Death Process

There are three ways that the project can move through the death process. It can be postponed, canceled, or completed.

Project Postponed

An active project is postponed if its staff resources have been temporarily removed. Such projects must return to the pool of prioritized projects and be selected and its staff resources restored. The resources allocated to a postponed project are returned to the staffing category from which they originated to be reallocated to the next project in the queue of that project category.

Postponed Indefinitely

The problem situation or business opportunity is no longer what it was when the project was first proposed. Unless that situation changes, the project will die a slow death due to neglect.

Paused

A project can be paused for some number of cycles due to a temporary condition and then resumed when the condition is no longer in play. These conditions include:

- Higher priority projects require team resources for a few cycles for completion.

- There is a temporary loss of resources to the portfolio.

Project Canceled

An active project is canceled if it has failed to demonstrate planned progress toward its successful completion. Depending on the stage in which the project was canceled, there may be unspent resources. If so, they are returned to the resource pool from which they originated. Those resources then become available for the next project in the prioritized queue of projects being held pending funding for that portfolio.

Project Completed

A project is completed if it has met all of its objectives and delivered acceptable business value. Even if it hasn't met all of its objectives the decision may be to call the current solution acceptable and hence the project complete. Recall that the complex project environment is one where the final solution is not known at project launch and the solution attained may compromise some of the deliverables and hence delivered business value may be less than planned business value but yet acceptable to the SMT.

Putting It All Together

Every organization needs to define its own version of this birth and death process. Having done that the organization and the SMT can track the number of projects in each category. This is especially important in establishing the contents of each portfolio. Of specific interest will be the project prioritization category and the staffing of selected projects. Prioritization includes new projects, continuing projects, and postponed projects. Defining the rules for prioritization is not as easy as you might think. The three categories of projects are to be prioritized in a single list and they are very different types of projects.

Chapter 8

Agile Project Portfolio Management Process

Complex projects introduce uncertainty and high risk into the organization. A particular idea and its estimated business value may place it at the top of the priority list today but that is no guarantee that it will be there tomorrow. Priority among complex projects is volatile and can render the best decisions meaningless. In the past you had a hard time killing projects even though it didn't seem like they were going to deliver the originally estimated business value. If you suggested that a particular project be terminated or significantly reduced in scope, it would certainly upset the sponsor who campaigned so vigorously for it. You might be hesitant to put yourself in the position of project killer for fear of repercussions later on. If you were the sponsor and are now recommending termination or scope reduction the client might not be too happy about your decision. Then there is the reaction of other senior management team (SMT) members to your recommendation. They might have good reason to continue with the project. There is a way to resolve this seeming dilemma and that is the topic of this chapter.

To succeed in today's complex business environment requires a very different approach than you might be used to. Every project portfolio reflects an investment strategy and should be viewed from that perspective. Every project in the portfolio is an investment with an expected return on investment (ROI) contribution to the portfolio and must be judged from that perspective too. If the expected ROI doesn't seem to be measuring up with other projects vying for inclusion, it is a candidate for replacement by a project with a better prospect unless there is some more compelling reason why not. Every member of the SMT must focus on maximizing the value and return on the portfolios of the enterprise and there are several possible models to assist in that endeavor. The adoption of agile project portfolio management (APPM) gives the SMT an opportunity to periodically review (assumed quarterly in this book) the performance of a project portfolio and make adjustments to improve the expected portfolio performance. In this and the following chapter, I will develop that decision model for you.

At quarterly intervals the performance of projects in the portfolio is reviewed and decisions made as to the projects that will make up the portfolio for the next cycle. A comparative evaluation of active, postponed, and new project proposals is done and the contents of the portfolio for the next quarter determined. So on balance the word agile applies to the portfolio not to the projects in the portfolio. Traditional project management (TPM), agile project management (APM), extreme project management (xPM), and emertxe project management (MPx) projects can all belong to the same portfolio.

There are a number of issues that you must be cognizant of and be able to put processes and tools in place to manage the organization's project investment effectively. That is the intent of this and the next chapter. So let me begin by establishing the portfolio management framework that I recommend you should use. This chapter will put the APPM Model in place and the next chapter will discuss how that model is used to effectively manage your complex project portfolios.

What Is a Project Portfolio?

A simple definition of a project portfolio is that it is a collection of projects that share some common link to one another. The operative phrase in this definition is “share some common link to one another.” That link could take many forms. At the enterprise level, the link might be nothing more than the fact that all the projects belong to the same company. While that will always be true, it is not too likely the kind of link you are looking for. It is too general to be of any practical use. Some more useful and specific common links might be any one of the following:

- The projects may all originate from the same business unit—for example, information technology.

- The projects may all be new product development projects.

- The projects might all be research and development projects.

- The projects might all be infrastructure maintenance projects from the same business unit.

- The projects might all be process improvement projects from the same business unit.

- The projects may all be staffed from the same human resource pool.

- The projects might request financial support from the same budget.

Each portfolio will have an allocation of resources (time, dollars, and staff) to accomplish whatever projects are approved for that portfolio. Larger allocations usually reflect higher importance of the portfolio and stronger alignment to the strategic plan. One thing is almost certain: Whatever resources you have available for the projects aligned to the portfolio the resources will not be enough to meet all requests. Not all projects proposed for the portfolio will be funded and not all projects that are funded will necessarily be funded 100 percent. Hard choices have to be made and this is where an equitable decision model is needed.

Your organization will probably have several portfolios. Based on the strategic plan, resources will be allocated to each portfolio based on its priority in the strategic plan and it is those resources that will be used as a constraint on the projects that can be supported by the specific portfolio.

What Is Agile Project Portfolio Management?

The complex project environment is one characterized by frequent change and high risk. In order for the organization to survive and thrive in this environment, the SMT will need to implement a project support environment that is flexible and supportive of creativity but with an eye on the expected business value of the portfolio and the projects it contains. With that as a given the next issue is how to spend resources in that environment in order to maximize the business value derived.

APPM is a logical consequence of complex project management and the agile movement. Agile projects are projects comprised of iterations and are continuously redirected to take advantage of the learning and discovery about the solution that arises from the work of the previous iterations. They are projects characterized by frequent change. The objective of a single agile project is to find and implement deliverables that maximize business value within time and cost constraints. Extend that same concept to the portfolio. Agile portfolios are those whose contents can change at regular intervals to take advantage of market shifts, competitor actions, as well as the learning and discovery that takes place among its current projects and newly proposed projects. So agile refers to the contents of the portfolio not to the type of projects in the portfolio. The objective of the portfolio is to maintain the contents of the portfolio in order to maximize the business value of the portfolio.

The APPM life cycle consists of the five phases shown by the shaded boxes in Figure 8.1 and discussed in the sections that follow. Note that the eight project birth and death stages are clearly evident in Figure 8.1.

Figure 8.1 APPM Life Cycle

Establish

The first step in portfolio management is deciding the portfolios to be established and the level of resources allocated to each one. That strategy is an investment strategy that aligns with the goals and objectives stated in the strategic plan. (NOTE: Chapter 9: An Agile Portfolio Strategy discusses alternative processes that can be used in place of a strategic planning process.) The definition of the portfolios and the level of resources allocated to each portfolio is the responsibility of the SMT. Once this strategy is in place, there will be a structure in place for categorizing the project proposals into the appropriate portfolio.

Several models can be used for this phase. Two of the more popular ones are discussed in Chapter 9. They are the Strategic Alignment Model and the Project Distribution Matrix. The Strategic Alignment Model assumes that a strategic planning process is in place. The Project Distribution Matrix is not based on a strategic plan but is based on defining categories of projects and the level of resources allocated to each project category. If your organization does not have a strategic planning process, you might start your APPM Life Cycle by using the Project Distribution Matrix. Both models can be used to meet the organization's need for good investment strategies. The strategy is conveyed to the organization by the dollar or resource investment (people, machines, facilities, and so on) the company is willing to make in each of the goals and objectives or project categories defined by each model.

In preparation for accepting proposals for the portfolios, four questions should be answered by the SMT:

- Will projects be partially staffed in order to include more projects in the portfolio, or will projects be staffed only at the level of their request?

- Will project sponsors be asked to reduce project scope in order to reduce their request?

- Will project managers (PMs) be asked to reduce their staffing request in order to have the project plan approved?

- If an investment category has excess resources after project acceptance decisions have been made, can those resources be reallocated to other investment categories without compromising the portfolio strategy, and if so, how will they be reallocated?

If possible, it is good to make these decisions before the situations arise. The rules need to be clear so that all parties are informed ahead of time. Postponing these decisions until the situation manifests itself tends to add subjectivity and political pressures on the decision. Put the decision process up front so that it is clear to the organization before there are any decisions to be made. The message to those who will be proposing projects is to consider alternative levels of support and project scope should there be a need to implement the decision process.

Evaluate

This evaluation is a very simple intake task that places a proposed project into one of several categories as defined in the model being used. The beginning of the project intake process involves determining whether the project is in alignment with the strategy of the portfolio to which it is proposed, and placing it in the appropriate “bucket.” These buckets are defined by the strategy that is used, and each bucket contains a planned dollar or human resource allocation. After all of the projects have been placed in buckets, each bucket is passed to the next phase, where the projects that make up a bucket are prioritized.

There are two ways that this intake process (evaluation and alignment decisions) can be executed:

- The person proposing the project does the evaluation and alignment based on defined criteria.

- A single intake person or office does all of the evaluations and alignments.

The intake process can work well either way but the SMT needs to make that decision up front.

The Person Proposing the Project Does the Evaluation

If the person proposing the project does the evaluation, he or she needs a clear definition of each project category in the portfolio strategy. Some procedures may require the proposer to classify the project, in which case this intake process is nothing more than an administrative function. This places the burden on the proposer and not on the portfolio manager. However, there is the possibility of biasing the evaluation in favor of the proposer. The bias arises when the proposer, having such intimate familiarity with the proposal, evaluates it subjectively, rather than objectively. There is also the strong likelihood that these types of evaluations will not be consistent across all projects.

A Single Intake Person or Office Does All of the Evaluations

Having an intake person (this could also be a committee or office) conduct the evaluations ensures that all proposals are evaluated using a consistent and objective criterion. That criterion can be documented and published as part of establishing the portfolio strategy. The playing field is consistent for all proposers which is not the case with the previous process.

When using a single intake person or office the process is more formal, and the project proposal is screened to specific criteria. This formal evaluation is now a more significant process and may involve the portfolio manager or a portfolio committee. Projects that do not match any support category are returned to the proposer and rejected with no further action specified or requested. If the portfolio manager receives proposals that align with their portfolio from the intake person and does the evaluation, the problem of bias largely disappears. The portfolio manager will act so as to maximize the expected business value from the entire portfolio. In this scenario the proposer must follow a standard procedure for documenting the proposed project so that it can pass from intake person to portfolio manager with minimal problems.

The deliverable from this phase of the process is a simple categorization of projects into support categories.

Prioritize

The first step in every portfolio management model involves prioritizing the projects that have been aligned with each portfolio. Recall that the alignment places the project in a single support category. It is those projects in a support category that must now be prioritized. That responsibility belongs to the portfolio manager or appropriate SMT member. When you are finished, each support category will have a list of prioritized projects. Dozens of approaches could be used to establish that prioritization. Some are nonnumeric; others are numeric. Some are very simple; others can be quite complex and involve multivariate analysis, goal programming, and other complex computer-based algorithms. My approach here is to identify those methods that can easily be implemented and do not require a computer system for support, although sometimes a simple spreadsheet application can reduce the labor intensity of the process. The portfolio manager is responsible for choosing the approach and assigning the priorities accordingly. In Chapter 9, An Agile Portfolio Strategy, I offer a few of the simpler prioritization models for your consideration.

Select

You might think that because you have a prioritized list in each portfolio and you know the resources available for those projects, the selection process would be simple and straightforward, but it isn't. Simply allocating resources to projects in priority order until you run out of resources and cannot support the next project on the list won't work for three reasons:

- There will be unused financial resources.

- There will be unused human resources.

- There may be a better allocation of resources that was never considered because of the one at a time approach that was used.

Selection is a very challenging task for any portfolio manager. The problem stems from the apparent conflict between the results of evaluation, the ranking of projects from most valuable to least valuable, the need to balance the portfolio with respect to one or more variables, and the availability of skilled professionals. These factors are often in conflict with one another. As a further complication, you may have decided that partial staffing of projects makes sense. Partial staffing usually extends the total duration of the project, unless scope has been reduced, and can increase the risk of project postponement or failure.

There are several approaches to picking the project portfolio. I've chosen to focus on the Graham-Englund Selection Model and the Risk versus Business Value Project Distribution Matrix. These are both discussed in Chapter 9.

Manage

In this last phase, you continuously compare the performance of the projects in the portfolio against your plan. Projects can be in one of three statuses: on plan, off plan, or in trouble. You will see how that status is determined and the three actions you can take as a result. Here, the challenge is to find performance measures that can be applied equitably across all the projects. Two come to mind:

- Earned value

- Milestone trend charts

A detailed discussion of these is given later in this section. To bring closure to the final phase, projects can be postponed, canceled, or, believe it or not, completed, and you will see exactly how these endings affect the portfolio going forward.

As mentioned, there are three categories for the status of active projects: on plan, off plan, or in trouble and there are three categories for inactive projects: postponed, canceled, or completed. The following sections take a look at each of these states and how that status might be determined:

- On Plan. Even the best of plans will not result in a project that stays exactly on schedule. A certain amount of variance from the plan is expected and is not indicative of a project in jeopardy. The threshold between on plan and off plan is a subjective call. I offer some guidelines for this variance in the section “SPI and CPI Trend Charts,” later in this chapter.

- Off Plan. Once a project crosses that threshold value, it moves from on plan to off plan. For a project to be off plan is not unexpected, but what is expected is for it to get back on plan. If the project manager cannot show the corrective action that will be taken to get the project back on plan and when that event is likely to occur, there is a problem and the project has now moved to the in trouble category. The project can also move to in trouble if it passes a second threshold value that separates off plan from in trouble.

- In Trouble. Regardless of the way in which a project reaches the in trouble condition, the implications are very serious. To be in trouble means that there is little chance the project can be restored. Serious intervention is required because the problem is out of control and out of the range of the project manager's abilities to correct it. However, just because a project is in trouble doesn't necessarily mean that the project manager is at fault. There may be cases where freak occurrences and random acts of nature have put the project in this category, and the project manager is unable to put a get-well plan in place and is asking for help that goes beyond his or her range of authority. The portfolio manager is considering canceling the project unless there is some compelling reason why that action should not be taken. A new project manager will not necessarily rectify the problem.

Reporting Portfolio Performance

Two well-known reporting tools can be used to compare the projects across a portfolio and assess the general performance of the portfolio as a whole: cost/schedule control (C/SC) and milestone trend charts. The Executive Bookshelf in the Part III Summary provides references if you need more details on either C/SC or milestone trend charts. What I will do is take those two reporting tools and show you how to use them to measure portfolio performance.

Schedule Performance Index and Cost Performance Index

From C/SC I take the schedule performance index (SPI) and cost performance index (CPI):

- Schedule performance index. The SPI is a measure of how close the project is to performing work as it was actually scheduled to be performed. If the project is ahead of schedule, its SPI will be greater than 1; if it is behind schedule, its SPI will be less than 1, which indicates that the work performed was less than the work scheduled.

- Cost performance index. The CPI is a measure of how close the project is to spending on the work performed to date compared to what was planned to be spent. If less was spent than budgeted, the CPI will be greater than 1. If not, and more was spent than was budgeted, then the CPI will be less than 1.

These two indices are intuitive and provide good yardsticks for comparing the projects in a portfolio. Any value less than 1 is undesirable; any value over 1 is good. These indices are displayed graphically as trends compared against the baseline value of 1.

SPI and CPI Trend Charts

I introduced milestone trend charts (MTC) several years ago and I provided a detailed description in Effective Project Management: Traditional, Agile, Extreme, 5th Edition (New York, John Wiley & Sons, 2009). The versatility of the MTC allows me to adapt it to track SPI and CPI trends. Some examples will help. Consider the milestone trend chart for the hypothetical project shown in Figure 8.2. The trend chart plots the SPI and CPI for a single project at weekly reporting intervals. The heavy horizontal line has the value 1. That is the boundary value for each index. Values above 1 indicate an ahead-of-schedule or under-budget situation for that reporting period. Values below 1 indicate a behind-schedule or over-budget situation for that reporting period. Over time these indices tell an interesting story about how the project is progressing or not progressing.

Figure 8.2 Example of Using a Milestone Trend Chart to Track SPI (S) and CPI (C) Trends

For example, Figure 8.2 shows that beginning with the Week 5 report, the schedule for Project ALPHA began to slip. The slight improvement in the budget may be explained by work not being done, and hence the cost of work that was scheduled but not done was not logged to the project. This type of relationship between schedule and cost is not unusual.

Certain patterns signal an out-of-control situation. Some examples of this sort of situation are shown in Figures 8.3 through 8.5 and are described in this section.

Figure 8.3 Four or More Slippages Above or Below 1

Figure 8.4 SPI and CPI Trending in a Negative Direction

Figure 8.5 SPI and CPI Trending in a Positive Direction

Figure 8.3 depicts a project schedule slowly slipping out of control. Each report period shows additional slippage since the last report period. Four such successive occurrences, however minor they may seem, require special corrective action on the part of the project manager. The causes need to be researched and rectified. Much like the situation in Figure 8.2, Figure 8.3 shows the project drifting under budget. That may be a myth because planned work may not have been done resulting in the schedule slippage.

Figure 8.4 is another example of Figure 8.3 but in this case both the SPI and CPI are trending in the negative direction. The fact that the trend is negative is very serious. Not only is the schedule slipping, there are consistent cost overruns at the same time.

Figure 8.5 shows both the SPI and CPI trending in the same direction. The fact that the trend is positive is an ideal situation. The project is ahead of schedule and under budget.

In either case, whether trending to the good or trending to the bad, a good portfolio manager investigates to find out what has happened. There may be some hidden reasons why the performance shown in Figure 8.5 has occurred. You are tempted to congratulate the complex project team (CPT) but wait a minute. Being under budget may be the result of work not done and hence the reason for the favorable schedule. Perhaps it was learned that some of the work was not necessary or a better and more time efficient way was found. You have to investigate and find out the real cause(s).

These same data plots can be used to show how the portfolio is performing with respect to both schedule and cost. Figure 8.6 illustrates the hypothetical data for the BETA Program Portfolio. It consists of five projects that all began at the same time. The solid lines are the SPI values for the five projects over the seven-week reporting period. The heavy dotted line is the portfolio average. Although the portfolio has been behind schedule for the entire seven weeks, it is trending upward and has nearly reached an on-schedule situation. The same type of plot can show budget performance for the portfolio as well.

Figure 8.6 SPI Values for a Hypothetical Portfolio

The preceding MTC reports are easy to produce. Consult your IT consultant for advice and an implementation plan.

Project Status Changes

Once the status of a project has been determined from the MTC analysis, there are three possible actions that might be taken:

- Postponed

- Canceled

- Completed

Obviously, one of the project manager's key responsibilities is the status of the project. While there are many reasons why a project may drift out of plan, it is the responsibility of the project manager to institute corrective measures to restore the project to an on-plan status. The extent to which the project manager meets that responsibility will be obvious from the future status of an off-plan project.

The project manager can also be a cause of an off-plan status. That can happen in a number of ways. In my experience, one of the major contributing factors is the failure of the project manager to have a good system of cross-checking and validating the integrity of the task status being reported by the team. If the project manager does not have a visible process for validating task status, then that is a good indication that scheduling problems are sure to occur.

The second behavioral problem that you see is the failure of the project manager to establish a repeatable and effective communications process. The first place to look for that is in constant questioning from the team members about some aspect of the project that affects their work for which they have little or no knowledge. There should be full disclosure by the project manager to the team. That process begins at planning time and extends through to the closure of the project.

Putting It All Together

This chapter has outlined a project portfolio management life cycle using an agile strategy. At regular intervals (I recommend at least quarterly) the performance of each project in the portfolio is assessed against the planned performance for the just completed cycle. Adjustments to the project contents will be made in order to maximize the expected business value from the next cycle of the portfolio. Adjustments can be of several types:

- Some active projects will be continued for the next cycle.

- Some active projects will have an increase in resources.

- Some active projects will be revised.

- Some active projects will be postponed.

- Some active projects will be canceled.

- Some active projects will be judged complete.

- Some postponed projects will be reactivated in the portfolio.

- Some new projects will be added to the portfolio for the next cycle.

Care must be taken to not change the contents of the portfolio more than common sense would suggest. Too much variation in contents from cycle to cycle can turn out to be counterproductive.

Chapter 9

An Agile Portfolio Strategy

This is a critical chapter for the senior management team (SMT). It is here that you set in motion a series of projects, processes, tools, and templates that reflect the organization and what it hopes to be. The success of your organization rests on how well you are able to build and monitor these project portfolios. All of the topics we have discussed in Parts I and II come together and form the foundation of the decisions we will discuss in this chapter. The extent to which the cadre of complex project managers (CPMs) and complex project team (CPT) members align with the project staffing needs is a major determinant in what you are able to do. If the SMT has done a good job so far, these decisions will be much more effective.

The question before your business unit and the SMT is how will you decide which projects and programs belong in your portfolio and in the organization's portfolio for the next cycle and if you are able to staff them? Subjectivity, politics, and favoritism aside you need a sound business strategy. That is the topic of this chapter.

Adapting the Project Management Life Cycle Models to the Agile Project Portfolio Management Model

The first order of business is to connect the project landscape discussed in Chapter 1, The Project Landscape, and the Project Management Life Cycle (PMLC) Models discussed in Chapter 2, Project Management Life Cycle Models, to the Agile Project Portfolio Management (APPM) Model discussed in Chapter 8, Agile Project Portfolio Management Process. In order to accommodate the APPM process, you will need to define a very high-level PMLC that embraces the projects in all four quadrants of the project landscape. Fortunately I've already laid the foundation so that will be quite easy. Figure 9.1 displays the PMLCs for all five approaches. Whatever form your portfolio management process takes, it will follow some type of cyclical pattern. My recommendation is quarterly and that is the assumption I am making here. Arguments can be put forth for longer as well as shorter cycles. Shorter cycles add to the management overhead and non–value added work by the project teams while longer cycles can delay getting important information for decision making and potentially wasting time, money, and human resources.

Figure 9.1 The Five PMLC Models

Only two minor adjustments are needed to fit these PMLC Models to the APPM Model. Firstly, traditional projects using the linear model must be planned in quarterly increments. Secondly, incremental, iterative, adaptive, and extreme projects will have to be planned so that every project's sequence of cycles must end at the end of a portfolio cycle. Again these are not serious adjustments and should cause no problem with proper planning. With these adjustments in place we can define a robust PMLC Model that fits the APPM Model. Figure 9.2 is that robust PMLC Model that fits the APPM Model.

Figure 9.2 A Robust PMLC Model for the APPM Model

Figure 9.2 shows how the robust PMLC Model integrates into the APPM Model. PMLC iterations continue until the end of a portfolio cycle occurs. At that point a status report for each project in the portfolio is prepared with recommendations about the future of the project. This should be incorporated into the client checkpoint phase.

Problem/Opportunity Prioritization

Within your business unit you have a list of problems that have not been solved and a list of business opportunities that haven't been addressed. These are all well accepted by your staff and do not need to be defended. Your resources (time, money, and staff) are not sufficient to attack all of them at once but you do need an action plan. So the question becomes one of prioritizing them and attacking them in the resulting order of their priority. The models discussed in this chapter can be applied within your business unit as well as at the portfolio and organizational levels.

Strategic Alignment Model

While this model can be used at the business unit level its best use is at the organizational level. The Strategic Alignment Model makes good sense because it attempts to align projects at all levels of the organization with the goals the organization has decided to pursue. In other words, it aligns projects with the things that are important to the organization. Figure 9.3 graphically depicts this model.

Figure 9.3 Strategic Alignment Model

Value/Mission

The value/mission is a very brief statement of why the enterprise exists. This could define an end state that the organization hopes to achieve or simply be a statement of how the organization views the business it is in. Whichever form is used, this statement is unlikely to change, at least not in the foreseeable future.

Goals

To achieve its end state or accomplish its mission, the organization has to engage in certain major efforts. These are likely to be multi-period or multi-year efforts designed to accomplish major results. These goals might define an ideal end state that is never attainable (eliminating world hunger, for example), or they might be achievable over long periods of time (finding a cure for cancer or a preventative program for the common cold, for example). Any of these are good examples of goal statements. The important thing to remember is that they must be each stated in a way that they can be decomposed into one or more objective statements whose attainment results in achievement of a goal statement.

Objectives

There will be many approaches to the realization of each goal. Each approach is called an objective, which might be a one-year effort or span several years. Again, take the example of the preventative for the common cold. Objectives might include investigating possible food additives, modifying the immune system, or finding a drug that establishes immunity to the cold. All three of these objectives can launch a number of tactics.

Objectives form a necessary and sufficient set for accomplishing the goal to which they are attached. Referring to Figure 9.3, if Objectives 2, 3, and 4 are achieved, Goal B is reached. All three of these objectives are necessary and none is superfluous.

Projects

Projects are the short-term efforts, usually less than one year in duration, designed to contribute to one or more objectives. For example, Project #1 aligns with Objectives 1 and 2. There is no assumption that if Project #1 is successful, that Objectives 1 and 2 are achieved. That might be the case but it is not implied. These are the projects that will be proposed by the business units for inclusion in a particular portfolio. There may be several portfolios attached to the strategic plan. A project that relates to only one objective will be less attractive to the portfolio manager than a project that relates to several objectives. Similarly, a project that relates to a lower-priority objective will be less attractive than a project that relates to a higher-priority objective. If Project #1 is successful and Objectives 1 and 2 are met, Project #1 will be very valuable to the organization. You saw how this happened in Chapter 8, Agile Project Portfolio Management Process.

How Are You Going to Allocate Your Resources?

The application of this model is quite straightforward. The SMT must decide what resources will be allocated to each goal and to the objectives that support that goal. With that decision made, the organization accepts project proposals from its various business units regarding what projects they wish to undertake and how those projects relate to the goals and objectives of the organization. Obviously, there won't be much interest in supporting projects that do not further the goals and objectives of the organization.

Alternatively, project proposals can be aligned with goals and objectives, and within the goals or objectives projects can be prioritized and then the process of funding begins. Expected business value might be used as the prioritization criterion.

Alternatives to the Strategic Alignment Model

The Strategic Alignment Model is a robust structure for the organization to use to allocate its resources (time, money, and professional staff) to projects and programs. But what do you do if your organization does not have a well developed strategic planning process to base your resource allocation decisions on? There are alternatives and that is what I am sharing in this section. The more popular approaches are briefly described in the following sections.

Growth Versus Survival Model

This way of categorizing projects is the simplest of all models that I am aware of. Projects are either focused on growth or survival. Growth projects are those that propose to make something better in some way. Obviously, these are discretionary projects. Survival projects are the “must-do” projects. These projects must be done or the enterprise will suffer irreparable damage. In short, survival projects are projects that must be done, and all other projects are growth projects.

If the budget is in a contracting phase, you will probably allocate most of your resources to the survival category. Conversely, if you are in an expansion phase, you will allocate most of your resources to the growth category.

Within each of the growth and survival categories the proposed projects should be prioritized as the basis for funding or staffing them.

Project Investment Model

The Project Investment Categories Model is a close kin of the financial investment portfolio. It identifies categories of investments. These categories define types of projects, just as a financial portfolio defines types of investment instruments. In the case of projects, you define the following categories:

- Infrastructure. Projects that strengthen the hardware and software systems that support the business

- Maintenance. Projects that update existing systems or products

- New products. Projects that propose entirely new products or services

- Research. Projects that investigate new products, services, or systems to support the business

Each type of project will receive some percentage of the resource pool.

This model requires the SMT to establish a distribution across existing and new products and services. The distribution will most likely be directly related to whether the enterprise is in a growth or maintenance posture with respect to its upcoming investment strategy.

Business Value Project Distribution Matrix

This is the model I advise many of my clients to use. I have saved it for last because in a certain sense it is an integrative model. Simple, yet elegant, the Project Distribution Matrix, shown in Figure 9.4, says that there must be a mix of projects in the portfolio. This mix will be dictated by the skills inventory of those who work on the projects, as well as the needs of the organization to attain and sustain market share. It can be used in conjunction with the models shown previously to ensure that a healthy mix is present in the project portfolio. The project distribution matrix defines a rule for classifying projects. The rule is a two-way classification, as shown in Figure 9.4.

New—Enhancement—Maintenance Project Classes

- New. A new project proposes to develop a new application, process, or product.

- Enhancement. An enhancement project proposes to improve an existing process or product.

- Maintenance. A maintenance project proposes to conduct the normal care and feeding of an existing product or service, which could include fixing errors that have been detected or otherwise updating some features that have become obsolete or are part of a process that has been changed.

Strategic—Tactical—Operational Project Types

- Strategic. A strategic project focuses on the strategic elements of the enterprise. Applications that extract basic data from businesses, society, and the economy, and translate that data into new products or services are examples of strategic projects.

- Tactical. Tactical projects review existing processes and procedures and propose ways to make improvements by changing or replacing the product, process, or procedure.

- Operational. Operational projects focus on existing products or services and try to find ways to improve efficiency or reduce costs.

Figure 9.4 Project Distribution Matrix

Even though the data represented in Figure 9.4 is multidimensional, the illustration of it is quite intuitive. Each project is represented by a single icon. The shading of the icon tells you which class the project belongs and the shape of the icon tells you the project type. The location of the icon establishes the risk and incremental business value associated with the project. The size of the icon can be either the total cost of the project or the full-time equivalent (FTE) staffing required to complete the project. There are three new Strategic projects (A, E, and F). There are five Enhancement projects (B, G, H, J, and M). There are five Maintenance projects (C, D, I, K, and L). There are six Strategic projects (A, H, E, F, J, and L). There are three Tactical projects (B, G, and I). There are four Operational projects (K, C, D, and M).

Figure 9.4 provides qualitative input to decisions regarding portfolio contents. If the risk and incremental business value variables can be measured quantitatively, then the decision model could be based on expected incremental business value. Expected incremental business value is the product of the probability of project success and incremental business value. The probability of project success is (1 – risk) and is a number between 0 and 1. That is,

Expected incremental business value can then be the single quantitative metric that you use to prioritize all projects under consideration. Table 9.1 contains the data we will use to create the initial project portfolio.

Table 9.1 Sample Project Data Ranked by Expected Business Value.

By way of example, if the portfolio budget were $50 million you could entertain funding Project L through Project K. Under this strategy Project B, Projects C and D, and Project I would not be funded. Before you decide to not fund a project, it might be smart to determine the loss of business value to confirm your decision. If not funding a project results in a loss of business value that exceeds the incremental business value resulting from funding either Projects G or K, it might be smarter to replace Projects G and K with Projects C and D.

To continue the example, assume you have decided to stay with the decision to fund the first nine projects (Projects L through K). The next question is can you staff these projects? To answer that question I recommend the Graham-Englund Selection Model discussed in the next section. Here is where many organizations drop the ball. According to the table you need at least 82 FTE available staff for that portfolio. Having 82 FTE staff is necessary but may not be sufficient to staff the nine projects. The reason is simple. Sufficiency follows from having the right mix of skills for the projects available at the times they are needed for each project. All you know at this point is that at least 82 FTE staff is needed for the nine projects and to be realistic, you will probably need more.

Prior to releasing the investment plan, the following two questions should be answered by the portfolio manager:

- Will projects be partially funded in order to include more projects in the portfolio, or will projects be funded only at the level of their request?

- If an investment category has excess resources after project funding decisions have been made, can those resources be reallocated to other investment categories without compromising the portfolio strategy, and if so, how will they be reallocated?

If possible, it is good to make these decisions before the situations arise. The rules need to be clear so that all parties are informed ahead of time.

The application of this model is quite straightforward. The enterprise that has defined a project classification rule must now decide what resources will be allocated to each of the nine categories shown in Figure 9.4. With that decision made, the enterprise accepts project proposals from its various departments as to what projects they wish to undertake. A feature of this model is that it can be tied to the resource pool of skilled employees. The required skills across each of these nine categories shown in Figure 9.4 are different. To some extent, that may dictate how much emphasis is placed on each category. The enterprise will want to use its available skills, so the relative priority of each category can help or hinder that effort.

Graham-Englund Selection Model

Once projects have been aligned with their appropriate portfolio and prioritized, the final decision is to select those projects that will be supported. Figure 9.5 supplies the model we will need.

Figure 9.5 Agile Version of the Graham-Englund Selection Model

Adapted From: Robert Graham and Randall Englund, Creating an Environment for Successful Projects, San Francisco, CA: Jossey Bass, 1997

Very few organizations use a complete project selection process for their portfolio. Many are based on dollars available in the portfolio and ignore staffing. Once the projects have been allocated to the Risk versus Business Value Project Distribution Matrix and Table 1 generated, you will have a prioritized list of projects. Then the Graham-Englund Model can be used to determine how many of the projects, starting at the top of the list, can be staffed. Staffing constraints may affect priorities when lower priority projects can be staffed and when higher priority projects may not have the available staffing.

One of the most important resources, at least for information technology projects, is people. Staff resources are composed of professionals of varying skills and experience. As you consider the portfolio of projects, you need to take into account the skills and competencies of the staff to deliver that portfolio. For example, if the portfolio were largely new or enhanced strategic applications, you would draw heavily on your most experienced and skilled professionals. What would you do with those who have lesser skills or experience? That is an important consideration, and the Graham-Englund Selection Model is one model that approaches project selection with that concern in mind. Basically, it works from a prioritized list of selected projects, and staffs them until certain sets of skilled and/or experienced professionals have been fully allocated. In other words, people, not money, become the constraint on the project portfolio.

The Graham-Englund Selection Model can be used in conjunction with other models that categorize and prioritize projects. Once those assignments have been made and the resources available to each category determined, the Graham-Englund Selection Model can be used to actually select the projects to be included in the portfolio.

What Projects Should We Do?

The answer to this question is equivalent to establishing the portfolio strategy. In the case of the Graham-Englund Selection Model, you are probably referring to the information technology (IT) strategy of the organization. The answer can be found in the organization's values, mission, and objectives; it is the general direction in which they should be headed consistent with who they are and what they want to be. It is the role of IT to support those goals and values. IT will do that by crafting a portfolio of projects consistent with those goals and values. Think of answering “What should we do?” as the demand side of the equation. You will use the project class (new, enhancement, maintenance) and the project type (strategic, tactical, and operational) to identify the projects you should undertake. These categories loosely align with the skill sets of the technical staff and will give you a basis for assigning resources to projects. In fact, any categorization that allows a mapping of skills to projects will do the job. I have kept it simple for the sake of the example, but this approach can get very complex. One complexity arises when the FTE schedule commitments of a staff member are plotted against the project requirements and schedule for those skills.

What Projects Can We Do?

The answer to this question is found by comparing project requirements to the organization's resource capacity. Current commitments come into play here, as the organization must look at available capacity, rather than just total capacity.

Dealing with the issue of what your organization can do raises the important issue of having a good human resource staffing model in place—one that considers future growth of the enterprise, current and projected skills inventories, training programs, career development programs, recruiting and hiring policies and plans, turnover, retirements, and so on.

Think of answering “What can we do?” as the supply side of the equation. Table 9.2 lists the projects that can be done with the IT staff resources available. In practice the staff needed in the other three disciplines adds to the complexity of the staffing decisions. Note that the first five projects (L, J, F, E, and A) can be done with the current staff assigned as requested by those five projects.

Table 9.2 Project Staffing Requirements.

Table 9.2 shows a list of the nine prioritized projects from Table 9.1 and the skilled positions needed to staff them. The second column gives the number of professionals in each position that are available for these nine projects. Again, I have kept the data simple for the sake of the example.

What Projects Will We Do?

There are adjustments that can be made to Table 9.2 to allow more projects to be done. The bottleneck is the programmer staff. There are a total of 36 programmers to be assigned across nine projects requiring a total of 44 programmers. The mix of programmer classes needed is the barrier. If some of the senior programmer requirements could be reduced to programmers and some of the programmer requirements reduced to associate programmers, perhaps a sixth project could be staffed. All nine projects should be reviewed with the intention of reducing either the number of staff required or the skill levels required. To do that, scope may have to be reduced for the coming quarter. Combining these planning changes may allow more than the first five projects to be staffed.

Will the Portfolio Be Balanced?

Answering this question is roughly equivalent to the selection phase in the portfolio project life cycle. In the case of resource management, “How will we do it?” is just a big staffing and scheduling problem. By scheduling scarce resources across the prioritized list, you are placing more projects on active status; that is, they will be placed in the portfolio. Detailed project plans are put in place, and the scheduling of scarce resources across the projects is coordinated. Performance against those plans is carefully monitored because the resource schedule has created a dependency between the projects. A critical chain approach could be used here. Consult the book Critical Chain Project Management by Lawrence Leach (Boston, MA: Artech House, 2000).

Continuing with the example, the first five projects are distributed across the Project Distribution Matrix as shown in Figure 9.6.

Figure 9.6 Is the Portfolio Balanced?

This portfolio is very aggressive. All five projects are strategic and three of them are new (A, E, and F). Based on project staffing requirements and availability these are the top five projects based on the current selection criteria but there are adjustments that can be made to reduce the heavy dependence on new strategic projects and create a more balanced portfolio. Project A is the highest cost ($15 million) with a low business value (BV)/Cost ratio (0.13). With some minor adjustments in programmer staff requirements, Project A could be replaced by Projects M and G with higher BV/Cost ratios (0.58 and 0.42 respectively) and at less cost ($2.75 million + $3.00 million instead of $15 million).

How Is the Portfolio Performing?

The schedule performance index (SPI) and cost performance index (CPI) milestone trend chart reports introduced in Chapter 8, Agile Project Portfolio Management Process, is my recommendation for tracking and reporting the performance of a portfolio. The frequency of the report should be determined based on the projects in the portfolio being tracked. The higher the risk profile of the portfolio the more frequent the reports. In the examples I used a weekly frequency but that is probably overkill and a monthly frequency would be more effective. The least frequency I would recommend is quarterly so that at the end of a portfolio cycle you will have a report that will add information for deciding on the next quarter's content for the portfolio.

Adjusting the Contents of the Portfolio

The end of a cycle marks the time when the performance of each project in the portfolio is reviewed against the deliverables planned for the just completed cycle, postponed projects are reconsidered, new project proposals are considered for inclusion in the project portfolio for the next cycle, and active projects may be postponed, canceled, or defined as complete. Obviously this can be a time of great change in the portfolio.

If risk and business value are the variables used to calculate expected business value and that value is used to prioritize projects, then you will need to make some adjustments. For example, the agile projects in the portfolio will now have an additional cycle of performance to measure against expected performance. Based on the performance to date, the risk and business value will need to be reviewed and perhaps changed. If the risk has gone down, the expected business value will go up and the project will move to a higher priority. If the risk has increased, then the expected business value will go down and the project will move to a lower priority position. For some projects in the portfolio both the risk may increase and the business value decrease. This will result in a lower expected business value and hence a lower position in the prioritized list. The risk associated with the postponed projects may also change and hence their position in the prioritized list.

Available Human Resources

If you increase the task variety assigned to an individual, you increase the risk of failure of all the tasks assigned to them. That applies to changing project assignments too. To the extent possible you should try to keep a team intact. If the project is continued to the next cycle, that should not be a problem unless the project has moved further down in the prioritized list. The model may assign some or all of the team members to the higher priority projects leaving less skilled staff for the continuing project. Despite the simplicity of the expected business value approach there will be subjective decisions regarding staff assignments.

Closing Projects in the Agile Portfolio

Best practices include acceptance criteria, agreed upon by the client and the project manager during project planning, that clearly state when the project is considered finished. This acceptance criterion usually takes the form of a checklist of scope items or requirements. When all items on the checklist have been checked off as completed, the project is deemed finished. The work of the project, however, is not yet complete. What remains is what I call a post-implementation audit. Any good text on project management will present the activities and contents of a post-implementation audit and discuss why it is so important that one be done.

Attainment of Explicit Business Value

Each project was proposed based on the incremental business value it would return to the enterprise if it were funded and completed successfully. Was that value achieved? This is a question that may not be answerable until long after the project is completed but it is a question that deserves an answer. This proposed value was the justification for the project and a major factor in placing the project in the portfolio in the first place.

Staffing Issues

There are two staffing issues that the SMT must resolve before implementing their staffing decision model.

Issue #1: How Will New Versus Active Projects Be Prioritized Together?

Active projects will have an updated estimate of expected business value based on past performance while new projects will only have an estimate of expected business value and no past performance to draw upon. If your staffing decision model prioritizes projects based on expected business value, will you be comfortable creating a single prioritized list? Is a bird in the hand (active projects that have proven their business value) worth two in the bush (new projects that have not proven their business value)?

Issue #2: How Will Active CPTs Be Protected?

Active projects have established actual business value while new projects can only offer estimated business value and that should carry some weight in your final project selection. The decision will often be a subjective decision.

Putting It All Together

APPM is a work in process for most organizations. Survival in the complex project world requires an APPM Model be put in place. Treat it as an agile project. Put your best guess forward and implement it. Through practice expect to improve its effectiveness.

Part III

Summary

Organizational Challenges and Mitigation Strategies

The two major challenges regarding APPM are:

- Too frequent change of status of complex projects can result in thrashing where too many stops and starts introduce waste into the project and increase project risk.

- The lack of an effective human resource management system (HRMS) which can lead to ineffective project assignments, wasted human resources, and resulting in a compromised portfolio.

Questions to Ask the Project Manager

Gaining management approval of the POS is a significant event in the life of a project. The approving managers in the SMT should question the project manager, and the answers they get scrutinized very carefully. While the POS does not have a lot of detailed analysis supporting it, it is still valuable to test the thinking of the proposer and the validity of the proposed project. It is not unusual to have the project manager return to the drawing board several times for more analysis and thought as a prerequisite to management approval. As senior managers review the POS you can anticipate the following review questions:

- How important is the problem or opportunity to the enterprise?

- How does the project relate to our CSFs?

- How does the project align with the strategic plan?

- Does the goal statement relate directly to the problem or opportunity?

- Are the objectives clear representations of the goal statement?

- Is there sufficient business value as measured by the success criteria to warrant further expenditures on this project?

- Is the relationship between the project objectives and the success criteria clearly established?

- Are the risks too high and the business value too low?

- Do we have the skilled professionals on staff and available to staff the project?

- Has this client been meaningfully involved in previous projects?

- Can senior management mitigate the identified risks?

The approval of the POS is not a perfunctory or ceremonial approval. By approving the document, professionals and managers are saying that, based on what they understand the project to involve and its business value, it demonstrates good business sense to go to the next level, that is, to commit the resources needed to develop a detailed project plan.

The Pain Curve

If you were able to do a project twice—once with a good plan and once with a poor or no plan—the project with the good plan would finish earlier, including the time spent planning. The project with a good plan has a higher probability of finishing than does the poorly planned project. The quality is better, the cost is less, and the list of benefits to good planning goes on. So why is planning often seen as not being real work? The following graphic expresses my message clearer than mere words could. The data is real data and is adapted from the International Benchmarking Council from over 5,000 projects.

The Pain Curve

“Pay me now or pay me later” applies equally well to the oil change commercial as it does to project planning. When the team and management are anxious for work to begin, it is difficult to focus on developing a solid plan of action before you are pressed into service. At times it would seem that the level of detail in the plan is overkill, but it is not. The project manager must resist the pressure to start project work and instead spend the time up front generating a detailed project plan. It has been demonstrated that a poor planning effort takes its toll later in the project as schedules slip, quality suffers, and expectations are not met.

For the SMT the message in this graphic is that the time spent planning a project has a return on the time investment. The pain curve demonstrates that proper planning is painful but pays off in less pain later in the project. Not to plan is to put the project in harm's way. In fact, that pain usually continues to increase. It would continue to increase indefinitely except that someone usually pulls the plug on the project when the pain reaches unbearable levels.

Gaining Approval to Plan

Project planning is not done until the project has been prioritized and selected for inclusion in a portfolio. The project plan will provide additional cost, schedule, and resource requirements date to inform the final decision. Approval to plan a project is not approval to do the project. Approval to plan is a significant step in the life of a project but a lot remains to be done before approval to do the project is granted. Approval to do the project implies that the project can be staffed. And here is where subjectivity enters the decision.

If the SMT allows projects to be partially funded and/or partially staffed, then rules are needed to define how those partial support decisions will be made. You are only making a decision that impacts the next portfolio cycle.

Complex Project Plan

Complex project plans are only good one cycle at a time. The learning and discovery from the current cycle informs the CPM and the client as to the direction to be taken in the next cycle. The final deliverables and business value from the completed project can only be guessed and there is always a high risk of failure attached to such estimates. As the project establishes a successful history of meeting deliverables planned for completed cycles, there is an added confidence that future cycles will maintain that trend.

Balanced Portfolio

What constitutes a balanced portfolio is a subjective call. In general, there should be a mix of high and low-risk projects. The mix should also use the range of skill levels in the resource pool.

With Respect to Project Types

Figure 9.6, which is repeated in the following graphic, contains a mix of project types that might be seen as unbalanced and not a good use of resources.

An Unbalanced Project Portfolio

It contains three new strategic projects, one strategic maintenance project, and one strategic enhancement project. There are no tactical projects. The two largest strategic projects are also the highest risk projects in the portfolio. This is a high-risk portfolio.

With Respect to Resource Alignment

A portfolio loaded with high-risk complex projects will require the most skilled and experienced CPM and CPT. If for some reason one of these professionals is lost to the project, the only replacements left on the bench will be lesser skilled and lesser experienced professionals. That means project risk, which is already high, will increase and the portfolio becomes riskier as a result.

Questions to Ask the Portfolio Manager

The portfolio manager is responsible for delivering the expected business value from the portfolio. They must assemble and maintain the project content in their portfolio. Even if they have the support of an exemplary HRMS they aren't home yet. All of the projects in the current portfolio got there because they were able to convince the portfolio manager that their expected business value was achievable. Some of these projects did demonstrate their viability from previous portfolio cycle successes. New projects don't have that luxury. The reputation of the CPM and CPT members assigned to the project may lend credibility to the estimated expected business value. Other new projects won't even have that as a validity check on the feasibility of the project and the reasonableness of the estimated business value.

Supply/Demand Human Resource Forecast

The HRMS is the critical component for any organization that expects to excel in the complex project world.

On the supply side is the degree to which the HRMS can put in place professional development plans (PDPs) that will result in a CPM and CPT cadre that will meet project staffing needs. Training, turnover, and recruiting programs all feed these PDPs.

On the demand side are those projects that attain and sustain the organization's market position. These are always speculative and are heavily influenced by a fickle market and technological change.

Graham-Englund Selection Model

Too many organizations build their portfolios thinking they have a steak budget when in fact they have a baloney budget. A specific project may be the best investment the SMT can make but if it can't be staffed, all is for naught. The Graham-Englund Selection Model is a reality check that too many organizations ignore. The senior manager cop-out is to think that the CPMs and CPT members will figure it out. I remember one of my client's senior managers saying “What are they doing on Sundays?” They were already working on Saturdays. While they may be able to do that don't think that it won't have an impact on project failure rates, late projects, dissatisfied clients, and less than expected business value.

On-the-Beach Projects

One of my clients gathers all maintenance projects into a Scrum-like setting. Those CPT members who are idle in a quarter should be working on those projects as though they were in a Scrum backlog bucket. They simply look at the contents and choose a maintenance project that they have the requisite skill to work on even if they cannot finish it in the available time.

Executive Bookshelf

Here are some references that you may find useful. I have included those that reinforce the material introduced in Part III as well as material that gives you more detail on each of the topics discussed.

Crawford, J. Kent. Seven Steps to Strategy Execution: Integrating Portfolios, Programs, Projects, and People for Organizational Performance. Havertown, PA: Center for Business Practices, 2008.

Dye, Lowell D., and James S. Pennypacker, editors. Project Portfolio Management: Selecting and Prioritizing Projects for Competitive Advantage. West Chester, PA: Center for Business Practices, 1999.

Eckstein, Jutta. Agile Software Development in the Large. New York: Dorsett House, 2004.

Graham, Robert J., and Randall L. Englund. Creating an Environment for Successful Projects. San Francisco: Jossey-Bass, 1997.

Martin, Roger. The Design of Business: Why Design Thinking is the Next Competitive Advantage. Boston: Harvard Business Press, 2009.

Moore, Simon. Strategic Project Portfolio Management: Enabling A Productive Organization. Hoboken, NJ: John Wiley & Sons, 2010.

Pinto, Jeffrey K. and Pekka J. Rouhiainen. Building Customer-Based Project Organizations. New York: John Wiley & Sons, Inc., 2001.

Turner, J. Rodney. The Handbook of Project-Based Management: Leading Strategic Change in Organizations. New York: McGraw-Hill, 2008.

Weiss, Joseph and Robert K. Wysocki. 5-Phase Project Management: A Practical Planning and Implementation Guide, Reading, MA: Perseus Books, 1992.

Wysocki, Robert K. “ How to Write a Bulletproof Project Overview Statement” Cutter Consortium, 2009, Vol. 10, No. 12.

Wysocki, Robert K. “ An Agile Approach to Resource Constrained Project Portfolio Management” Cutter Consortium, 2009, Vol. 10, No. 5.

Wysocki, Robert K. “ Managing Complexity and Uncertainty in Software Projects” Cutter Consortium, 2006, Vol. 6, No. 7.

Part IV

Establishing and Maturing an Enterprise Project Support Office

Project offices and program offices have been around for a very long time but variations of the modern Project Management Office (PMO) have only been popular since 1960. They have served their purpose with mixed blessings. Their responsibility for return on investment (ROI) is a continuing topic of debate. My position is that the project, program, and portfolio sponsors are responsible and that is the position I have taken in Part II and reinforce that in Part IV.

In Chapter 3 and Part III I defined my position regarding the generalist and the specialist and the fact that to be a complex project manager the professional must be multi-disciplined. The project management (PM), business analysis (BA), business processes (BP), and information technology (IT) disciplines define the position profile of a project manager. Continuing with that model in Part IV the project support office (PSO) must also support those disciplines.

It is my opinion that we are positioned for a disruptive innovation of the PMO. Early stages of that innovation are what I call the PSO and that is what I present in Chapters 10 and 11. Also as part of that innovation I am seeing a growing involvement of the generalist as discussed in Chapter 3. In a companion book The Business Analyst/Project Manager: A New Partnership for Managing Complexity and Uncertainty (Hoboken, NJ: John Wiley & Sons, 2011) I develop that idea further.

Finally, in Chapter 12, I carry further evolution of the PSO to its logical conclusion. My major contribution is the changing discipline scope of the PSO. Today its scope is project management and that works fine for the project manager. Independent of these PSOs we are experiencing the emergence of centers of excellence (COE) and communities of practice (COP) in the business analysis discipline. It is my opinion that these should be merged with the PSO but I have no evidence that such a merger is taking place in any organization. In the short term I believe that the scope of the PSO will expand to support the project not just the project manager and that expanded scope will incorporate the business analysis discipline. The trend of integrating other disciplines into the PSO will continue and eventually include business processes, and information technology. Tomorrow's scope will be supported by the expanded position family discussed in Chapter 3. That portends of a significant evolution for existing PSOs and a view of the PSO of tomorrow.

Organizing and Defining your Project Support Office (Chapter 10)

Chapter 10 sets the foundation for Part IV by establishing the basics of the PSO. Three variations of the PSO are defined and the support services that are commonly provided are defined. There are specific signs that a PSO is needed and these are also defined. And so you decide that a PSO is needed. Its mission statement, objectives, and functions are first specified and then a discussion of organization and placement discussed. The Hub & Spoke structure is shown to be the best foundation for expanding and growing an effective PSO for the future demands of complex project management and support.

Growing and Maturing your Project Support Office (Chapter 11)

Chapter 11 describes how to establlish your PSO for effectively supporting complex projects. That enables your organization for the future evolution of your PSO. That evolution will be a necessary characteristic of the effective PSO of the short-term future.

The Future of the Project Support Office (Chapter 12)

The distant future may include the PSO as a utility. I take that topic up in Chapter 12.

Chapter 10

Organizing and Defining Your Project Support Office

Note that I use the term “support” instead of “management.” The term “management” sends a heavy-handed message of compliance and that is not what promotes a successful operation nor is it the message I want you to send. The term “support” sends an “I'm here to help you” message and sends a reactive message rather than a proactive message of support provision. My use of support has major implications to the mission, vision, and objectives of the project support office (PSO). The discussion in these early sections is robust and will apply regardless of the impact of those implications and the discipline scope of the PSO.

Definition of a Project Support Office

Definition: Project Support Office

A PSO is a temporary or permanent organizational unit that provides a portfolio of services to support project teams that are responsible for a defined group of projects.

There are three types of PSOs:

- Directive. In this type the project managers are organizationally attached to the PSO and are assigned to projects from the PSO. This structure is generally reserved for enterprise-wide projects.

- Controlling. In this type of PSO the tools, templates, and processes are supplied by the PSO and all project managers, regardless of their home department, are required to use them. A heavy-handed compliance function is administered by the PSO.

- Supportive. This type of PSO (frequently named PSO and the name I will use here) provides on an as-requested basis any type of help and expertise the project manager or team members might need.

One thing that is common to all three of the above PSOs is the responsibility for standards development, maintenance, and compliance. So with the name PSO, the name we will go forward with, most implementations of the PSO are generally some hybrid of the above. The senior management team (SMT) is responsible for deciding on the type of PSO most appropriate for their organization and then implementing it. I strongly recommend a hybrid variation with supportive, control, and directive components. So with that as the foundation we can get more specific.

Temporary or Permanent

Among the various forms of PSOs some are temporary and some are permanent structures. That determination is made based on the types of projects that they support.

Those that are temporary are often called program offices and they support the administrative needs of a group of projects that are related by goal, purpose, or budget. When those projects are completed, the program office that supported them is disbanded. Many government projects have program offices attached to them. They are generally long-term arrangements and involve millions or billions of dollars of funding. Our Challenger Space Program is a familiar example. As defined, the program office is out of scope for this book.

Those that are permanent provide a range of support services for projects that are grouped by organizational unit rather than goal or purpose. They might have an enterprise-wide scope or a functional scope, such as IT, research and development, or new product development. The permanent PSOs are the focus of this book.

Portfolio of Services

A recent survey of 502 PMOs (Brian Hobbs and Monique Aubry, The Project Management Office (PMO): A Quest for Understanding Newtown Square, PA: Project Management Institute, 2010) identified 27 functions that the surveyed PMOs provide. I've taken those 27 functions and grouped them as follows:

- Project Support

- Report project status to upper management

- Provide advice to upper management

- Participate in strategic planning

- Identify, select, and prioritize new projects

- Manage archives of project documentation

- Manage one or more portfolios

- Manage one or more programs

- Provide interface between management and customer

- Allocate resources between projects

- Implement and manage database of lessons learned

- Implement and manage risk database

- Provide networking and environmental scanning

- Consulting and Mentoring

- Coordinate between projects

- Methods and Standards

- Develop and implement a standard methodology

- Monitor and control project performance

- Implement and operate a project information system

- Develop and maintain a project scoreboard

- Conduct project audits

- Conduct post-project reviews

- Monitor and control performance of PMO

- Software Tools

- Provide a set of tools without an effort to standardize

- Training

- Develop competency of personnel, including training

- Project Managers

- Provide mentoring for project managers

- Promote project management within organization

- Execute specialized tasks for project managers

- Recruit, select, evaluate, and determine salaries for project managers

- Manage benefits

These six groups define what I believe should be the services offered by the PSO of the future. The full-service PSO offers services aligned with the six major functions listed previously. These are the services that the current and future PSOs should be supporting. They are briefly described in the following sections. Not every PSO will provide all six functions. Deciding on the services to be offered by a PSO is the responsibility of the SMT. I would advise that all six functions be included in your PSO organization because they are critical to fully supporting the complex project environment.

Project Support

Project support is an administrative service that can extend over the entire project management life cycle (PMLC). The project support services are intended to remove as much non–value added work from the project team as it can and place it in the PSO. Off-loading the non–value added work to the PSO allows the complex project manager (CPM) and complex project team (CPT) to focus all of their energies on the complex demands of their project. Obviously we would rather have the project team focused on the work of the project and not be burdened by so-called “administrivia.” More importantly, the PSO staff will be much more knowledgeable of how to provide these services more effectively and efficiently than the CPT because they will be very familiar with them and with the use of the tools and systems that support them. It is obvious that the cost of providing the service is much lower if done by the PSO than if done by the project team. Further to the point, the PSO staff that will actually provide the service need minimal office skills whereas the project team members' skill set is not likely to include the skills appropriate to provide these services. The service will therefore be provided by a less costly employee, who is appropriately positioned and prepared for the assignment.

The project support services that a PSO might offer include:

- Schedule updating and reporting

- Timesheet recording and maintenance

- Preparation and distribution of agenda materials

- Report production and distribution

- Report archiving

- Report consolidation and distribution

- Project notebook maintenance

So how much staff support should the SMT allocate to the PSO? I get this question all the time. To calculate the number of full-time equivalent (FTE) positions you will need in the PSO add up all of the labor hours for all of the projects under PSO protection and take 7 to 15% of those hours. That will give you a rough idea of the number of administrative hours needed to support all of the projects. 7% is the smallest percentage I have seen among my clients. As the project increases in size that percentage has risen to as much as 15%. From that you can calculate the number of staff needed to provide administrative support to all projects. For example, suppose the total number of labor hours for the projects in your portfolio adds to 35,000 for the next 13-week portfolio cycle. Most projects have about the same number of labor hours and complexity. I'll use 10% of the 35,000 labor hours. So the portfolio will need about 3,500 administrative hours of support over the next 13 weeks. 3,500 hours/13 weeks = 269 hours/week—roughly 7.7 FTE positions. Don't make the mistake of ignoring that and assuming that the project team can absorb the work. They could, but they shouldn't—ever. Unfortunately they do in most organizations. That practice has to stop and it is the SMT that can put a stop to that practice.

Consulting and Mentoring

Professional project consultants and trainers are available in the PSO to support the consulting and mentoring needs of the project teams. In this capacity they are a safe harbor for the project manager and team members as well. They stand ready to help with any specialized assistance including:

- Proposal development support

- Facilitating project planning sessions

- Risk assessment

- Project interventions

- Confidential mentoring and coaching of project managers

- Mentoring senior management

- Post-implementation audits

The PSO professional consultants are the senior-most project managers in the organization. Their experiences are broad and deep. Like the priest in the confessional, they have heard and seen all situations. There will not be any surprises. They will be able to help the project manager even in the most complex of circumstances. One practice that we have seen in a few PSOs is to rotate these consultants through the PSO. Think of it as a sabbatical from the front lines. One of the benefits of this rotation is that it continually infuses new ideas and best practices into the PSO as well as from the PSO back out into the field.

The PSO is uniquely positioned to gather and archive best practices from around the company. That makes them particularly valuable as a resource to project teams. Those resources are made available to teams through the PSO professional consultants.

One service that I believe is particularly valuable is the facilitation of project planning sessions. The PSO consultant is the ideal person to conduct a project planning session. That relieves the project manager from the facilitation responsibility and allows them to concentrate on the project plan itself. The PSO consultant can concentrate on running a smooth planning session. They will have better planning facilitation skills than the project manager by virtue of the fact that they have conducted far more planning sessions. It is a win-win situation.

One other practice that I have seen is that the PSO consultant is not actually attached to the PSO. They are out in the field running projects but have particular areas of expertise that they are willing to make available to others as needed. The PSO simply becomes the clearinghouse for such services. With this set up, confidentiality is critical. Project managers are not likely to bare their soul to other project managers, if they will be the topic of conversation in the lunch room the next day.

Methods and Standards

This includes providing tools, templates, and processes across the entire PMLC. This is a service that every PSO must provide. The ROI from a PSO will not happen in the absence of a standard methodology and a means of monitoring and enforcing it. The services can include:

- Establish, monitor, and enforce standards

- Requirements gathering and requirements breakdown structure (RBS)

- Project selection for the portfolio

- Work breakdown structure (WBS) construction

- Program evaluation and review technique/critical path method (PERT/CPM) network development

- Maintenance of tools, templates, and process library

- Evaluation of proposed process changes

- Bid preparation

- Vendor solicitation, vetting, and selection

- Scope change management process

- Risk assessment

- Documentation

- Status reporting

Software Tools

Every PSO should be looking for productivity improvements. As teams become dispersed, it is essential that they remain productive. In this technology crazed business environment we can't let time and distance erect barriers to performance. The PSO is the only organizational unit that can provide the support needed in the ever changing set of tools available on the market. The software tools services include the following:

- Software evaluation

- Software selection

- Vendor vetting

- Request for proposal (RFP) preparation and management

- Vendor negotiations

- Software training

- Software management and maintenance

Training

Training curriculum development and training delivery may be assigned to the PSO depending on whether the organization has a centralized training department and whether it has the expertise needed to develop and deliver the needed programs. My recommendation is to have training management as part of the PSO. Training in project management has probably been around longer than any service an organization is likely to have. Senior managers incorrectly assumed that the solution to their high rate of project failure lay in giving everyone some training in project management. They were looking for that silver bullet and there simply isn't one to be found. What has happened in many organizations is that several different project management training courses have been taken by the professional staff. There is no central approach that they followed as a result of their training. In a sense everyone was still doing their own thing. Some followed the approach they had been taught, others did what they had always done, and yet others taught themselves. Under the management of the PSO all of that will change.

There is a school of thought that says if you teach the concepts and principles effectively, project managers will be able to adapt them to whatever situation they encounter. That sounds good but it usually doesn't work. I have found that most project managers don't want to think they want to be told. “Just tell me what I am supposed to do. I'm not interested in the concepts and theory.” That is truly unfortunate but that's reality and you can't change it very easily. With that in mind, the PSO, in collaboration with their organization's training department, must jointly assume the responsibility of designing and implementing a curriculum that is aligned with the organization's project management methodology. Furthermore, the PSO must assume whatever responsibility the training department is unwilling or unable to assume. Whatever the case, the job must be done. The training services should include the following:

- Project management basics

- Advanced project management

- Project Management Professional (PMP) Exam preparation

- Specialized topics

- Support the training department

- Developing courses and course content

- Delivering courses

- PM training vendor selection

Project Managers

The Hobbs and Aubry survey does not indicate much involvement in the professional development or assignment of project managers to projects. 22% of the PMOs surveyed have some project managers assigned to their PMO and those would be assigned to projects based out of the PMO. Although the survey did not deal with the specifics of projects assigned to the PMO, my assumption is that these are enterprise-wide projects. A variety of human resource functions (recruiting, career and professional development support, and project assignments) will be provided by the PSOs of the future.

The following list is quite comprehensive. It encompasses assessment, development, and deployment services.

- Human resource development

- Identification/assessment of skills

- Selection of project managers

- Selection of team members

- Assessment of the alignment between the project and the project team

- Professional development

- Career guidance and development

This function is delivered in two ways. In some cases project managers will be assigned to the PSO. They receive their project assignments from the PSO. The more common arrangement is for the project managers to be assigned to a business or functional unit. Even in this case the PSO can still make project assignments and deliver the human resource services listed under this function.

Defined Group of Projects

We have already identified one group—those projects that are linked through their goals and purposes. In other words, collectively they represent a major initiative to accomplish some overall common purpose. A good example is our space program. We can think of a single mission as a collection of projects all aimed at accomplishing some part of the mission. Together they represent a single effort. As we stated previously, these projects form a program and are administered under a program office. When the goal of the projects that are part of the program is accomplished, the program office is disbanded.

The other groups of projects that we can identify are those that are organized under a single organizational unit, like IT. Their PSO will be a permanent structure that will support all IT projects now and into the future.

Another group that deserves mention is made up of those projects that are funded out of the same budget. They may have no other relationship with one another other than they share a finite pool of money. These projects will often be linked through a PSO. Such a PSO will be primarily interested in assuring the proper expenditure of the dollars in the budget that funds all of these projects. These PSOs will generally have a project portfolio management process in place to manage the budgets for their projects.

Spotting Symptoms that You Need a Project Support Office

Let me begin by saying that any organization that expects to sustain its business in the face of project complexity and uncertainty must implement a PSO. Apart from that, there are at least four reasons why an organization would choose to implement a PSO:

- As the organization grows in the number and complexity of the projects in its portfolio, it must adopt formal procedures for managing the volume. To do this, the organization establishes the procedures that are followed for initiating, proposing, and approving projects.

- With the increased volume comes a need for more qualified project managers. Those who would like to become project managers will need to be identified and trained. Those who already are project managers will need additional training to deal effectively with the increased complexity. The PSO is often the depository of the organization's skill inventory of current and developing project managers; because it is aware of the types and complexity of current and forthcoming projects, it is best prepared to identify the training needs of project managers and their teams.

- The lack of standards and policies will lead to increased inefficiencies and a compromise on productivity. The increasing failure rate of projects is testimony to that need. Through the establishment and enforcement of standards and practices the PSO can have a positive impact on efficiency and productivity.

- The increased complexity and number of projects places a greater demand on resources. It is no secret that the scarcity of information technology professionals has become a barrier to project success. By paying attention to the demand for skilled project teams and the inventory of skilled team members the PSO can maintain the proper balance through training.

The following conditions provide you with clues that you might need a PSO:

- Project failure rates are too high. This symptom is all too familiar. Reports show project failure rates of 65 to 70 percent and higher, regardless of how failure is defined. That is simply unacceptable. Many of the reasons for these high numbers are probably found in the list of the top ten reasons for project failure from the Standish Group Chaos 2007 report. Reasons that relate to the project management approach that was used—namely, user involvement, clear business objectives, minimized scope, standard infrastructure, and formal methodology—can be addressed by choosing the correct approach (traditional project management [TPM], agile project management [APF], extreme project management [xPM], or emertxe project management [MPx]). It is my contention that by choosing the appropriate approach, the organization can make a serious impact on failure rates.

- Training is not producing results. I am not aware of any systematic study of the root causes of training ineffectiveness. Possible causes are inappropriate materials, inappropriate delivery, no follow-through on behavioral changes after training, or no testing of skill acquisition. Training needs to be taken seriously by those who attend the training. Attendees must be held accountable for applying what they have learned, and there must be ways to measure that application. I am amazed at how many training professionals and curriculum designers are not familiar with Kirkpatrick's model. The interested reader can consult Donald L. Kirkpatrick's Evaluating Training Programs, 2nd Edition (Berrett-Koehler, 1998). In my experience, project reviews that are held at various milestones in the life of the project are excellent points at which to validate the application of training. If clear evidence isn't shown that training has been applied, some corrective action is certainly called for.

- HR project staff planning isn't effective. Organizations need to do a better job of defining the inventory of project staff skills and the demand for those skills by projects. A concerted effort is needed to match the supply to the demand and to make better staffing assignments to projects. The PSO is the best place for this responsibility to be carried out. Without question, the Graham-Englund Selection Model should be used (see Chapter 9).

- Best practices are not leveraged. The PSO is the best place to collect and distribute best practices. Project status meetings and project reviews are the places to identify best practices. The PSO, through some form of bulletin board service or direct distribution to the project managers, is the best place to distribute that information. In the absence of that service, the collection and distribution of best practices isn't going to happen. The SMT needs to be openly involved and supportive of the use of best practices.

- There is little or no control over the project portfolio. Many SMT members don't know the number of projects that are active, nor do they fully understand the resource availability. Unknowingly they overcommit. If you haven't made any effort to find out about or be selective of those projects that are active, you will have to change your behavior, if you expect to get control of the project portfolios in the organization. The PSO is the clear choice for stewardship of that portfolio and your active involvement in those portfolios is a critical success factor. At the least, the PSO can be the unit that assembles project performance data and distributes it to the SMT for their review and action.

- No consistency in project reporting. Without a centralized unit responsible for the reporting process, consistent and useful reporting isn't going to happen. Again, the PSO is the clear choice to establish the reporting structure and assist in its use.

- There are too many resource scheduling conflicts. Most organizations operate with some form of matrix structure. Project resources are assigned from their functional unit at the discretion of that unit's manager. In such situations, resource conflicts are unavoidable. The individuals who are assigned to projects are torn between doing work for their functional unit and doing work for the project to which they have been assigned. If you're a seasoned project manager, most likely none of this is news to you. One solution to resource scheduling conflicts is to use the PSO as the filter through which project staffing requests and staffing decisions are made. The major benefit of this approach is that it takes the project manager off the hot seat and puts the responsibility in the PSO, where it can be more equitably discharged.

- There is a gap between process and practice. This is a major problem area for many organizations. They may have a well-documented process in place, but unless they have an oversight-and-compliance process in place as well, they are at the mercy of the project manager to use or not use the process. The PSO is the only unit that can close this gap. The PSO puts the process in place with the design and implementation help of those who will be held accountable for its use. The PSO, through project performance reviews, can determine the extent of the gap and put remedial steps in place to close it.

If one or two of these eight conditions prevail, you may be able to rectify the situation with a process improvement program but if several (say four or five) are in evidence, then establishing a PSO is the correct business decision.

Mission

If you have decided that a PSO will be established, the first order of business is to establish the mission of your PSO. Some examples of possible mission statements include:

- (Directive) Provide overall management and administrative support to the ALPHA Program.

- (Controlling) Establish and monitor compliance to the project management methodology

- (Supportive) Provide a comprehensive portfolio of support services to all project managers on an as-requested basis.

The first statement is the typical mission statement of a program office, which in this example is a temporary office. It provides administrative support for a program, which comprises a group of projects related to something called the ALPHA Program. Once the ALPHA Program is complete the PSO will be disbanded. The second statement is a very limited mission statement. Actually such a statement doesn't find much favor with project managers. It sounds too much like a Gestapo-type organization. Even though this mission statement is not popular it is necessary in any PSO that is worth the price. The third statement is more to my liking. The priority is clearly on support and not enforcement of standards. It does not have an obvious standards compliance responsibility—at least not in the mission statement—and so it should be very appealing to most project managers. It seems to be more supportive of the things a project manager is looking for in a PSO. This is my pick and it fits comfortably with a name like project support office. A PSO will still have some of those Gestapo-like functions to perform but they are surrounded by a comprehensive list of support services with the emphasis on support. It seems to define a package that can be sold to project managers and to senior managers as well.

Objectives

Let us assume that we have adopted the third mission statement as the mission statement of our PSO. Since the PSO is a business unit, its objectives should be framed in business terms. The following are some examples:

- Help project teams deliver value

- Increase the success rate of projects to 75%

- Reach Level 4 in Project Management Maturity (PMM)

The first statement is a bit vague in that it passes the business reason for the PSO to the project teams. That is as it should be. Since the PSO does not do the project it doesn't make sense for them to be responsible for delivering ROI on the projects. That responsibility belongs to the customer of the project team. The PSO is responsible for the quality of the process, tools, and templates; in addition suitable metrics should be in place to measure that. Easy to say but so very hard to do. This is where the complication of measuring ROI from the PSO comes about. The PSO really can only impact ROI indirectly through the project teams that it helps and through the provision of best practices and other exemplary support services. They have to define value and make it happen. If you want to hold the feet of the PSO to the fire, then either the second or third statement will do the job. They are very specific and can be easily measured. PMM will be discussed later in Chapter 11.

Functions

The six functional areas listed earlier in this chapter are fairly comprehensive of those that a PSO might offer. A word of caution is in order however. It would be a mistake to implement all of the listed functions at once even if that is the ultimate goal of your PSO. Introducing a PSO into the organization is asking management to absorb quite a bit. You will have a much better chance of success if the functions are prioritized and introduced piecemeal. A root cause analysis might help identify which functions can generate the most value. Start with those and work your way through the list. We will have more to say about this later where we discuss the challenges of implementing a PSO.

Organization and Placement of a Project Support Office

There are several approaches that organizations have taken in the structure and placement of the PSO. In this section, I will comment on the structures I have seen in practice.

Virtual/Real

A virtual PSO performs all of the functions of any other PSO except that their staff is allocated to the business units. These PSOs are mostly available when their services are needed. They do not perform any routine functions. Other than a director and perhaps an administrative support person, the virtual PSO does not have any other budgeted staff. Professional staff from the business units that are involved with projects volunteer their services to the PSO. This is not a permanent volunteer position. These individuals, who are generally project managers themselves, agree to serve for some period of time and are then replaced. In many cases they volunteer to provide only a specified type of service or services.

The real PSO, on the other hand, does have a budgeted staff of professionals, which probably includes several project managers. They will perform several routine functions such as project reviews and software evaluations. The project reviews are a good way to monitor the adoption of the methodology and uncover best practices as well. Their strength will probably be that they offer a healthy dose of project support services to project teams.

Proactive/Reactive

The proactive PSO aligns very closely with the real PSO and the reactive PSO aligns closely with the virtual PSO. The real PSO can be proactive because they have the staff to take leadership roles in a variety of projects to improve project management practices. The reactive PSO, on the other hand, does not have the staff and does well to just respond to requests for help.

Temporary/Permanent

What we have called program offices are the only temporary form of PSO that we know of. They are often established to serve the administrative and managerial needs of large projects. Those projects are decomposed into smaller sub-projects and each is assigned a project manager. They are accountable to the program manager through the program office. All other examples of PSOs are permanent and service an ever changing list of projects.

Program/Projects

We have already defined programs as collections of related projects. They are managed under a program manager with or without the benefit of a program office.

Enterprise/Functional

PSOs can be attached at the enterprise level or at the functional level. At the enterprise level they must provide services to all disciplines. They are generally well funded and well staffed. They have visibility at the project portfolio level and may be involved in strategic roles. At the functional level they are often accountable to the enterprise PSO, if there is one, and generally service the needs of a single discipline.

Hub and Spoke

In very large organizations the PSO may be organized in a hierarchical form. At the hub, or central office if you will, is a high-level PSO that sets policy and standards for the enterprise. This is what we will call an enterprise PSO. The enterprise PSO reports to a C-level executive. At the business unit or division level there are division PSOs that service a functional area (like IT) or a business unit, or a customer group. The division PSOs takes their policy and standards direction from the enterprise PSO—the hub. The hub is typically staffed by high-level project executives whose focus is strategic. At the end of a spoke is a division PSO which has operational responsibilities for the unit they represent. Within the policies and standards set by the hub each division PSO is free to set their own policies and standards as long as they are compatible with the hub.

Figure 10.1 is a graphic illustration of the hub and spoke organizational structure.

Figure 10.1 Hub and Spoke PSO

Steps to Establishing a Project Support Office

In order to plan for a PSO there are four critical questions that must be answered. One of them deals with defining a desired future for our organization's PSO—the goal, so to speak. But to reach that goal we have to assess where we currently are with respect to that goal. The answer to that question identifies a gap between the current state and the future state. That gap is removed through the implementation plan for our PSO. And so the four questions, arranged chronologically are:

- Where are you?

- Where are you going?

- How will you get there?

- How well did you do?

Before we attempt to answer those questions we need a foundation for answering them. The Software Engineering Institute (SEI) provides just the foundation we need. Their five-level model described in Chapter 11 gives us a foundation on which we can plan for the further growth and maturation of our PSO.

Putting It All Together

Establishing a PSO can take 6 to 24 months. This chapter discussed the basic definition of the PSO from which you should have decided exactly what type of PSO makes sense for your organization. You should be thinking about implementing your PSO in the short term but with a view to evolving it to the long-term. Chapter 11, Growing and Maturing your Project Support Office, focuses on the short-term and Chapter 12, The Future of the Project Support Office, focuses on the long-term.

Chapter 11

Growing and Maturing Your Project Support Office

If you do not now have a Project Support Office (PSO) in place expect to spend up to two years to put a functional PSO in place like the one described in Chapter 10. In this chapter I will share a template project plan for establishing a PSO. If you have some type of Project Management Office (PMO) in place now, the implementation plan will accommodate evolving your PMO to the type of PSO recommended in Chapter 10. Both Chapter 10 and 11 set the foundation for discussing and implementing the PSO of the future, which is the topic of Chapter 12, The Future of the Project Support Office.

Project Support Office Stages of Growth

The Software Engineering Institute (SEI) at Carnegie Mellon University over the past several years has developed a maturity model for software engineering. It has gained wide support and has become a standard of the software development profession. The model is called the Capability Maturity Model (CMM). It has recently been adapted to project management in the form of a Project Management Maturity Model (PMMM). We are going to use the five maturity levels of the PMMM to answer the questions: Where are you and where are you going?

Level 1: Initial

Level 1 is the level where everyone basically does as they please. There may be some processes and tools for project management and some may be using them on an informal basis. Project management training is non-existent and help may be available on an informal basis at best. There doesn't appear to be any signs of a formal organization for supporting project management.

Level 2: Repeatable

Level 2 is distinguished from Level 1 in that there is a documented project management process available. It is used at the discretion of the project manager. There is some training available for those who are interested. The only sign of a PSO is through some part-time support that will help a project team on an as-requested basis. Establishing Level 2 Maturity can be a 6- to 12-month project.

Level 3: Defined

The transition from Level 2 to Level 3 is dramatic. The project management processes are fully documented and project management has been recognized as critical to business success by senior management. A formal PSO is established and staffed and given the responsibility of assuring enterprise-wide usage of the methodology. Enforcement is taken seriously. A solid training curriculum is available. There is some sign that project management is being integrated into other business processes. The biggest distinction between Level 2 and Level 3 Maturity is that at Level 3 everyone is required to use the documented process. Getting to this point in maturity generally requires a massive effort. The biggest challenge is to convince project managers that the documented process is, in fact, the best process. That is a tall order because project managers will come to your organization with all sorts of tools, templates, and processes that they will claim are best. My advice is to vet these tools, templates, and processes so they can be used within the project management methodology your organization has implemented.

Level 4: Managed

At Level 4 Maturity, project management is viewed as a critical success factor by the organization. A complete training program and professional development program for project managers is in place. The PSO is looked upon as a business, and project portfolio management is of growing importance. The project portfolio is an integral part of all business planning activities. So Level 4 differs from Level 3 in that at Level 4 the project management methodology has been integrated into other business processes.

Level 5: Optimized

The PSO is the critical component of a continuous quality improvement program for project management. Progress in the successful use of project management is visible, measured, and acted upon. Level 5 is characterized by a continuous process improvement program for the process and practice of the project management methodology.

A Step-by-Step Plan

We can now put the pieces of a plan together. Based on what we have done so far our plan to establish a PSO might look something like Figure 11.1.

Figure 11.1 A Plan to Establish a PSO

Establishing a PSO is an agile project and all agile projects begin with a Project Overview Statement (POS). The POS is a one-page document that provides a high-level description of the PSO development project written for anyone in the organization who has a reason to know what you are proposing to do. It answers these five questions:

- What problem or opportunity is being addressed by this project?

- What is the goal of the project?

- What are the objectives of the project?

- What are the success criteria?

- What are the major obstacles, risks, and assumptions?

The POS also serves as a gating factor for the senior management team (SMT) because it describes the project at a level of detail sufficient for them to make a go/no go decision on committing the resources to do the detail planning. Let's take a brief look at each part of the POS:

- Problem/opportunity. This statement describes a business condition that needs no defense or further clarification. Anyone who reads it will understand it and agree with it. The importance of this statement will determine whether or not the reader will continue to the goal statement or not. If the situation is grave enough, their continued reading is a foregone conclusion.

- Goal. The statement is clean and crisp. It states what will be done and how long it is estimated to take.

- Objectives. The objective statements expand and clarify the goal statement and may suggest interim milestones and deliverables. The objective statements form a necessary and sufficient set of objectives. They are all needed in order to achieve the stated goal and none of them are superfluous.

- Success criteria. Here is where the business value that a successful project will deliver to the enterprise is stated. It must be expressed in specific and measurable quantitative terms.

- Assumptions, risks, obstacles. Anything that might compromise the successful completion of the project is documented here but this is not the complete risk management plan. The list highlights for the SMT some of the potential problems that they might be able to mitigate for the project team. Second, they provide some risk data for the financial analysts to estimate the expected return on the investment in a PSO. They will consider the success criteria versus risk to determine the expected business value that can result from this project. In case there were other projects vying for the same resources, the analysts would have a comparable statistic to use to decide where to spend their resources.

Form the PSO Task Force

The PSO Task Force forms the strategy group for this project. They are to be considered members of the project team. The task force members should be decision makers from those business units that will be impacted by the PSO or will impact the PSO. The size of the enterprise will determine how many members there will be. A task force of 8 to 10 should work quite well whereas a task force of 20 could be counterproductive. Without the support and commitment of each task force member, the PSO is unlikely to succeed. Since their operations will affect the PSO, they must participate in its mission and have an opportunity to be heard as decisions are made on the mission, functions, and services the PSO will provide.

Where Are You?

There are several metrics that have been developed to quantitatively measure the maturity level of your project management processes. I have developed one that consists of over 800 yes/no questions. These questions cover all five maturity levels for all 39 project management processes identified by the Project Management Institute (PMI) in their Project Management Body of Knowledge (PMBOK). Figure 11.2 shows the results for a recent assessment for one of our clients. The data on each of the 39 processes have been aggregated to the knowledge area level.

Figure 11.2 Maturity Level Data for Nine Knowledge Areas of PMBOK

This one graphic conveys a lot of information about this organization's project management maturity levels. First of all, the dashed line shows the maturity level of each knowledge area as documented in the organization's project management methodology. The box and whisker plots are maturity level data on how project management was practiced in several projects that were reviewed in the same quarter. The box and whisker plot is a summarized view of the data points for each project on a single knowledge area. Each box displays the middle 50% of the data. The end points of the whiskers denote the extreme data points. The shading denotes the status of the knowledge area. The darker shaded box indicates a process whose practice is significantly below the maturity level of the baseline process. The lighter-shaded box indicates a process whose practice is significantly above the maturity level of the baseline process. For example, let's take a look at the Scope Management Knowledge Area. The projects that were reviewed demonstrated a maturity level range from a low of 1.2 to a high of 4.1. The middle half of the data points range from 1.8 to 2.9. The Scope Management Knowledge Area was assessed at a maturity level of 3.5.

Where Do You Want to Go?

The long-term goal of the PSO is to assure project success. It should be obvious that that means at least the attainment of Level 3 Maturity. Without a documented process in place and in use by all teams, it is unlikely that there will be any measurable increase in the rate of project success.

On the other hand, to casually state that Level 4 Maturity is the goal of the PSO is not appropriate. That is clearly a business decision. To attain Level 4 Maturity is a big step. It is very costly in terms of the extent of change in the organization. We would equate that change to the evolution of the enterprise to a project-based organization. To move from Level 4 to Level 5 is a matter of implementing a continuous quality improvement process within the PSO. That is far less traumatic and usually involves not much more than putting teeth into a project review process and a concerted effort to capture and implement best practices from the organization's projects as well as projects external to the organization.

How Will You Get There?

It goes without saying that the lower your current project management maturity level is, the more challenging it will be to move to Level 3 or higher maturity. Level 3 is where the PSO can really begin to make an impact on the practice of project management. It is at this level that the organization is fully bought into project management. Teams must use it and the PSO is monitoring that usage. Best practices are identified through project reviews and folded back into the methodology. All signs are positive.

How Well Did You Do?

At the completion of each process improvement program, an assessment is made of what was accomplished versus what was intended. If further improvements are possible, another process improvement effort is commissioned. Table 11.1 gives a brief description of what actions should be taken to move from one level to the next.

Table 11.1 How to Move to the Next Maturity Level.

Current PSO Maturity Level

Characteristics of PSOs at this Maturity Level

Initiatives that Will Move the PSO to the Next Maturity Level

Initial (1)

Some defined project management (PM) processes available
Informal support to teams as requested
No PM training available

Assemble a task force to establish a PM process
Document the PM process
Make PM training available

Repeatable (2)

A documented PM process is in place
Part-time support to teams available
Limited PM training is available

Establish programs to increase PM process usage
Establish a full-time PSO staff to support teams
Monitor and enforce compliance
Increase available PM training

Defined (3)

Fully documented and supported PM process
Full-time support to teams is available
All project teams are using the PM process
PM processes are integrated with other processes
More extensive PM training is available

Projects are made part of the business plan
Put project portfolio management in the PSO
Give the PSO an active role in project staffing
Offer more extensive training
Create a career development program in the PSO
Staff project managers in the PSO

Managed (4)

PSO responsible for professional development
Complete PM training is available
Project portfolio is managed as a business

PSO begins to identify and adopt best practices
Metrics are defined to track process quality
Project reviews are used to monitor compliance

Optimized (5)

A continuous improvement process is in place
There is measured improvement in project success

Challenges to Implementing a Project Support Office

Too many executives have the impression that a PSO is mostly a clerical function and establishing one is not too difficult. Nothing could be farther from the truth. J. Kent Crawford provides a compelling discussion of some of those challenges (The Strategic Project Office: A Guide to Improving Organizational Performance, Second Edition, New York: Marcel Dekker, 2010). The following is the list of Crawford's challenges:

- Speed and patience

- Leadership from the bottom up

- A systems thinking approach

- Enterprise-wide systems

- Knowledge management

- Learning and learned project organizations

- Open communications

Speed and Patience

To effectively deploy a PSO can require two to five years for full implementation. That is a long time. According to the Standish Group research, the longer the project, the higher the probability of project failure. The way out of this apparent dilemma is to plan the PSO deployment in stages. Each stage must deliver visible and measurable value to the organization. To do otherwise is to court disaster.

Leadership from the Bottom Up

A major strategy in putting a PSO in place is a bottom-up strategy. At the department or project level, you will have to demonstrate value by showing the results that a PSO can achieve. By way of example then, others in the organization will see that success and ask how they can do it in their own areas. This grass roots effort will be contagious and will be one of the keys to a successful PSO implementation over time.

A Systems Thinking Perspective

This goes to the very heart of a PSO contributing at the corporate level. At some point in the implementation of the PSO, senior managers will begin to see how an effectively managed project portfolio can contribute to corporate goals. Senior managers begin to think about the portfolio and not just the projects that make it up. This transition from Level 3 Maturity to Level 4 Maturity is the result of a major discovery by senior management. They begin to think in terms of a systems perspective.

Enterprise-Wide Systems

This is clearly characteristic of a Level 4 organization. The integration of the project data into the other corporate databases allows senior managers the tools they need to make enterprise-wide business decisions where projects are the strategic components of their business plans. To make this jump from single project focus to strategic portfolio focus is the sign of a Level 4 PSO.

Knowledge Management

To drive thinking to the enterprise-wide level requires sophisticated corporate databases, standardization of data capture, and the application systems to extract knowledge from information. Even something as simple as a database of best practices and lessons learned has been implemented in only a few organizations. Part of that is due to the fact that project management is in its infancy. There are standards at the project level but few standards at the portfolio level.

Learning and Learned Project Organizations

Most organizations have not taken the education and training of project managers very seriously. That has to change, if the PSO is expected to make an impact on project success. A comprehensive curriculum with a variety of delivery approaches is needed. Career and professional development programs for project managers are few and far between. The PSO is positioned to deliver but senior management must first make the commitment and provide the needed resources.

Open Communications

Communications between and among projects and from first-line managers through to executive levels must be open and free. The PSO can establish and maintain the channels of communications.

Putting It All Together

Chapter 10, Organizing and Defining Your Project Support Office, and this chapter provide both the definition and a template implementation plan for establishing your PSO. That should be your starting point but there is more to consider. The SMT needs to start thinking about future evolution of the PSO. The complexity and uncertainty of the emerging project management world gives good reason to think about the effective support of projects and how the PSO must respond. That is the topic of Chapter 12, The Future of the Project Support Office.

Chapter 12

The Future of the Project Support Office

The history of information technology (IT) offers us some insight into the probable future of the project support office (PSO). History is going to repeat itself with the PSO. It won't be in my lifetime but it will happen. In the late 1950s IT was the province of a select group of engineers. If a manager wanted a business application, they had to enter the domain of the engineer and hope they could describe what they wanted and actually get it. I remember how frustrating and often disappointing those early times were because I was one of those confused managers. In time my staff and I acquired the skills to use some of the emerging development tools and we took a more proactive role in our development needs. The fourth-generation languages of the 1970s gave us the kick-start we needed. Modeling tools like unified modeling language (UML) are the current offering. In some cases the manager's staff could do most of the high-level design work themselves and turn the actual code development over to the IT developers. Whether that was a good strategy isn't the issue here. It happened and it continues to happen. We are now seeing a trend in strategic systems where development is becoming the way businesses operate. Both the business analyst (BA) and business processes manager (BPM) have come on the scene and are often assigned into a business unit. They are the subject matter experts (SMEs) for new and improved systems for their business unit. IT is rapidly repeating the history of the telephone and becoming a utility. The evolution in that direction is clear and certain. No one can predict the future of the systems development environment and support tools but the trend to continuing sophistication is already established. That trend includes imbedding human intelligence and systems development in the software applications. As long as that trend continues, the days of IT as a utility will be part of your future.

In the meanwhile, after 40 years of participation and observation, I see similar trends at work in project management, business analysis, and business processes. It won't be happening anytime soon and during that evolution the entire senior management team (SMT) will depend on a maturing internal support function for those disciplines. So the short-term goal of the SMT is to continue developing a support function for those disciplines and the long-term goal of the SMT is to integrate those support functions into the business units themselves. The long-term goal may or may not be reached. A lot of water will pass under the bridge before that will occur if it will occur. In the meanwhile what should the PSO look like and what should it do? At this point in time the short-term PSO that I envision doesn't exist yet but its emergence in the foreseeable future is clear. To me that is obvious.

So the short-term PSO will evolve into a support organization for business projects, programs, processes, and portfolios—the four Ps that appear in what I am going to name the Business Project, Program, Portfolio, Process Support Office (BP^4SO). So far I have helped you glimpse into the predictable future as follows:

- In Chapter 3, The Complex Project Team, I defined the position class that will provide the professionals support for the BP^4SO with the necessary integration of disciplines (project management, business analysis, information technology, and business processes).

- In Chapter 5, A Professional Development Model, I defined the human resources management system (HRMS) that is needed to build the inventory of professionals to support the BP^4SO.

- In Chapter 8, Agile Project Portfolio Management Process, I defined a model to effectively use the inventory of professionals and align the portfolios to that inventory.

- In Chapter 10, Organizing and Defining Your Project Support Office, I described the PSO that is needed to support you in your complex project and program investments.

The integration of all four of these entities is future oriented and certain to be part of your successful contemporary organization someday. For now, the best strategy is to make decisions that will accommodate that integration when it occurs. In this chapter I want to integrate those disciplines into a cohesive unit—the BP^4SO. Think of the BP^4SO as the PSO of the future. It does not exist today but by my estimation the trends I see portend of just such an entity emerging in the foreseeable future. My message to you is to begin laying the foundation for it by designing your PSO and putting a plan in place so that it can begin evolving into the BP^4SO of the future.

Hub and Spoke BP^4SO

In preparation for the BP^4SO, the PSO hub and spoke organizational structure is probably the only organizational structure that makes good long-term business sense. This structure was introduced in Chapter 10. The initial implementations of the BP^4SO hub and spoke will be to put the hub enterprise PSO (eventually it will be called the enterprise BP^4SO) in place. The spokes will emerge in the business units as demand dictates.

To put the hub in place, the following steps should be taken in the order listed:

- Define the mission and objectives of the hub.

- Establish the policies and standards of the hub.

- Define the support services offered by the hub.

Figure 12.1 illustrates the BP^4SO of the future. It is simply an updated version of Figure 10.1. The BP^4SO will be implemented in several phases. Initially the enterprise BP^4SO will be established and serve the support needs of the enterprise. As demand grows, division-level BP^4SOs will be established and offer support services as needed by the division. These support services might encompass all four disciplines. Once a second division has established its BP^4SO, communities of practice will begin to appear in order to establish communication links between divisions.

Figure 12.1 BP^4SO of the Future

As demand in a division increases the spoke that feeds that division is established. To put a spoke in place the following steps should be taken in the order listed:

- Define the mission and objectives of the division.

- Define hub policies and standards.

- Adapt the mission and objectives of the division BP^4SO to the policies and standards of the enterprise BP^4SO.

- Establish the policies and standards of the division BP^4SO so they are in compliance with the policies and standards of the enterprise BP^4SO.

- Define the discipline support services offered by the division.

The initial discipline of the enterprise BP^4SO will probably be project management (PM) because of the strong historical roots of the project management office (PMO). There is already a growing trend in establishing a Community of Practice (COP) and Center of Excellence (COE) in BA and so that will most likely be the second discipline that is integrated into the BP^4SO. That will give the BP^4SO a strong generalist orientation in PM and BA. From that point the IT and business processes (BP) disciplines can be added as demand grows for specialists in the division BP^4SOs.

At some point in time—usually when two or more division BP^4SOs are in place—COPs for all four disciplines will emerge. They may support all four disciplines in an integrated model or support single disciplines as the BA COP now does. These will be the only direct communications link between division-level BP^4SOs. A sharing of best practices will develop as will training, consulting, and other support services that can be shared. Some of these can continue to be offered by the Enterprise BP^4SO.

Staffing the BP^4SO

For me the only staffing strategy that makes sense is to rotate complex project managers (CPMs) between the enterprise BP^4SO, division-level BP^4SOs, and their home business unit. That accomplishes three very important things:

- They maintain a professional relationship and credibility with their peers in their home business unit.

- They seed their home business unit with practices and techniques used elsewhere in the enterprise BP^4SO and the division-level BP^4SOs.

- When they return to a BP^4SO they bring best practices back from their home business unit and pick up some clues about improving existing tools, templates, and processes.

Most attempts at spreading best practices across the organization have been a disappointment. “My project is different” and “Not invented here” are the major obstacles.

Rotations are a great way to reward a CPM and give them a chance to recharge themselves. This is especially important after a really tough assignment. The rotation can happen in two ways:

- Between projects, when they are “on the beach” they can be assigned special projects within the BP^4SO. These would be short-term projects.

- They can periodically take a sabbatical from their business unit to be assigned a major project within the BP^4SO or simply provide consulting support across the organization. These could be competitive assignments awarded based on a proposal. The proposal could be unsolicited or a response to a request for proposal (RFP) from the BP^4SO. These are great ways for the BP^4SO to do process improvement projects.

Other Considerations

I want to leave this chapter by giving you two other things to think about as you try to envision how the BP^4SO might play itself out in your organization.

Special Weapons & Tactics Teams

The professionals who staff the BP^4SOs will often be formed into Special Weapons and Tactics (SWAT) Teams to tackle the most complex and uncertain enterprise-wide projects. These will be mission-critical projects on whose success the future of the organization may well depend. The most skilled human resources in the organization must be assigned to these projects. Failure is not an option! These teams can be formed from CPMs in the division-level BP^4SOs perhaps under the leadership of a CPM from the enterprise BP^4SO.

Multiple Complex Project Teams

The multiple team projects that populate the project portfolio of large organizations are unlike any other application development projects found today. For example, if you organize IT around client groups and business units, any project that crosses client lines gives rise to a multiple team project. The temptation is to let each team act on its own with some integrating activity at the end to “glue” everything together and hope that it works. For complex projects, that is almost certain to lead to failure and is not recommended. My approach is more deliberate and planned, as you will see.

A SWAT Team will potentially be staffed by CPMs from several divisions. Each comes with their own best practices and must now form a single team. These multi-team projects are particularly challenging because there is no reason to assume they all use the same tools, templates, and processes. They are in effect independent professionals with their own practices. I have had the occasion to work with clients where this situation arose and new management approaches were needed. There are three models I have used successfully. This complication can be somewhat mitigated through the policies and standards issued from the enterprise BP^4SO. The SMT should play a significant role in forming those policies and standards.

Definition: Multiple Team Project

A multiple team project is any project that requires the collaboration and concurrent involvement of two or more independent teams. The teams do not have to be from the same organization.

This is a simple definition, but it can serve our purposes quite well. In large companies this can occur quite frequently, but even in smaller companies it happens, too. For example, the IT department has its own methodology for doing software development. The mechanical engineering department has its own methodology for doing new product development. Teams from both departments are brought together to develop a new product with a significant software component. The IT team has decided that this is an Agile Project Management (APM) project and will use the Adaptive Project Framework (APF) project management life cycle (PMLC) model. The engineering department has used a linear PMLC for over 20 years and has no intention of doing it any differently. You are the project manager. What would you do? The answer lies in using one of the three management structures discussed in this section.

Challenges to Managing a Multiple Team Project

For many years the focus in project management has been on the effective management of the project team. Its members were selected based on their expertise relative to the requirements of the project; requirements were gathered and documented; a project plan was built and executed; client change requests were proposed and acted upon in the best interest of the enterprise and the goal of the project.

All that has changed for many organizations. Along came companies like Wal-Mart with its unique client-centric information systems structure. The IT Department is organized into independent teams. Each team focuses exclusively on a specific line of business or client group and is able to satisfy their requirements for new and enhanced applications systems. These teams are very effective in meeting their client's specific needs. The IT teams became experts in the client's line of business. In meeting the specific business systems needs of their client group, each team created its own project management methodology with the tools, templates, and processes needed to support it. Many of the team members were in fact the CPM professionals discussed in Chapter 3, The Complex Project Team. At the time they were my client, Wal-Mart's Information Systems Department had over 10,000 associates organized into 250 such teams. Whenever projects involved more than two teams you can imagine the potential conflicts between methodologies that usually occurred. How to manage such situations is the focus of this section. Here are a few thoughts just to get your creative juices flowing. If you need more details on the items on this list see my book Effective Project Management: Traditional, Agile, Extreme, 5th Edition, (New York: John Wiley & Sons, 2009).

- Working with fiercely independent team cultures

- Working with different team processes

- Accommodating competing priorities

- Communicating within the team structure

- Establishing a project management structure

- Establishing one PMLC

- Building an integrated project plan/schedule

- Defining a requirements gathering approach

- Establishing a scope change management process

- Defining the team meeting structure

- Establishing manageable reporting levels

- Sharing resources across teams

- Searching out your second

The three models I have seen used successfully among my clients are:

- Project office

- Core team

- Super team

They are briefly described in the sections that follow. For a complete discussion, see my book: Effective Project Management, cited previously.

Project Office Structure

It is a common practice in organizations to establish a project office (PO) to manage large or mission-critical projects. These structures are temporary and exist only to serve the needs of large or mission critical projects. Some organizations will even establish a PO whenever the team size reaches a certain number (30 for example is the rule used by one of my clients). The PO is just another layer of management, to whom the individual project managers assigned to the project report. The PO provides general management support and coordination as well as basic administrative services to each of its project managers.

Definition: Project Office

A project office is a temporary management structure established to coordinate and support the work of several independent teams who are concurrently working on the same single project that has task dependencies across the team structure.

First note that the PO structure is a temporary structure. It is managed by a program manager and exists only to serve the needs of the individual teams who are working on the same project. Once the project is complete the PO is disbanded. The purpose of the PO is to coordinate and administratively support the several project teams working on the project and to interact directly with senior management and the stakeholder groups. Each team has a project manager who is accountable to the PO manager and coordinates their project work with the client group they support and with the other project teams.

Project Office Characteristics

The PO structure is very simple, as Figure 12.2 illustrates.

Figure 12.2 Project Office Structure

This structure scales very well to large projects. The support staff ranges from a minimum of a single part-time administrative person (the service might be provided centrally by the PSO) to a practical maximum of several full-time support staff and associate PO managers.

The list that follows is a comprehensive list of the roles and responsibilities of the PO manager and support staff:

- Organize and manage the entire project.

- Develop high-level project plan in collaboration with team managers.

- Integrate and coordinate the project plans of each team.

- Maintain the overall project schedule.

- Monitor and manage resource utilization.

- Prepare and distribute project status reports.

- Plan and conduct team meetings.

- Process scope change requests.

- Solve problems escalated from the teams.

- Negotiate and solve inter-team problems.

Project Office Strengths and Weaknesses

The strengths of the PO Structure are as follows:

- Coordinates the work of several independent teams

- Scales to large projects

- Managed from a single integrated plan

- Integrated resource management control

- Allows teams to maintain their practices

On the other hand, the weaknesses of the PO Structure are as follows:

- Must manage across disparate practices

- Team members have to manage competing priorities

- May have a cumbersome scope change management process

Advice to the SMT on When to Use the PO Structure

This structure is common and your CPMs are probably aware of it and now you are too. The PO structure is the least disruptive of current project structures across the enterprise and so would be the preferred model for the teams. In a very mature enterprise it may make sense politically to use this structure. At the same time it places a significant coordinating burden on the shoulders of the PO manager and their support staff. The PO manager's role is seen as coordinating rather than having direct management responsibility over the team managers. That squarely places the PO manager in a position where their skills as leaders and negotiators are called into service.

As project complexity and uncertainty increase the PO structure loses its appeal. In APM or extreme project management (xPM) projects any organizational barriers that can be removed or avoided should be. That would argue against using a PO structure for such projects. If team size is less than 30 the PO structure can still be made to work for simpler APM projects but there is a better choice. The PO structure works best for linear and incremental projects. You have to make room for creativity and flexibility, and inheriting as many project management practices as there are teams is unnecessarily burdensome on the project manager and increases the risk that a solution will not be discovered. For APM and xPM projects the super team (ST) structure discussed later is generally the better choice.

Core Team Structure

The core team (CT) structure originates from an idea I got while doing some consulting work for Wal-Mart. CT is the name they used. Originally it was a structure they used for critical and complex projects. It was not a structure designed for multiple team projects, but I have redefined it to fit multiple team projects.

Definition: Core Team

A core team is a temporary team comprising a small number of SMEs chosen and managed by the core team manager who consults, advises, and supports the core team manager and the teams assigned to the project.

Core Team Characteristics

The core team structure is very simple as Figure 12.3 illustrates.

Figure 12.3 Core Team Structure

The CT consists of the recognized resident expertise assigned to the project. Collectively their expertise covers the business units and systems that support them. The project manager is not the resident expert. Because they—the CT—occupy senior level positions in the CPM position family they have the respect and credibility of the teams. Often they will be consultants or senior-level consultants. They represent the subject matter expertise available to the team. In fact, the CT members will often be from some of the same client groups and business lines as the teams themselves. They have earned the right to speak on the project and when they do, people listen! Their responsibility is both up to the CT manager and down to the individual teams and the members.

The list that follows is a comprehensive list of the roles and responsibilities of the CT manager and the CT:

- Advise each team on technical matters.

- Provide subject matter expertise on enterprise systems and processes.

- Support each team as requested and as needed.

- Collaborate with and advise the CT manager as requested.

- Negotiate and help resolve inter-team problems.

Core Team Strengths and Weaknesses

The strengths of the CT structure are as follows:

- The CT is hand-picked by the CT manager

- Provides the best available advice to the CT Manager

- Coordinates the work of several teams

- Lends support and credibility to the decisions of the CT manager

- CT members are assigned 100 percent to this project

- Takes advantage of the most experienced SMEs

- Allows teams to retain their business unit practices

On the other hand, the weaknesses of the CT structure are as follows:

- May not scale to the larger projects

- Individual team plans are not necessarily integrated

- Must manage across disparate practices

- Project team members may have divided loyalties

- Same SMEs are chosen for CT membership, so it doesn't provide development opportunities for future core team members

Advice to the SMT on When to Use the CT Structure

The CT structure is quite unusual and I wouldn't expect your CPMs to be aware of it but you are and you can advise them accordingly. As complexity and uncertainty increases, the decision would favor either the CT or ST structure discussed next. The size of the project is a limiting factor in using the CT structure. In my experience, CT structures are used for critical mission projects, so the business case becomes the driving factor. The cost to the resource pool is so great that only a critical mission project can justify this structure. CT structures can be used for linear, incremental, and iterative projects.

Super Team Structure

For those cases where team size is not a deterrent to successful project performance, this structure can work quite well. It does require that the project manager be experienced in managing large (even very large) projects. This is not a job for the faint of heart. The team will have one person leading it (a senior member of one of the teams). In most cases, there will be at least one other management layer within the team. These subproject leads will be responsible for some of the deliverables. It would be a mistake to organize the subprojects along strict client-centric lines. This smacks of the PO structure. The structure of the project should suggest how those subprojects might best be defined. Using the concept of maximum cohesion and minimum coupling would be a best practice that has good application here.

Definition: Super Team

A super team is a temporary management structure used for a single project that integrates several independent teams into a single team managed by a senior-level project manager and supported by several subproject managers.

Having a single team structure means that all of the tools, templates, and processes in the five process groups can now be used. As project size increases several things happen:

- A formal requirements management process is employed.

- The planning process applies here without revision.

- An experienced facilitator should prepare and conduct the planning session.

- The ST Manager focuses on plan contents, not on plan creation.

- The skill and competency profile of every team member will be needed.

- Intermediate levels of project management personnel will be needed.

- Project management software will be needed for planning and resource management.

- A technographer enters into a computer exactly what the facilitator requests of them. The output is displayed on a screen for all to see.

Super Team Characteristics

The ST structure is a very simple hierarchical structure as Figure 12.4 illustrates.

Figure 12.4 Super Team Structure

This is a very dynamic structure that can easily expand or contract as project size increases or decreases. So you should be asking: “How big is big enough?” Here are some rules that I have used in my consulting practice. They seem to hold up under the experiences I have had.

First of all is the size of the ST support staff. To compute the number of full-time equivalent (FTE) positions you need on your support team add up all of the estimated labor time associated with the tasks from the work breakdown structure (WBS). Take a percentage of that number. In my experience that percentage has ranged from 7 to 20 percent. That percentage increases as the size of the project increases. For example, suppose the project duration is 12 months and the total labor hours are estimated at 50,000. 10 percent of 50,000 hours is 5,000 hours spread across 12 months. That averages 416 hours per month. The average work month has 160 hours, so you will need about 2.6 FTE positions to support your administrative needs on the project. Some organizations don't think like this when it comes to staffing so you may have a selling job to do. Somebody has to pick up an estimated 2.6 position duties. Look around you. The team members are your resource, and what you can't or shouldn't do yourself someone on the team will have to do. Look for those administrative duties you can pass on to others on the team. Rotate those duties around. Don't make the mistake of thinking that one team member should do all the meeting minutes.

Second is the size and disposition of the senior, associate, and assistant project managers. Again from my experiences, the number 30 is the key to calculating the size and disposition. Every team increase of 30 members triggers another structural change to the management of the project. The structural changes are bottom up changes. For example, my preferred disposition of 30 team members would be to teams of five to six members, so I would have five or six teams. Say five for the sake of the example. As ST manager I can handle five direct reports, so I don't need any other project managers yet. By the way you should probably set the maximum number of direct reports any project manager should have. In the example for a team of 30 that number is 6, and that's acceptable. As for ST support staff you have the formula and can figure that out. As overall project team size increases, you add to the sub-teams until you need more sub-teams, in which case you need at least one assistant PM to cover the increased management needs. There is no exact formula that I can give you because so much is a judgment call on your part. What makes sense for the project should be the final guide.

The list that follows is a comprehensive list of the roles and responsibilities of the ST manager and the team leaders:

- Organize and manage the project.

- Develop the project plan.

- Maintain the overall project schedule.

- Monitor and manage resource utilization.

- Prepare and distribute project status reports.

- Plan and conduct team meetings.

- Process scope change requests.

Super Team Strengths and Weaknesses

The strengths of the ST structure are as follows:

- Managed from a single integrated source

- Scales to large projects

- Integrated resource management control

- Standardizes on a set of tools, templates, and processes

On the other hand, the weaknesses of the ST structure are as follows:

- Establishing standardization

- Team members have to manage competing priorities

The ST structure works for all sizes of multiple team projects. All you need in order to use it is the agreement of the key team leaders to agree to the conditions. They will hear you say that the standards to be used will be their decision under your guidance. I recall one such project where one of the team leaders had been very successful with a particular approach to requirements gathering. He presented his argument to the other team leaders and won them over. With the support of the other team leaders, he was given the responsibility to manage that part of the project. The message that I want to convey to you is that the entire team needs to participate in establishing those standards. Delegate responsibility for project phases or processes to team leaders who have earned the right to have those responsibilities. These can be great motivation tools, too.

Advice to the SMT on When to Use the ST Structure

The ST structure is adaptable to several different project types regardless of total team size. It should be the structure of choice for APM and xPM projects. For the more mature project environment, the ST structure is the obvious choice. That doesn't mean it is the default choice and when you are in doubt use the ST structure.

Project-based Organizations

The project-based organization is one of the strategic organizational structures of the future. The management demands placed on an organization and the SMT because of project complexity dictates that this needs to be seriously considered by organizations.

Putting It All Together

The PSO of the future that I am calling a BP^4SO is a marked change from the PMO of today in two respects. First of all, it supports projects, programs, processes, and portfolios not just projects. So the BP^4SO can embrace the entire spectrum of complexity, uncertainty, and risk that are part of the complex project management world. Second of all, it supports the four disciplines that are part of that complex project management world; namely, project management, business analysis, business processes, and information technology.

As projects span the entire organization and even embrace multiple organizations, the need for processes to manage projects that involve multiple and independent teams is paramount. Three models that have been shown to work in practice were presented: PO, CT, and ST.

Part IV

Summary

Organizational Challenges and Mitigation Strategies

The PSO of the future must be full service. That means it provides direct support to complex projects and project managers in all four disciplines. Current PMOs already do that for the PM discipline. COE and COP do that for the BA discipline. The IT and BP disciplines have no comparable equivalent. The challenge there will be to create client-side support as a bridge between the IT and BP functions. The IT function is in a state of transition. It is steadily becoming more of a utility or commodity and so the support of it is a changing target. Here the client is the project and the project manager. The BP function is imbedded in the business units where the expertise is resident in the business unit that owns the process. Defining the nature of that support is part of the challenge of becoming a full-service PSO. So the challenge of providing full-service is simultaneously one of integrating support and expanding breadth of discipline coverage. From the perspective of infrastructure, that has been adequately discussed in Chapter 12. In this section I want to consider the operational challenges that will be presented. To a large extent, some of these are imbedded in the present organization but many are unique to the PSO of the future. Both are discussed in the following sections.

Generalists versus Specialists

Except for the simplest of projects every project team should have both generalists and specialists among its members. The more complex the project the more critical the need will be. Generalists bring an organizational perspective to the project and with that experience will see solution opportunities that the specialist will not. Specialists bring a specific business unit or business process expertise to the project, so with that experience they will see adaptations of the ideas suggested by the generalist to the specific needs of the business unit or business process covered by the project.

Balance between Compliance and Support

The majority of current PMOs are founded on the development of project management standards and monitoring compliance to those standards. That is certainly needed, but if it is the way the practitioners have come to understand their PMO, it will not be the way the PMO can effectively serve complex project teams. Rather the understanding that should pervade the organization is that the PMO should first be seen as a support organization; hence the reason for calling it a PSO rather than a PMO.

Compliance under the guise of a PSO supporting complex projects is an interesting and challenging practice. You have come to understand complex project management as a creative process based on organized common sense and an environment that supports creativity rather than constrains acceptable activity to a pre-defined set of processes. The emphasis on complex project management is on practice not process and that adds a challenge to the conduct of the compliance officers in the PSO. In the final analysis it is the delivering of acceptable business value that is the real testimony of a CPM and CPT adherence to any compliance standards.

Project Review

The CPM and CPT might have taken exactly the correct steps and decisions with respect to their project but success was just not in the cards. Remember that complex projects are filled with uncertainty, complexity, and high risk. The collective wisdom of the sponsor, client, and entire project team was just not sufficient to find an acceptable solution. Maybe there is no acceptable solution to be found with present technology and knowledge. The solution will have to wait for the passage of time in order to be found. That is the just the nature of the beast. And so project review must reflect that reality.

The SMT project review board must understand that reality and act accordingly. Their responsibilities will of course include suggesting corrective action plans for the CPM to solve process problems but perhaps as important will be suggestions for solution discovery that may not have been considered by the client, CPM, and CPT.

Portfolio Review

The PSO provides portfolio review and analysis support to the SMT. Recall from Chapter 7, The Project Birth and Death Process, that there are three categories of projects that have to be considered as the performance of the portfolio is analyzed and portfolio contents for the coming portfolio cycle are considered. Those categories are: active, new, and postponed. Will active projects be continued in the next cycle or will they be replaced by projects that were postponed from an earlier cycle or new projects that have been selected for possible inclusion in the coming cycle? The PSO is a critical component in whatever process is used to make those difficult decisions.

Executive Bookshelf

Here are some references that you may find useful. I have included those that reinforce the material introduced in Part IV as well as material that gives you more detail on each of the topics discussed.

Crawford, J. Kent. The Strategic Project Office: A Guide to Improving Organizational Performance. New York: Marcel Dekker, Inc., 2002.

Dye, Lowell D., and James S. Pennypacker, editors. Project Portfolio Management: Selecting and Prioritizing Projects for Competitive Advantage. West Chester, PA: Center for Business Practices, 1999.

Hallows, Jolyon. The Project Management Office Toolkit: A Step-by-Step Guide to Setting Up a Project Management Office. New York: AMACOM, 2002.

Wysocki, Robert K. How to Establish a Project Support Office: A Practical Guide to Its Establishment, Growth and Development. MA: EII Publications, 2006.

Wysocki, Robert K. “ How to Establish a Project Support Office: A Practical Guide to Growth and Development” Cutter Consortium, 2008, Vol. 9, No. 3.

Wysocki, Robert K. “ Distressed Projects: Prevention and Intervention Strategies” Cutter Consortium, 2007, Vol. 7, No. 8.

Wysocki, Robert K. “ Managing a Multiple Team Project” Cutter Consortium, 2007, Vol. 7, No. 4.

Wysocki, Robert K. “How to Establish a Project Support Office: A Practical Guide to Its Establishment, Growth and Development” Worcester, MA: EII Publications, 2006.

Wysocki, Robert K. “Managing a Project That Involves Multiple Teams” Worcester, MA: EII Publications, 2006.

Wysocki, Robert K. Project Management Process Improvement, Boston, MA: Artech House, 2004.

Epilogue

Next Steps

I've put a lot on your plate and given you things to think about that you may not have even considered before reading this book. The project landscape has changed and continues to change. More organizations are becoming project based, raising a variety of challenges that have never been faced before. I have given you my best thoughts about the future that awaits you and my best advice for getting in charge and staying in charge.

Define Your Role in Supporting Complex Projects

Decide now whether or not you expect to be visibly involved and proactive or simply passively involved by making sure that the proper support environment is in place. Either level of involvement is acceptable.

How Will You Make It Happen?

For the three examples given in the following sections I want you to follow the same robust implementation process that I used in Chapter 5, A Professional Development Model. I've adapted it to this discussion. Recall that my model simply asks you to answer five questions:

- Where are you? For the purposes of this discussion you need to assess what you now have in place in the organization. That assessment should be a strengths, weaknesses, opportunities, and threats (SWOT) analysis. The deliverable will be a detailed description of the current state of a business process.

- Where do you want to go? Describe the ideal or end state of the process. If there were no constraints on the process, what would it look like? Include in this description a few performance metrics and your expectations for the performance levels of the end state as compared to the current state. In other words, what is the expected incremental business value of the end state as compared to the current state?

- How will you get there? This is your plan to move from the current state to the end state. I prefer to see a phased plan. Prioritize the end state requirements and, within the limitations of dependencies, implement them in priority order.

- How will you know you got there? There needs to be performance metrics that track how well you are doing with respect to the evolution from current state to end state. Allow the possibility that learning will take place and may result in changes to the end state description and hence a revision of the plan.

- How are you doing? Compare the new performance levels of the now changed process to the planned performance levels. Are you behind or ahead of plan? Any necessary adjustments should be made.

Implementing a Professional Development Program

For our first example let's assume you want to implement a Professional Development Program. That was the topic of Part II, Improving Project Success with Human Resource Strategies and Processes.

Where Are You?

What does your organization do now (the current state) in the way of professional development for its employees? In most organizations it is an informal exercise. That won't work for organizations trying to support a complex project management infrastructure.

Where Do You Want to Go?

This is the time to dream about an ideal end state. Knowing your organization as you do, what is the best environment for supporting a complex project management infrastructure?

How Will You Get there?

The difference between the current state and the end state is the professional development gap that needs to be removed. Depending on the seriousness of that gap, a one-step or phased plan might be advised.

How Will You Know You Got there?

Every process improvement effort needs quantitative performance metrics. The end state should be described by those metrics. In the case of a professional development program, the percentage of employees with active plans in place is one metric and the success of performance against those plans another.

How Are You Doing?

The value of the metrics against the plan for those metrics is a measure of effectiveness.

Implementing Agile Project Portfolio Management

For our second example let's assume you want to implement agile project portfolio management (APPM). That was the topic of Part III, Improving Project Return on Investment (ROI) Using APPM.

Where Are You?

Organizations are beginning to realize that the project is not the end-all entity. Those organizations that have begun to look at projects as just another investment instrument are beginning to see the project portfolio as the end all entity. How to define them, how to populate them with projects, and how to evaluate portfolio performance for possible adjustment are now the significant focus of the senior management team (SMT). It is time to implement a formal portfolio management process. So what is the current state of portfolio management in your organization? Does it even exist? Is it formal? Do you monitor and periodically adjust it?

Where Do You Want to Go?

Portfolios that support complex projects are often constrained by both finances and resources. In your organization what might the ideal end state to accommodate those two constraints look like?

How Will You Get there?

I have done several APPM design and implementation projects. I have found that the best way is a single phase plan recognizing that continuous process improvement will be necessary.

How Will You Know You Got there?

The project portfolio is an investment strategy. Your objective is to generate the maximum business value possible from your choices. While individual project performance is certainly of interest your real focus should be on the performance of the entire portfolio. Some projects will be high-risk high-return projects so not every project in the portfolio can reasonably be expected to be successful but the portfolio should be successful. Metrics such as average return on investment are likely performance metrics.

How Are You Doing?

Actual average return on investment compared to expected, is a good metric for tracking portfolio performance.

Implementing a Project Support Office

For our third example let's assume you want to implement a project support office (PSO). This was the topic of Part IV, Establishing and Maturing an Enterprise Project Support Office.

Where Are You?

You might be considering your first attempt at a PSO or you might have had one in place for some time but are not seeing the expected impact on project success. In either case something needs to be done because project performance is not measuring up to expectations. Too many organizations put the responsibility for project success in the lap of the PSO. I think that is wrong. Rather, the PSO is responsible for creating the infrastructure and support so that projects can be successful. The sponsor is responsible for the business value generated by the product or service delivered. The project manager is responsible for the management of the process that produces the product or service.

Where Do You Want to Go?

The SMT needs to decide what type of PSO is needed. In defining that end state, keep in mind the future PSO and how, if at all, it supports all four disciplines discussed in Chapter 12, The Future of the PSO. The establishment of that PSO can be an evolutionary process. It should be demand driven. Furthermore, the best organizational structure for the PSO of the future is the hub and spoke model. That is an organic model that is demand driven.

How Will You Get there?

As mentioned previously, establishing a full-service PSO should be a multi-phased project. Each phase will expand the support services and increase the maturity of the PSO.

How Will You Know You Got there?

Defining an appropriate performance metric for the PSO is two-fold. One set of metrics should focus on the maturity of the project management process. The other set of metrics should focus on the degree to which the practice of project management is compliant with process maturity. Note that neither of these sets of metrics directly measures project success. One would expect a causal relationship however between high process and practice maturity and a high degree of project success.

How Are You Doing?

The PSO has a significant responsibility in enabling both process and practice maturity. This is reflected by continuous process improvement projects, and effective training, coaching, and consulting with project managers and their team members.

Final Thoughts on the Book

I have tried to give every SMT member food for thought about their roles and responsibilities in establishing an infrastructure that effectively supports the complex project world. The IBM report quoted in Chapter 1, The Project Landscape, dominates my thinking about the importance of effective project management. We are not there yet. All I can hope for is that I have described an end state and path forward for you.

About the Author

Robert K. Wysocki, Ph.D., has over 45 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written 20 books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme, 5th Edition (New York: John Wiley & Sons, 2009), has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

From 1963 to 1970 he was a systems consultant for one of the world's largest electronics components manufacturers. In that capacity he designed and implemented several computer-based manufacturing and quality control systems. From 1970 to 1990 he held a number of positions in both state-supported and private institutions in higher education as MBA Director, Associate Dean of Business, Dean of Computers and Information Systems, Director of Academic Computing, CIO, and Senior Planner.

In 1990 he founded Enterprise Information Insights, Inc. (EII), a project management consulting and training practice specializing in project management methodology design and integration, project support office establishment, the development of training curriculum, and the development of a portfolio of assessment tools focused on organizations, project teams, and individuals. His client list includes AT&T, Aetna, Babbage Simmel, BMW, British Computer Society, Boston University Corporate Education Center, Computerworld, Converse Shoes, Czechoslovakian Government, Data General, Digital, Eli Lilly, Harvard Community Health Plan, IBM, J. Walter Thompson, Ohio State University, Peoples Bank, Sapient Corporation, The Limited, The State of Ohio, Travelers Insurance, TVA, University of California–Santa Cruz, US Coast Guard Academy, Wal-Mart, Wells Fargo, and several others.

He is a Senior Consultant at the Cutter Consortium where he is an active member of the Agile Project Management Practice. He is the Series Editor of Effective Project Management for Artech House, a publisher to the technical and engineering professions. He was a founding member of the Agile Project Leadership Network and served as its first Vice President and President Elect, a member of asapm, the Agile Alliance, the Project Summit Business Analyst World Executive Advisory Board, the Project Management Institute, the American Society of Training & Development, and the Society of Human Resource Management. He is past Association Vice President of the Association of Information Technology Professionals (formerly Data Processing Management Association). He earned a BA in Mathematics from the University of Dallas, and an MSc and Ph.D. in Mathematical Statistics from Southern Methodist University.

Index

Acceptance test procedure (ATP)

Adaptive PMLC models

Adaptive Project Framework: Managing Complexity in the Face of Uncertainty (Wysocki)

Adaptive Project Framework (APF)

Adaptive Software Development (ASD)

“The Agile Manifesto,”

Agile Project Management (APM)

change requests

complexity of project

co-PMs

example projects

generalists and specialists

and PM/BA position

and project landscape

Q2 projects

Q3 projects

staffing

Agile projects. See also Agile Project Management (APM)

APM. See Agile Project Management (APM)

Assessment

Associate Manager

ATP. See Acceptance test procedure (ATP)

Audit, post-implementation

BA (Business Analyst)

career path. See also Career paths

defined

dual-career path. See Dual-career-path model

generalists

historical perspective

integration into project landscape. See Integration of PM and BA into project landscape

landscape sector

misconceptions

one person with both PM and BA responsibility on same project

organizational placement

position description

position landscape

professional development. See Professional Development Program (PDP)

and project planning

responsibilities

risk management

roles and responsibilities

separate BA or single BA/PM issue

skill set

skills and competencies. See Skill and competency profile

specialists

training courses

BABOK

BA/PM

career development

career opportunities

and change requests

and client involvement

co-PMs

curriculum

extreme projects

focus of

landscape sector

and market environment

position landscape

and project landscape

BA/pm

and change requests

incremental TPM projects (Q1)

integration of PM and BA

landscape sector

and market environment

and project landscape

Q3 projects

Q4 projects

and team size

Bloom, Benjamin S.

Bloom's Taxonomy

BP^4SO. See Business Process, Project, Program, and Portfolio Support Office (BP^4SO)

Brennan, Kevin

British Computer Society

Business analysis, defined

Business Analysis Body of Knowledge (BABOK)

Business Analysis Consultant/Architect

Business Analysis Office (BAO)

Business analysis technician

Business Analyst (BA). See BA (Business Analyst)

Business architect

Business Process, Project, Program, and Portfolio Support Office (BP^4SO)

as alternative to PMO

defined

implementing

mission

need for

objectives

organization structure of

staffing models

Business process managers

Business process owner

Business process technician

Business value

collaboration, need for

and conflict resolution

and decision making

justification

maximizing

and project landscape

and project success

Q1 projects

Q2 projects

Q3 projects

Q4 projects

role of BA

Career paths

BA (Business Analyst)

change in

dual-career-path model. See Dual-career-path model

long-term career planning

short-term career planning

skill and competency profile

Career planning. See also Professional Development Program (PDP)

CareerAgent

Carkenord, Barbara A.

Centers of Excellence

Chandler, Margaret K.

Change management

Change requests

Chief information officers (CIOs)

Chief process officer (CPO)

C-level positions

Client environment

Clients

common language, need for

departments affected

history with

involvement

maturity

POS responsibilities

and project management structure

and staffing choices

subject matter experts

wants and needs

Collaboration

need for

PM and BA

PMI and IIBA

Q2 projects

Communications management

Conditions of Satisfaction (COS)

model

and project complexity and uncertainty

and project failure

project management life cycle (PMLC)

requirements elicitation

responsibility for

Communities of Practice

Competitive Advantage: Creating and Sustaining Superior Performance (Porter)

Complexity and uncertainty

APM projects

and communications

contemporary projects

co-PMs, use of. See also Co-PMs

and project landscape

and project management life cycle

and risk management

skills and experience required

and SMEs

and staffing

Conditions of Satisfaction (COS)

Conflict resolution

Consultants

BA generalists

Business Analysis Consultant/Architect

PM positions

requirements elicitation

Senior Business Analysis Consultant/Architect

Senior Consultant

Senior Consultant/Architect

terminology

Co-PMs

Core Teams

Costs

Creating an Environment for Successful Projects (Graham and Englund)

Curriculum. See Training

Deadlines

Decision making

Deliverables. See also Work breakdown structure (WBS)

Conditions of Satisfaction. See Conditions of Satisfaction (COS)

deadlines

incremental

installation

out of scope

post-implementation audit

responsibility for

Director of Business Analyst Management

Director of Business Architecture

Director of Project Management

Doran, George T.

Dreyfus, Hubert L.

Dreyfus, Stuart E.

Dreyfus Model

Dual-career-path model

BA career paths

overview

PM career paths

position family

use of

Dynamic Systems Development Method (DSDM)

Educators and trainers. See also Training

Effective Project Management: Traditional, Agile, Extreme (Wysocki)

Emertxe Project Management (MPx)

Englund, Randall

Enterprise analysis

Executive level positions

BA positions

c-level positions

generic

PM/BA and BA/PM sector

Practice Director

Process Director

Extreme Project Management (xPM)

Extreme projects

Failure. See Project failure

Force field analysis

Fowler, Martin

Gap analysis and resolution, staffing needs

Getting It Right: Business Requirements Analysis Tools and Techniques (Hass, Wessels, and Brennan)

Gottesdiener, Ellen

Graham, Robert

Graham-Englund Project Selection Model

A Guide to the IIBA Business Analysis Body of Knowledge (BABOK), Version 2.0

A Guide to the IIBA Business Analysis Competency Model, Version 1.0

A Guide to the Project Management Body of Knowledge (PMBOK)

Hass, Kathleen B.

Highsmith, Jim

Hossenlopp, Rosemary

HR managers

Human resource management system (HRMS)

Incremental TPM models (Q1). See also Q1 (quadrant

Infrastructure projects. See also Q1 (quadrant

Integration of PM and BA into project landscape

challenges

mapping

one person with both PM and BA responsibility on same project

opportunities

overview

strengths of integration

weaknesses of integration

International Institute of Business Analysis (IIBA)

IRACIS success criteria

Iterative PMLC models

Kennedy, John F.

Koteinkov, Vadim

Lewis, Jim

Linear TPM models (Q1). See also Q1 (quadrant

Management structure. See Integration of PM and BA into project landscape

Managers

Managing Large Systems: The Large-Scale Approach (Sayles and Chandler)

Market environment

Mastering the Requirements Process (Robertson and Robertson)

Mentors

Organization environment

Organizational maturity

PDP. See Professional Development Program (PDP)

Performance reporting

Performance reviews. See also Skill and competency profile

Plan-driven approach. See also Q1 (quadrant

PM (Project Manager)

career development. See also Professional Development Program (PDP)

client wants and needs

co-PMs

defined

discretion allowed

dual-career path. See Dual-career-path model

generalists

historical perspective

integration into project landscape. See Integration of PM and BA into project landscape

landscape sector

misconceptions

one person with both PM and BA responsibility on same project

organizational placement

position landscape

professional development. See Professional Development Program (PDP)

and project planning

roles and responsibilities

separate PM or single PM/BA issue

skill set

skills and proficiencies. See Skill and competency profile

specialists

training courses

PM/BA

background

career development

career opportunities

and client involvement

co-PMs

curriculum

defined

dual role

extreme projects

focus of

job descriptions

job opportunities

landscape sector

long-term career planning

mapping into project landscape

and market environment

need for

notation

organizational support

overlap of PM and BA skills

position family. See also Position family

position landscape

professional development. See Professional Development Program (PDP)

role of

sectors mixing disciplines, range of

short-term career planning

skill profile

PM/ba

design projects

incremental TPM projects (Q1)

and integration of PM and BA

landscape sector

mapping into project landscape

and market environment

short-term career paths

and team size

PMBOK

PMLC. See Project management life cycle (PMLC)

Porter, Michael

POS. See Project Overview Statement (POS)

Position family

defined

dual-career-path model

landscape for PM and BA positions

organization placement of PM and BA positions

overview

as work in progress

Post-implementation audit

Practice Director

Problem definition

Problem solving

Problem/opportunity statement

Process design and improvement

PM and BA overlap

Q2 projects. See also Q2 (quadrant

Process Director

Process installation

Product installation

Professional Development Program (PDP)

about

British Computer Society

career goal, change in

career path, change in

experience acquisition

future prospects

and landscape for PMs and BAs

mentors

off-the-job training

on-the-job training

organizational support for

professional activities

and resource management

reviews

revising

self-assessment

skill and competency profile

and staffing supply and demand

tracking progress

Professional level positions

Associate Manager

BA positions

Consultant

generic

Managers

overview

PM positions

PM/BA and BA/PM sectors

Senior Consultant

Senior Managers

Proficiency. See also Skill and competency profile

assessment of

model

Project communications model

Project environment

Project failure

client involvement, lack of

and communications, lack of

and project approach

and project duration

and project portfolio

Q2 projects

Q3 projects

rates

research and development

and staffing issues

Project goal

Project landscape

complexity and uncertainty of project

integration of PM and BA. See Integration of PM and BA into project landscape

overview

and PMLC selection

project classification

and project management models

quadrant

quadrant

quadrant

quadrant

quadrants

Project management

agile project management. See Agile Project Management (APM)

best-fit approach

life cycle. See Project management life cycle (PMLC)

overview

plan-driven

traditional. See Traditional project management (TPM)

Project Management Body of Knowledge (PMBOK)

Project Management Institute (PMI)

Project management life cycle (PMLC)

acceptance test procedure (ATP)

BA, role of

BA responsibilities

change management

client maturity

client wants and needs

communications management. See also Communications management

complexity and uncertainty

conflict resolution

decision making

deliverables installation

historical background

models for Q2 projects

overview

performance reporting

PM, role of

PM responsibilities

post-implementation audit

problem definition

problem solving

project communications model

and project management

Project Overview Statement (POS)

project plan

and project size

projects

requirements breakdown structure (RBS)

requirements change requests

requirements elicitation

risk management

selection. See also Project landscape

solution validation

staffing issues

team meetings

team operating rules

work breakdown structure

Project Management Office (PMO). See also Director of Project Management

Project Manager Competency Development Framework,

Project Manager (PM). See PM (Project Manager)

The Project Manager's Desk Reference (Lewis)

Project objectives

Project Overview Statement (POS)

Project planning. See also Work breakdown structure (WBS)

Project portfolio

management

and project failure

staffing requirements

Project scope

Project selection

Graham-Englund Project Selection Model

and staffing requirements

Project size

Project success

Project team. See also Staffing

availability

cohesion

co-location

conflict resolution

meetings

operating rules

Q1 projects

Q2 projects

Q3 projects

Q4 projects

size

structure

Q1 (quadrant

Q2 (quadrant

co-PMs

Q3 (quadrant

Q4 (quadrant

Quality assurance (QA) managers

Rational Unified Process (RUP)

RBS. See Requirements breakdown structure (RBS)

Requirements breakdown structure (RBS)

Requirements by Collaboration: Workshop for Defining Needs (Gottesdiener)

Requirements elicitation and management

and agile projects

BA's role

centralized

change requests

conflict resolution

consultants, use of

outsourcing

PM and BA overlap

process

and project communications

and project failures

project scoping phase

requirements breakdown structure (RBS)

requirements documentation

shuttle diplomacy

Requirements specification document

Research and development (R&D) projects

Resource management

Resource planning

Return on investment (ROI)

Risk

assessment

and business analysis maturity level

categories

identification

management

mitigation

monitoring and control

as part of POS

Q1 projects

Q2 projects

Q3 projects

Q4

Q4 projects

and staff availability

and technology

Robertson, James

Robertson, Suzanne

Root cause analysis

RUP. See Rational Unified Process (RUP)

Sayles, Leonard R.

Scope. See Project scope

Scrum

SDLC. See Systems development life cycle (SDLC)

Senior Business Analysis Consultant/Architect

Senior Business Analyst

Senior Consultant

Senior Consultant/Architect

Senior Managers

Seven Steps to Mastering Business Analysis (Carkenord)

Short-term career planning

career path examples

PM/BA

Professional Development Program (PDP)

Skill and competency profile

assessment approach

and career paths

matrices for position levels

overview

PM and BA overlap

and position levels

Professional Development Plan

proficiency model

and project portfolio management

and resource management

and resource planning

skill assessment

skill gap, calculating

and training

Skill set

PM/BA skill profile

PMs and BAs

SMART format for goals and objectives

SME. See Subject matter experts (SMEs)

Software Engineering Institute Capability Maturity Model

Solution validation

Staff level positions

BA positions

generic

PM positions

PM/BA and BA/PM sectors

Staffing. See also Project team

algorithm

assignments

availability

choices

contractors

environments, impact of

gap analysis

gap resolution

integration of PM and BA roles. See Integration of PM and BA into project landscape

issues

and project complexity and uncertainty

and project scoping phase

Q1 projects

Q2 projects

Q3 projects

Q4 projects

and skill/proficiency requests

staff environment

supply and demand

trends

Standish Group

Strengths and weaknesses of PM and BA integration

Subject matter experts (SMEs)

BA generalists

BA specialists

Business Analysis Consultant/Architect

and client maturity

and project complexity

and project environment

in projects without BAs

Q1 projects

Q3 projects

Q4 projects

Success criteria

Systems analysts

Systems development life cycle (SDLC)

Task Leaders

Taxonomy of Educational Objectives, Handbook 1: Cognitive Domain (Bloom)

Team. See Project team

Team leader

Team Members

Technology

and development of PM and BA positions

and risk

Time constraints

Traditional Project Management (TPM)

change requests

co-PMs

described

example projects

generalists and specialists, need for

incremental models

linear models

one person with BA and PM responsibilities on same project

and project landscape

Q1 projects

staffing

team organization

Training

courses

design, development and scheduling

developers

managers

off-the-job

on-the-job

PM/BA curriculum

and skill level proficiency

Unearthing Business Requirements: Elicitation Tools and Techniques (Hass and Hossenlopp)

Wal-Mart

Wants and needs

Waterfall model

WBS. See Work breakdown structure (WBS)

Wessels, Don

Work breakdown structure (WBS)