Praise for Wh. Project Management "I work with a wide range of entrepreneurs, small and mid-sized companies. The accelerated project management techniques in this book have consistently served my needs and interactions with my clients. LaBrosse really knows how to design information that is user friendly, quick to implement, and very cost effective. I have referred many of my clients to LaBrosse's material. If you need to get a whole project team moving fast, here is the solution." - Peter Newman, Marketing Edge Seattle, Washington "As-an IT and a Project Management Professional, I have worked on a fair number of e-business projects in the past 10 years. The case study presented in this book hit the nail on the head! This is the best way to quickly launch an e-commerce project. Michelle LaBrosse has written a great resource text for anyone who needs to manage projects fast in today's ever-changing technical environment. With a minimum of jargon, this book makes learning how to build and manage IT projects far easier than I've ever seen. This book is a keeper. Put it where you can find it!" - Peter McBride, PMF' Vancouver, BC, Canada "With the echniques in this book, I was able to rapidly bring a team to consensus on who needs to do what -and when. If you need to get things done at Internet speed (and who doesn't?), don't just read this book, make these techniques part of how you do your job." - Louisa Dickson, Programme Manager London, England I
"As a business owner, I am frequently working on many projects at once. Since implementing the methodologies outlined in Cheetah Project Management, I have more time to spend with my employees and my customers. Our new strengths include higher productivity levels, streamlined teamwork, and ultimately very happy customers!" - Debbie Zener, President 6 Owner, Emerald City Cafe 6 Catering Co. Reno, Nevada "Reading this book has changed the way I approach my work-for the better! With Cheetah's approach, my colleagues and I are now clearer about our responsibilities. The lines of communication have been opened, enabling us to work together more cohesively to get the project done. Even the customer has noticed a positive difference since we've implemented the Cheetah PM approach. I keep this book close by as a reference for each new project I undertake. I recommend you keep this book on your shelf, too." - Allan Geetter, Data Security Administrator, Information Technology Services, University of Hartford Hartford, Connecticut
"In my twenty year career in Information Technologies, I've seen as many ways of doing Project Management as I've seen changes in the speed of microprocessors. What I found with Cheetah Project Management is a technique that cuts to the chase and makes it fast and simple to do projects. In my world, it's not uncommon for projects to morph over and over as technology enhancements drive customers to want different features. By using the Cheetah Project Management methodology to complete our projects in less than three months, we avoid the problem of the never-ending project." - Bryne Parrott, President, Silver Back Servers Carson City, Nevada
PROJECT MANAGEMENT
PROJECT MANAGEMENT T h e Fastest Way to Reach Your Goals
MAKLAF PRESS
Carson City, NV
Cheetah Project Management by Michelle LaBrosse, PMP Published by MAKLAF Press LLC. 502 N. Division St., Carson City, NV 89703 A Division of MAKLAF Holding, Inc. www.cheetahlearning.com Copyright O 2006 by MAKLAF Press LLC. All rights reserved. Printed in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher. Notice: This publication contains the opinions and ideas of the author. It is intended to provide helpful and informative material on the subject matters covered. It is not meant to replace the advice of an attorney. The author and publisher specifically disclaim any responsibility for any liability, loss, or risk, personal or otherwise, which is incurred as a consequence, directly or indirectly, of the use andlor application of any of the contents of this book. Post-It@,Sharpie@and all other brand, product, service, and company names are trademarks of their respective holders. Reference to a product, service, or company does not imply recommendation, approval, affiliation, or sponsorship of that product, service, or company by either the authors or MAKLAF Press. MAKLAF Press books are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please write to the Director of Sales, MAKLAF Press, 502 N. Division Street, Carson City, NV 89703, or contact your local bookstore. Cover and interior design by Pneuma Books, LLC. Visit www.pneumabooks.com Cover photograph of Michelle LaBrosse by Phyllis Uitti-muslin Publisher's Cataloging-in-PublicationData (Prepared by The Donohue Group, Inc.) LaBrosse, Michelle. Cheetah project management : the fastest way to reach your goals I Michelle LaBrosse. p. : ill. ; cm. - (Cheetah success series ; Book 1) ISBN-13: 978-0-9761749-5-0 ISBN-10: 0-9761749-5-2 ISBN-13: 978-0-9761749-6-7 (pbk.) ISBN- 10: 0-9761749-6-0 (pbk.) Includes index. Cheetah success series developed by Cheetah Learning. "Cheetah Project Management... follows the Project Management Body of Knowledge (PMBOK)" 1. Project management-Handbooks, manuals, etc. I. Cheetah Learning. II. Title. III.Title: Project management body of knowledge (PMBOK)
For my entire staffat Cheetah Learning and our associated entities. You have followed the principles outlined in Cheetah Project Management with unwavering dedication. Thank you for your belief in my vision and for what we are creating together.
Contents Preface
. . :....................................... ~ ... 111
Chapter 1.The Cheetah Way: Speed and Efficiency . . . . . . 1 What Is the Cheetah Approach? . . . . . . . . . . . . . . . . . . . . . 3 The Project Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 One .Step at a Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Relax and Have Fun ............................... 8
.Facilitation: Setting the Stage . . . . . . . . . . . . . 1 1
Chapter 2
Selecting the Project Team . . . . . . . . . . . . . . . . . . . . . . . . . 12 Serving as a Leader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Pre-event Preparations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Running the Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 3.The Project Agreement: Ready...Set...Launch! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Five Areas of Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Risk Tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Project Team Member Responsibilities. . . . . . . . . . . . . . . . 56 Project Agreement Template . . . . . . . . . . . . . . . . . . . . . . . 57 Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
.
Chapter 4 Teaming: Pulling Together ............... - 6 7 Self-interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Ground Rules for Teamwork ....................... 75
.-.*....
. . & --x? e +- : *
...
>A.
..'.
:
. .- .
.
> -r
Tale of Contents
ix
Weathering Changes and Conflict Resolution . . . . . . . . . . 83 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 .
.
Chapter 5 Project Planning: Bringing Your Ideas to Fruition . . . . . . . . . . . . . . . . . . . . . . 93 Assembling Your Information . . . . . . . . . . . . . . . . . . . . . .94 Project Planning Approaches . . . . . . . . . . . . . . . . . . . ;. . . 96 Project Planning Step 1: Identifying High-Level Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . 97 Project Planning Step 2: Identifying Interim Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Project Planning Alternative: Bottom-Up Planning . . . . . 102 Project Planning Step 3: Processes . . . . . . . . . . . . . . . . . . 108 Project Planning Step 4: Conflicts . . . . . . . . . . . . . . . . . . 112 Project Planning Step 5: The Tree Diagram . . . . . . . . . . . 113 Project Planning Step 6: Milestone Reviews . . . . . . . . . . 113 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
.
Chapter 6 Project Risks: What Could Go Wrong? . . . . . 121 Identifying the Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Quantifying. or Calculating. the Risks . . . . . . . . . . . . . . . 123 Developing Countermeasures . . . . . . . . . . . . . . . . . . . . .128 Assigning Responsibility for Risk Countermeasures . . . . 133 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Chapter 7.Scheduling: You Want It WHEN? . . . . . . . . . . 137 Milestones Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Deliverables Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Activity Tasks Schedule . . . . . . . . . . . . . . . . . . . . . . . . . .142 Computer-Based project planning Tools . . . . . . . . . . . . . 151 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
v-...e..
,....re=.--.
x
PROJECT MANAGEMENT
. -9 " -....--.
.... *IErr*w
4
.
.... 153 Labor Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 ExternallMaterial Costs .......................... 158 CashFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Aligning Your Budget and Your Spending Limit . . . . . . . 162 Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Chapter 8 Budgeting: Money Changes Everything
.
Chapter 9 Tracking the Project: Ensuring a Fast Project Stays Fast . . . . . . . . . . . . . . . . . . . 167 Projectchanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Project Status Reports and Performance Tracking . . . . . . 171 Project Decelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Rules of the Road to Accelerate Projects .............183
Chapter 10.Lessons Learned . . . . . . . . . . . . . . . . . . . . . -187 Collecting Lessons Learned Data Throughout the Project ........................ 188 Collecting Lessons Learned Data at the End of the Project . . . . . . . . . . . . . . . . . . . . . . . 189
.
Appendix The Completed Project Agreement
....... 199
Index
.......................................... 217
.
..v*pe
5 -.-
m -
.............
-;S,~^,~=*----=*=I~.~
Table of Contents
Preface
P
roject management has grown into a complex field, with literally thousands of computer-based tools and just as many methods. Organizations can have as many ways of doing project management as they have professionals engaged in its practice. Too often the results are chaotic. I created the technique I now call Cheetah project management from my experiences with project disaster recovery and launching new projects. My goal - both with this book and the courses I teach - is to provide project teams and project leaders with a simple, fast, and effective project management method that can be used by both experienced and inexperienced project team members. It's a method that they can use either to fix a hemorrhaging project or launch a new project. This book is a practical how-to guide for a fast project management method that has worked for me and for the hundreds of people I have worked
with over the past 15 years, in a wide range of industries and occupations. Many project teams do not undertake the necessary activities for project management because experience tells them that those activities cost a lot of time and deliver little in return. Cheetah project management was created for today's fast-paced environment to give project teams a quick, simple, reliable, and cost-effective way of coming to consensus on customer requirements, project scope, project schedules, and project budgets. Cheetah project management enables individuals and entire project teams to rapidly launch their projects, initiatives, and ideas. Once a project team (ideally three to seven people) is'familiar with Cheetah project management, it can typically complete the entire process of scoping, planning, scheduling, and budgeting in less than half a day. Cheetah's Accelerated Project Management process quickly brings teams to consensus on the following issues: the customer's requirements, schedule (who needs to do what and when) to complete the project, each individual's roles and responsibilities, the timing of critical milestones of the project, accurate cost estimates, and a clear picture of cash flow needs for labor and external costs. I wrote this book because I want to see teams and organizations succeed. Fast and efficient project management is the ticket to organizational growth and success. Project managers and project team members, facilities managers, facilitators, and those involved in organizational change will find this book to be an invaluable resource. It might just work for you too.
- Michelle LaBrosse, PMP
d& PROJ
Many people helped with the revision of Cheetah Project Management. I would like to thank my editor, Alexis Bohan, who worked diligently with the publishing company to update the manuscript. I also would like to thank Barbara McClintick and Pam Peacock for their sage advice in updating techniques for smoother facilitation and implementation. Additionally, I would like to thank the many people who are now practicing Cheetah project management and achieving their own outstanding results.
The Cheetah Way: Speed and Efficiency
7-
his book is a how-to guide for a quick method of implementing project disaster recovery with a project re-launch. 0 It is also designed for people who are interested in kicking off a project the right way from the beginning. But most people are initially motivated to use these techniques as an emergency firstaid fix for an ailing project. Once they have saved a project from imminent disaster, however, they find that they can use the same method to successfully launch their next project. Each chapter in this book presents detailed, step-by-step instructions about how to organize a project team using Cheetah's Accelerated Project Management methodology. The book takes the reader through the complete Cheetah Accelerated Project Management process, covering its implementation and advantages. Project team activities and a case study showing how the technique can be applied to an e-commerce project demonstrate how to do the following:
* * *
* *
Set up a project charter so that the project team members start off on the same page with their expectations about the project and their anticipated contribution toward the project completion. Develop teaming relationships that prevent destructive conflict from derailing the project performance. Decide on team responsibilities and time availability/commitments. Establish interim deliverables with measurable acceptance criteria. Identify processes external to the project team with which the project team must comply to create the interim deliverable~. Define conflicts that could impact the performance of the project. Summarize the deliverables each team member must create for the successful completion of the project. Identify the critical review points and milestones of the project. Assess and quantify risks in creating the interim deliverables. Establish the dependencies and timing among the deliverables and assess the critical path. Define the tasks needed to create the interim deliverables. Do a three-point estimate to determine the high, medium, and low confidence estimate for completing the tasks on schedule. Create an activity task schedule with a method that allows for "crashing" the project to finish by the due date. Plan for labor and external cost budgets with a fast way to establish project cash flow needs. Track a project's performance using computer and Internetbased project-tracking tools.
JEGT MAMj
Help team members communicate with each other and the project stakeholder on project performance. Document lessons learned for applications on future projects.
WHAT IS THE CHEETAH APPROACH? Maybe you have heard the term accelerated project management somewhere but do not know exactly what it means. Maybe you think you know what it means but are not absolutely sure. Let's start with a working definition. Cheetah's Accelerated Project Management (APM): Using accelerated learning to accelerate projects with a process that covers the complete framework for individuals and project teams to quickly launch projects, initiatives, and ideas. Cheetah's Project Management Methodology was first treated for project disaster recovery - to quickly put a failing, floundering project team back on track. It has since become a technique to launch projects in today's fast-paced environment. The approach was created for project teams who need a fast way of coming to a consensus on customer requirements, project scope, project schedules, and project budgets simply and reliably. An alarmingly high percentage of all product failures are attributed to poor project management. Many project teams do not take the necessary steps for project management in earnest, because they believe that to do so would be time consuming. However, dealing with the consequences of a project that has become bogged down, gone astray, or otherwise failed can ultimately prove to be far more time consuming - and expensive. Proper project management helps avoid these problems. The streamlined approach of Cheetah's Accelerated Project Management offers the bonus of helping you to achieve your project management goals quickly. The advantage is clear to any organization interested in the efficiency of its project teams. Accelerated project management is particularly valuable when the nature of the project requires a -..,,
. +--.
?-=
.-,5--
--
.--< -.--=-
OM
--
. ___l__,-=---
-----.-...--.
------7.-
wetah Way: Speed and Efficient
...
project team to deliver quickly; for example, to bring a product to market ahead of the competition.
THE PROJECT TEAM A project team is usually made up of three to seven people. The team should include a project sponsor, a project launch facilitator, and the other necessary team members. Let's take a snapshot of their roles: 1. Project sponsor: Sets the tone with the project mandate, including the approval for the resources needed to complete the project 2. Project launch facilitator: Implements the pre-event preparation and guides the team through the APM technique 3. Project team members: Provide the commitment for doing what it takes to launch and execute the project wically, once the team is assembled, its first tasks are to complete the process of project scope, planning, scheduling, and budgeting. You may have experienced situations where this process is so divisive and protracted that the project cannot even get off the ground. Cheetah's Accelerated Project Management enables a project team to reach consensus in less than a day on the following: Customer requirements Who needs to do what and when Each individual's role and responsibility The timing of critical milestones of the project Accurate cost estimates A clear picture of cash flow needs for labor and external costs
ONE STEP AT A TIME This book provides step-by-step instructions on how you can work with your team to use the powerful technique of visual fa-
f
i f I The ~eight components of Cheetah's Accelerated Project Management framework Project
aunch ilitation Projed Agreeme
ions
aecl
/
StalIj
anc
Planning .
. .
Risks
/
cilitation, the cornerstone of Cheetah's Accelerated Project Management method. This technique is woven throughout the book, guiding you through a case study of an e-commerce project. Figure 1.1 shows the eight components of Cheetah's Accelerated Project Management framework. The key to success with Cheetah's Accelerated Project Management is the participation of everyone on the project team. By setting and measuring the time it takes to complete the activities during a project launch, you can
P-
The GI
keep the project moving quickly so that a fast project stays fast. You can also set the stage for future project tracking. The figure also shows that you can build your projects from the lessons you have learned from previous projects. By creating a template based on what you have learned from managing your own projects, you can get your projects to work more quickly and effectively. And by customizing and streamlining your own strategies, you will find that you can launch and manage your projects with ease. Before you attempt to act as a facilitator on any project you should first go through all the APM steps yourself. The project you complete should lie solely within your own circle of influence one for which you are the project sponsor and a project team member. It's essential to run through all the steps of APM on your own project before you attempt to lead a team of people through the process. Invite two trusted colleagues to go through a rehearsal with you on a small project. You might also consider taking the Cheetah Project Management course offered through Cheetah Learning (www.cheetah1earning.com). This step-by-step approach, complete with examples that demonstrate how a project team works through a project together, shows how to do the following: Organize and facilitate a project launch event that involves everyone on the project team Set up a project agreement so that everyone on the project team starts off on the same page with the same expectations of the project, as well as an understanding of their anticipated contribution toward the project completion Develop teaming relationships that prevent conflict from derailing the project performance
lECT MANA
Decide on team responsibilities and time availability/commitments Develop a plan with each team member's final deliverable for the project each team member's interim deliverables with measurable acceptance criteria identified processes that are external to the project team and that must be complied with in order to create the interim deliverables a definition of conflicts that could impact the performance of the project a summary of the deliverables that each team member needs to create for the ultimate success of the project an identification of the critical review points and milestones of the project an assessment and a total count of the risks involved in creating the interim deliverables Create schedules that - establish the milestone timeline set the interim deliverable completion regarding the milestone timeline identify the dependencies and the timing between the interim deliverables and assess the critical path or the earliest completion date of the project define the tasks needed to create the interim deliverables - determine the estimate for completing the tasks by ranking them as high, medium,or low - include an activity task schedule with a method that allows for crashing the project, to be finished by the due date
-
......
-,.-
" , -v w -'-
Om
.--
-
,.
d--,-
--.a
>:-----
'.
.
---7
-
keetah Way: Speed and Efficiency
.-:
--L
7
I
Plan for labor and external cost budgets with a fast way to establish project cash-flow needs Track a project's performance with a simple method to calculate the cost and the schedule Facilitate communication among other team members and with the project stakeholder on project performance Document lessons learned to use for future projects If you follow the steps in order, you will provide yourself with a process that focuses on teamwork and covers all the bases by addressing issues as they arise. Remain flexible during your project, and you will be prepared for the unexpected - because the one thing we know about the unexpected is that it's inevitable.
R E W AND HAVE FUN The process you go through when working with your team to complete a project should be enlightening and rich with ideas. You can have fun with your projects by establishing an open and flexible environment, perfect for the proliferation of ideas and teamwork. You will find that your team will take this new methodology and use it to its advantage by coming up with strategic and innovative ways for completing any project that comes along. The more you can make use of this method, the faster and more effective you will become with your projects. Remember to take each process as a learning experience, and enjoy!
Facilitation: Setting the Stage
7-
his chapter covers how to set the stage so that you can use Cheetah's Accelerated Project Management (APM) technique to complete a project launch with a team in four to eight hours. It provides recommendations for selecting a team, project launch pre-event preparation guidelines, and advice for keeping things moving during the project planning session. It also helps you see how you can prevent and resolve conflicts during an event. The facilitation techniques are based on experiences using this methodology in a variety of settings. As you study Cheetah's APM launch activities in this chapter, keep in mind that they are not just exercises to speculate on various courses of action or to provide recommendations to a committee regarding how to complete a project. These activities are designed to actually launch a project - in other words, to get something done. Let's get to work.
7%&2?1 Characteristics and skills to focus on when selecting project team members
paced, fast-changing environment
at may be outside the bound-
-
A willingness to teach themselves the skills needed to do the project tasks The ability to maintain a balance between taking action and analyzing and collecting information to ensure that the ac-
SELECTING THE PROJECT TEAM Once the facilitator is prepared to do the work to run the project launch event, the project team members must be selected, first based on their attitude, and second on their capabilities. Putting together the right team is critical for success. In more formal initiatives, the project sponsor selects the project team leader, who puts together the project team. For informal, ad hoc projects, sometimes the project team leader finds a sponsor for the project first, and then puts together the project team. To ensure peak performance in APM, the project team leader must first identify the broad range of skills needed to complete the project and then select three to seven project team members with the characteristics shown in table 2.1. Some
characteristics are crucial; while others are important or merely desirable. The project sponsor, facilitator, and team members all have to be equipped with a winning, go-for-it attitude. Unfortunately, in many of today's work environments, there is often more than one cynic who questions the motivations of management, downplays the aptitude and attitude of skilled technical people working together to accomplish a goal, and lacks the focus to spend a day correctly planning a project. Take comfort in knowing that it was precisely this type of environment in which Cheetah APM was perfected. Cynics feel ineffective because they are too focused on the things they cannot affect. APM can temper the negative influence of the cynic because it focuses on the circle of influence. Starting a project with a positive, can-do attitude is the first step in being successful with Cheetah APM.
SERVING AS A LEADER Once the project sponsor gives the go-ahead in writing for moving forward with the project, the project launch facilitator sets the stage for success. The facilitator's primary responsibility is to ensure that the project team gets the project launched in one session. The facilitator is responsible for completing the pre-event preparation required for the project launch session. During the session, the facilitator leads the team in the following tasks: Developing the project agreement Setting the team rules for working together Coming up with the seven project planning steps, which includes doing a risk assessment and quantification Creating the project schedules Estimating the project staffing and budget requirements Preparing for the project launch event can be intensive. The first few times a facilitator prepares an event, he or she may need to -+.---*7-
1
.
.
'h-.
yT=-. , = ~ * ,.eF--
-~,/-,---:--C
ion: Setting the Stag1
6 -
9I Attitudes needed for accelerated project management
Project *am Members . Participate with positive can-do attitude and commitment to do the project
I't4(7X7
clcar m for Jt +l,n , -
spend as much as five hours of preparation time for every one hour of facilitation time. A more experienced APM facilitator will typically spend up one hour (or less) of preparation time per hour of event time. Preparation time depends on the nature of the project, the dynamics of the project team, and the amount of experience the project team has with APM. There is significant payback for adequately preparing for a project launch session. Quite simply, the preparation will allow the team to focus on creating realistic project plans, schedules, and budgets -precisely what it should be focusing on. What you don't want is for the team to split its attention between the project launch process and the project
--TF7. I d
-;--..-
-'--=----
--
#& PRO,IEGT MAMA
--
launch itself. Adequate preparation by the facilitator will prevent such a situation. The attitude and capabilities of the facilitator are a critical ingredient for a successful project launch. With proper preparation for the intense work necessary to launch a project in a day or less, the project team can increase its chances of planning a project that will be successfully completed on time and in budget.
PRE-EVENT PREPARATIONS The facilitator's responsibilities for the pre-event preparations include the following: Ensuring that the basic needs of the participants, or team members, are ,met throughout the event Setting the agenda -Arranging for the project planning room Collecting all the supplies needed Learning how to take a team through each stage of the accelerated project launch technique In preparation for the actual session, it's also a good idea to develop an initial project agreement and an estimate of the major deliverables needed, so that you know where the roadblocks are likely to arise during the session. (See chapter 3 for a discussion of the project agreement.) Let's take a closer look at arrangements and plans the facilitator must take care of before the launch event.
Briefing Materials Project team members need to be clued in ahead of time, in writing, regarding the agenda of the launch event, the expectations for their participation, and the desired outcome of their participation. If team members do not feel prepared for any reason
--.
.-.
-_-2_
-- -
-
--.
7%
&+--
- Facilitation: Setting the Stag1
d
during the laulich event, their participation and contribution will decrease significantly. Briefing materials should also include the launch event guidelines. Team members must agree to these guidelines before the session begins. Typical guidelines are: Show up on time Bring your labor rate information for budget calculations Stick to the agenda Do not use cellular or other phones, pagers, or e-mail while in the launch-planning session Offer only constructive suggestions Contribute - and recognize that silence implies consent Understand that if it is not written down, it is not agreed to Do not engage in side conversations Cooperate with the facilitator to finish the planning session within the allotted time Have the team members sign off on these guidelines and return them the day before the meeting. Of course, you know the common pitfalls that occur in your organization; be sure to tailor the guidelines appropriately to help ensure a smooth launch event.
Refreshments and Breaks Basic, fresh finger food, as well as water, coffee, tea, soft drinks, and juice should be freely available in the project planning room throughout the session, at no cost to the team members. If project team members are hungry, they will be thinking about when they can eat rather than focusing on getting the project launched. If refreshments are difficult to obtain - requiring trips to the cafeteria or a hunt for change for vending machines - the team will be distracted from the job at hand: to quickly launch a new project. Some companies have restrictions about providing free food at in-house planning meetings. If this is the case, have all
the project team members and the project sponsor contribute money for the cost of the food so it can be purchased and brought in ahead of the session so that this basic need is addressed before the meeting. There must be adequate time for the team members to stretch and use the restroom throughout the session. The rule of thumb is a five- to ten-minute break every hour. This should be discussed ahead of time, ideally with the agreement that the team members will not use the breaks to return phone calls or get sidetracked in conversations.
Project Launch Room To do an accelerated project launch, the room has to have approximately 60 linear feet of free wall space where the project team can work for the duration of the project. Organizations that place a high importance on completing projects on time and in budget will have dedicated such a room to the project team. In many companies, this is referred to as the "war room." If you cannot secure this type of workspace for your accelerated project team, hold your project launch event where the team members can work without being disturbed and without disturbing others. Lighting and ventilation should promote comfort, and there should be a clock in the room. If this type of space is not available in your facility, then rent a conference facility at an external location for the session. The facilitator must preview the facility ahead of time to ensure that it has enough free wall space and is adequate for the necessary facilitation activities.
Setting the Project Launch Event Agenda One week prior to the project launch event, the facilitator creates and distributes the project launch event agenda. This agenda specifies the tasks, timing, and goal for each stage of the project launch event (see figure 2.2).
_*-
_--_- . -_-_____ ---_r_r--'-=-
+----
wm,.--..
- Y L - . w
7 & ~- Facilitation: Setting the Stagc
-2
f i g m 2.2Cheetah APM Project Launch Event Agenda Location:
Date:
Start-End Time:
-
continued on p. 19...
To ensure that each team member has seen the agenda and agrees to participate in the launch session as detailed in the agenda, the facilitator should request each team member to confirm their agreement by e-mail or return an initialed copy of the agenda at least 24 hours before the launch event. For the accelerated project launch event to go smoothly, it is critical that each person participating in the session understand the intensity of the event as outlined in the agenda and be prepared to participate.
Supplies for a Cheetah APM Launch Session Cheetah APM uses a visual technique to quickly create the project outline, plan, schedule, and budget. To use this technique, the facilitator must have an APM facilitation kit, which should include: Wall templates for the project agreement, plan, schedule, and budget Sturdy mounting tape Post-its (three-by-three-inch adhesive pads, 100 sheets per pad), one color for each team member or deliverables category
&ah PRO
f i y w 2.2 Cheetah APM Project Launch Event Agenda (continued)
F" (From-To)
1 .Project
Scope the project
Project team leader
Agree on how we will work together
Facilitator
agreement 2.Setting team rules . steps 1-6
1 assign to team members; 1 members 1identify external processes I to create deliverables; identify conflicts and reviews Assess and quantify project Project team risks members
4.Project risks
5.Project milestone Develop timeline for major Project team project deliverables members schedule
1
1
6.Project deliverSet timing for project deliv- Project team able and depend- erables based on milestones members ency schedule and dependencies 7. Activity task schedules and task time estimates
Identify tasks to create each Project team deliverable with time esti- members mate and confidence rating for doing tasks
8.External cost estimates
Estimate external resources Project team and costs to create project members deliverables
9.Project cash flow analysis availability 10. Set agenda for Develop the agenda based Project team first project statu on what was decided in the leader report meeting launch session 11.Launch event lessons learned
Evaluate what worked well Project and what needs to be im- facilitator proved with APM launch sessions
.. - =<.
-+--
-<-
-..-
-.
-~---.--.
Facilitation: Setting the Stage
.r-??
'-7
Removable adhesive dots in four separate colors (used for risk quantification) Erasable whiteboard Paper Color-coded markers Black, medium-tip Sharpie markers Red pens A facilitator's tool belt for keeping all the facilitation supplies readily available and organized A quick Cheetah APM project launch reference guide (this book) for each project team member The right tools make all the difference during a project launch event. Time invested in gathering everything you need beforehand will save valuable time during the launch event.
RUNNING THE EVENT The more thorough the facilitator's pre-event preparations, the less likely the launch session will get bogged down in project definition details. One of the prime reasons that project planning sessions get derailed and take so long is that the project teams spend too much time working on the project process instead of the project plan. With a well-trained and practiced facilitator, the project team members can focus on developing the project details. Two key elements in Cheetah APM will help keep the session moving and the project team members on task: timing and process.
Timing Everything is timed during an APM launch session. It is not only up to the facilitator, but also up to each team member to closely monitor the clock and move things along during the session. This is one reason why it is so important to have team members confirm their agreement to the agenda.
Process The second element that keeps the launch session moving is the process. There are questions that the project team members have to answer, and answer quickly, to complete each step of the Cheetah APM project launch process. The timing element ensures that the project team answers the questions to the best of its abilities, and then moves on. Typically, project members can become very speedy going through this process after doing it several times. But the same basic questions must be answered for every single project because while the questions are the same for every project, the answers are not. Following the same process for project launches every time, and in a standard sequence, prepares the mind for the speed needed when setting up project plans, schedules, and budgets. Following a standard process also produces more consistent project results.
Anticipating and Handling Conflict There are times when the project team dynamics do not work well with APM. There may be instances when there are numerous disagreements regarding the scope of the project, the assignment of deliverable responsibilities, or the allocation of budgetary resources. At these times, it is up to the project sponsor to set a clear mandate regarding the project scope, the availability of funds, and the formal roles and responsibilities of the team members based on their job descriptions. If the poor team dynamics arise from the perception of a lack of management support, then it is crucial that the project sponsor participate in the APM launch session. The good news is that the initial APM launch pre-event preparations minimize the probability of conflict during the session. Conflict happens when people have differentexpectations. When individuals are not aware of their own expectations, they see conflict as something that happens because of someone else. The preevent preparations are designed to clearly and explicitly articulate
ion: Settin[g the Stage
the participants' expectations, thereby minimizing conflict during the session. It is critical that the APM launch participants agree to the guidelines for participating and also agree to the 'agenda. Note than an agenda refers merely to the timing of the APM launch process (see figure 2.2); it does not specify the details of the project plan. If destructive conflict occurs during the session, it is usually because the participants have different expectations about what should be happening and are dissatisfied that their needs have not been met. The guidelines to which the participants agree before the session should clearly state how they will communicate with each other, and how they will participate in the session. The role of the facilitator is to bring the group back to the original set of guidelines and the original agenda if they get off track. The participants can create new guidelines that are more in accordance with their expectations and their needs. Or they can recommit to the existing guidelines, resolving the conflict in accordance with the guidelines established before the event.
The Project Agreement:
Ready. ..Set ...Launch!
N
ow that you are ready to start your event, you can begin to create the project agreement. This is a combined effort, created by everyone involved in the project. The project agreement kicks off the project to a roaring start. It is a crucial part of Cheetah APM because it requires the project team and sponsor to agree on the major details of the project, thereby preventing any time-delaying disagreements that might crop up later on. As explained in chapter 2, an experienced facilitator leads the project team through the creation of the project agreement document. The more times you go through the project agreement creation process, the faster you become at hashing out the details that are needed to successfully launch your project. The aim of using a standard template for creating the project agreement is to make sure that all the major issues of launching the project are covered.
This chapter gives you a standard project agreement template with an example created for an e-commerce project. This example is revisited at the end of each project agreement topic description and is summarized in the appendix. Cheetah Learning has customized the project agreement template for a variety of project types and company practices. The chapter also covers project team members' responsibilities and communication among team members and discusses possible constraints for a project.
FIVE AREAS OF DISCOVERY The project agreement covers five major areas of discovery: Project scope: The goals of the project from the perspective of the customer and the organization Communication: How team members will keep each other informed of project progress and who needs to review the progression of the project at what milestone points Risk tolerance: How important the project is to team members and the project sponsor and the level of commitment they display when attempting to overcome the risks they encounter Constraints: The money, people, equipment, and time allocations necessary to complete the project Team member responsibilities: A record of each individual's role and the estimated time commitment for the project Acting as a guide, the project launch facilitator helps the team create its project agreement - normally in a one- to two-hour session. The exercise involves having the team make decisions about the project agreement, which is then re-created as a poster-sized visual aid and taped to the wall. The team makes its own decisions for each section of the project agreement and records them on Post-it Notes. After the event, all the information collected on the wall template is recorded in an electronic document. Often the
IJECT MAN
project leader will create a draft of the project agreement prior to the launch event. Each stage in the process of completing a project plan relies on information that was collected previously. When the project team decides to change information that was recorded in an earlier stage of the process, it has to look at how that change will affect all the other decisions that were made up to that point. This prevents project scope creep, or incremental changes to the project scope, from occurring later on - a phenomenon that could potentially derail the project.
PROJECT SCOPE There are six elements of project scope covered in the project agreement: Project identity information: The title of the project, the person creating the project agreement, the date the project agreement is created, and the project sponsor (the person authorizing the project to its completion). Project objective: The final deliverable(s) of the project. Project boundaries: When the project team will start its work and when the project will be complete. Customer definition: The people who will be concerned with the final deliverable(s),the current problems the final deliverable(s) will help them solve, the specific requirements, and the criteria for their acceptance. Business case: The strategic reasons for completing the project from the perspective of the overall value to the organization. It looks at the specific knowledge that is gained by having this group of people work on this project, the value of this knowledge, the strategic importance regarding other projects being considered by the organization, and the impact on the organization's markets. Project priorities: The various constituents involved in the ,., ,.,--,:,7-e
-,<-
-&.
*e.3?~..., ,....... ..rT-rrrr:i"-..!-.r<-" ?r%t*=?==~T+~ w - Thc!Project Atgreement: Ready SI Launcl ,..+3
... $...
->
project - sponsor, stakeholders, customers, project manager, and project team members - identify their priorities with the project. Let's look at each of the elements of project scope in more detail.
Project Identity You will find that every project needs to have certain information listed right up front. This is called the project identity. By completing information on project identity, everyone knows exactly what is going on, who is doing what, when the project started, and who is sponsoring the project. Every project must have a sponsor -someone who is paying for and authorizing the project. While a project team can create a project agreement, without a project sponsor it will not have the funding or the go-ahead required to complete the project. Here is a n example of the project identity information filled in for a n e-commerce project. (The entire project agreement for this case history is reproduced in the appendix.)
PROJEGf AGREEMENT Project Title: e-Commerce Project Today's Date: June 9, 2002 Person Recording Agreement: Alice Persons Creating Agreement: Alice, Bruce, Chris,, Debra, Ed Project Sponsor: Pat C. Eeo
Project Objective The project objective is just what it sounds like: a clear one- or twosentence statement that conveys the final desired outcome, or ob.
"&.:Y--.---
2P
-.
fk& PROJECT MANAI
'----
-
-
'
-
""..-'..--
* -4
jective, for the project. This is also called the final deliverable. One sure sign of poor project management is a project objective that changes throughout the life of the project. If the project objective changes, the entire project changes, It is no longer the same project, which in turn means that a new project agreement, schedule, and project plan need to be developed. If your goal is to create your final deliverable as fast as possible, do not change your objective after you have completed your project planning event. Project objectives can change for all kinds of reasons. Most commonly, perhaps, the objectives change if the basic concepts of the project change: for example, customer requirements, differing resources needed to complete the project, new threats from competitors, or the inability to get materials from suppliers. To prevent the need to change the project objective when external conditions change, do not make the objective too general or vague. While doing so may speed up the project planning stage, it will slow down the project. Instead, create tight, well-defined project objectives and do not change them after you have completed the APM launch event. In the early 1960s John F. Kennedy set a well-defined project objective when he defined the project objective of the United States space program. It was so well defined that even to this day many people remember it. The objective was to get a man to the moon and back by the end of the decade. The goal was not changed to "establish a colony on the moon" or "go to the moon and then on to Mars." The goal did not change. It was not too vague (explore travel to the moon); it was not too specific (we will use a rocket with solid propellant fuel to launch a space shuttle vehicle that has equipment to drive around the moon and make parachute reentry into the ocean) - and the American people succeeded. Accelerating projects requires that you set concise project objectives with clarity and a commitment to follow through.
"---.
,*-::.. ..-- ,..,.,*-v=--.,%:., , ., .. ie Prqject Aghemsnt: deady*.. Set.. Launc ,
. . . . . . . . I .
<
~
. , ,
~..T.
To give you an idea of what goes into a good project agreement, here is the e-commerce project's project objective.
Pl0JEGsf OBJECPt'blE(SEE 1.1) The final deliverable will be a website that our customers can use to order our products and to submit requests for quotes for specialized products and services.
Project Boundaries Project boundaries specifically state where the project team begins its work and what signifies the end of the project. The definition of the project boundaries helps the project team make sure that it has the necessary factors, or inputs, to start the project. This definition also helps give the team a clear idea of what will signify the project's success. Projects can generally move faster when there are tighter project boundaries that are relatively short in duration and not too complex. The team members of the e-commerce project set boundaries by defining when their job starts and when it should be finished.
PPWEGT BOUNDARIES(SEE 1.2) The project team starts with examining the existing website, including the existing order-fulfillment system and financial systems, and ends with reviewing the customer surveys from the newly launched ecommerce website.
Customer Definition You must determine the identity of your customer, or the person(s) ,
------ -.---
3c
r-=-.--,.
f& PROJECT MAMA(
y- ~
-
~
~
4
-.
-
-
- -..-. .-
- -~
~
-
~
who are affected by the final deliverable, by creating a customer definition. This definition should answer the following questions: Who is going to make use of the final deliverable? What problems do the customers have that the final deliverable will help them to solve? What are the customer requirements? What are the acceptance criteria for the final deliverable?
Project Customer The project customers are the people who are going to make use of the project's final deliverable. This is the section where you identify the various customers who will use the final deliverable. You also need to identlfy each of the customers' needs, requirements, and acceptance criteria. Employees of the company and members of the project team may also be customers of the project's final deliverable. Project customers who are outside of the company are called external customers; customers who are inside the company are internal customers. If you are not sure who will ultimately be using the project's final deliverable, you should seriously consider if there is a need to complete the project. As in the project objective, the more you know about the people who will use your final deliverable, the easier and faster you can define their needs, requirements, and acceptance criteria. Let's look at the way the e-commerce project team defined its customers.
PWOSEGT GUSOMERS (SEE 1.3A)
External Customers: The people who buy our products and services Internal CustomersIStakeholders: Sales and marketing staff, order-fulfillment staff
3 Project
A,
Customer Needs The customer needs section defines the customers' problems that the project's final deliverable will help them solve. The statements of the problem(s) need to reflect the importance of treating the project deliverable. The better the project team understands the customers' problems, the less chance there is for changing customer requirements to create project scope creep (slight incremental changes to the project scope). The e-commerce project team identified the following customer needs. -5
-
.. .
. ,A'. .
-
-
CUSTOMER NEEDS (SEE 1.3B)
External Customers Our customers are very busy during the day as they work to meet the needs of their customers. When they take time out of their business day to deal with their suppliers (and we are one of them), it reduces the time that they have to work with their customers. Internal Customers Sales and Marketing: While we can direct customers to our website to look at our product descriptions, there is no way for them to order from the site itself.
Order Fulfillment: Our order-fulfillment staff is overworked, taking repeat orders from customers who want to be able to place their orders through the websites, and we have had a problem hiring enough people to answer the phone. We need a way for customers to order our products and request quotes without having to interact directly with anyone from
-
-
3;
. . .... .--._
q& PROJECT MANAGEMENT
--*.= C ?- .
-.-.=-,
..
T S
-..-- ~
"
--L-
-
the company. We do need to be available to answer special requests and to process phone orders from customers who still want to do business that way.
Customer Requirements Customer requirements involve the specific features that the customer wants included in the final deliverable. If the customer has provided a request for a proposal, it should detail the customer's specification for the final deliverable. Include the proposal as an attachment to the project agreement and repeat the customer's major specifications in the main project agreement document. Keep in mind that you may be able to solve the customer's problems with some type of deliverable they didn't even know existed. Think creatively. It is important to prioritize the customer's requirements for the final deliverable in the event that cost trade-offs need to be made. Cost trade-offs look at how much each new requirement, or feature, of a project's final deliverable will cost. From this information, the team decides if the value is commensurate with the cost. The project team identifies each customer requirement and the importance of that requirement. The importance of each customer requirement is ranked as must have (5 points), nice to have ( 3 points), or not that important (1 point). Each team member votes on every requirement. A rule of thumb is to limit the number of customer requirements to no more than seven. Revisiting the e-commerce project, let's examine the customer requirements (See Table 3.1 on page 34). Customer Acceptance Criteria Measurements for the customer acceptance criteria rate the customers' level of satisfaction with the final deliverable. The customers may have a general sense of how satisfied they are with .
----
-- ,.
,
...
w - The Project Agreement: Ready Se
Zh!ia37 Customer Requirements (see 1.3C)
rcustomer
-
F
Nice to Have Not That portant
Must Have
Requ~irement
lue
A way to order sup- 4 plies 24 hours a day, 7 days a week without having to interact with our customer service department
1
0
23
An order capture sys- 3 tern that works with a credit card or is tied into the corporate account billing system 2 Delivery of in-stock items in under 24 hours
2
0
21
1
2
15
Reply to request for quotes in under 24 hours Delivery of specially ordered items in under 72 hours
4
0
1
21
0
3
2
17
the final deliverable, but they may not be able to put into words the specific criteria measurements. For example, two criteria for the e-commerce project are that the website should be easily navigated and that the orders should be processed quickly. But how do you measure easily and quickly, which are subjective terms? The acceptance criteria must specify objective measurement of any subjective qualities. Ease of website navigation could be demonstrated by the customer being able to order the product or get an online sales quote with one click. You can measure one click, so this is a valid acceptance criterion. Note that satisfying this one criterion does not guarantee customer satisfaction. If the "Submit Order" button is difficult to ------ .3.
:-L
--
-*
A --
'--
=
&APROJECT MANAGEMEW
.---
*--.-
.rrr.-n----
- -
~
7%!+22 Customer Acceptance Criteria (see 1.3D)
cess order within one
in existing corporate accounts billing system; no manual data entry from web orders to existing ac-
locate or there is a delay after the button is clicked, then the customer may still consider the single-click transaction to be neither easy nor quick. It may be appropriate to supplement the measurement of quickly with another objective measurement. Just as the project'team had to rank the importance of the customer requirements, they must rank the importance of the acceptance criteria with three rankings: high importance ( 5 points), moderate importance ( 3 points), less importance (1 point). Table 3.2 illustrates the customer acceptance criteria for the ecommerce project, including the importance rankings and the team members responsible for meeting the acceptance criteria. The team may not be able to identify all of the people responsible for each criterion during this stage of creating the project agreement. If this occurs, the team can put in several names or no name at all but should come back to the customer criteria when they complete the remaining planning activities. *.../-----.--.-:.
__;-=
-- .--_ __/---_. --.-, /
..
e Project Agreement: Ready. S
._-=-:
-%
Business Case An important preliminary step is to assess the overall intrinsic worth of your project. What will it bring to your business? What impact will it have on your place in the marketplace? Are there any organizational benefits to the outcome of the project? Sometimes organizations force their employees to compete for the corporate resources needed for projects. To improve the chances of getting and keeping the funding needed for the project, your project team should show a strong business case for implementing the project. The business case starts with a look at market impact - that is, how the project's final deliverable is likely to impact your organization's competitive positioning in terms of its products or services. To further develop the business case, your project team needs to identify the benefits of completing the project. To put this into perspective, the strategic impact section provides a ranking from 1 to 10 (1 is least important, based on the importance of the project to the organization) and explains the risks to the organization's interests if the project is unsuccessful.
Market Impact This section addresses how your project's final deliverable impacts your organization's competitive positioning in the marketplace. It helps you to take a look at what your competitors are doing and why this may be important for your project. %
BUSINESS CASE: MARKET IMPACT (SEE 1.4A)
How will our project impact our competitive position? If we make it easier for our customers to order our products through our website, they will be able to
order more products from us. Right now, four out of five of our competitors have websites where their a s tomers can order their products. These sites are difficult to navigate, and it takes several minutes to process the orders through a modem connection, which is what most of our customers use. Based on the design features of our e-commerce website, our customers will be able to order products with one click, and the order will take less than 30 seconds to process.
Organizational Benefrts The benefits your company gains from pursuing the project are known as the organizational benefits. These benefits may include the collateral gained from having your project team complete the project, the goals the project will help your organization achieve, and the ways in which this newly acquired knowledge will be used for future efforts. -3
\.
BUSINESS CASE: ORGANIZATIONAL BENEFITS (SEE 1.40)
What will the organization gain by pursuing this project? Our company is in the very early stages of ,integrating the Internet into our operations. We need to develop an internal capability for using the Internet, not just in e-commerce applications but in other areas of the business as well. This project enables a core group of people to become more knowledgeable about using the Internet for our business.
e Project A
et... La~rnc
Strategic Impact You should determine how important your project is from a longterm perspective. This is decided by your team based on a rating from 1 to 10. A rating of 1 means that there is minor strategic impact -the project's successful completion will have little impact on your organization's long-term strategic interests. A rating of 10 means that there is major strategic impact - the project's successful completion will have a major impact on your organization's long-term strategic interests. This impact could move your company into new markets, cause a growth in profits of a product or service line, meet a strategic objective, or achieve some other measurement of long-term strategic significance. For strategic impact ratings over 5 , your project team needs to note the strategic risks associated with not completing the project or failing to come up with the final deliverable.
BUSINEB CdSE: STRATEGIC flPACT (SEE 1.4C)
From a long-term strategic perspective, how important is it that we are succes$ul with this project? Give a ranking from 1 (minor importance) to 10 (major importance). This project has a strategic impact rating of 6. We have a strong customer base that is just starting to get up to speed with the Internet. We don't want to get "Amazon-ed" - that is, lose a lot of our market share to a n innovative, upstart Internet company. However, most of these innovative dot.com companies tanked several years ago. So this is not as strategically significant as it would have been at that time.
Project Priorities Working through this section of the project agreement enables team members to start the dialog about their shared understanding of the project priorities. Those priorities fall within the following categories: Business performance- strategic impact, marketing impact, organizational impact Project performance - schedule, cost, quality Project team performance - communication, resource management, team dynamics A thorough discussion of project priorities can significantly reduce conflict. Everyone will work better together when they are aligned on the project priorities.
-
% -
.. --.-,.
PRtlJIEGT PlllORlTV WEIGHTING (SEE 1.5)
'-
slness rforrnance
-
PI$
Team
-
Perfc -
Peri
i'rolrcl Inan'lgrr
I
-7
Projejecl spunsur Project team member Project stakeholder
1
2
3
2
1
3
2
1
3
3
f
-
B. Business Peflormance t-
.
+ .
f
.
r
I
Mi
*'StFalFj#c-- -- ' Organtzsitlona~'~
Impact
Impact
Impact
Project manager
2
1
I
Project sponsur
1
3
2
2 3 1
Project team member
3
1
Project customer Project stakeholder
1
2
2
3
.--.
-= :.:
-4-7R$ .<
- A = - .
.
-..-
-7
----
Y , 3:
5 Project A greement: Ready.,.
- -- .------=--
SI
-.~ .
C. Project Performance
D. Team Performance
COMMUNICATION There are two types of routine communications that have to happen with every project team: Sharing and coordinating the project progress among project team members A more formal communication to review and report on the accomplishment of any major project milestones for the project sponsors, customers, and other major stakeholders In Cheetah APM, all non-value-added communication is eliminated. In other words, there are no reports or reviews that do not add value to the completion of the final deliverable. Furthermore, all communication is made as quickly and as easily as possible. This is accomplished using a standard form, with any and all important information presented in an easy-to-read table that has been adapted specifically for the project. The table is only used
for communicating the progress information needed for each team member.
Project Progress During the project launch event, your team members should decide how often they are going to talk to each other about their progress, and what specific information they are going to share. These progress reports help your team members keep their worlds better coordinated. See chapter 9, for guidelines and forms on how to communicate project progress among project team members. By keeping one another informed through a project progress report, your team members can stay focused and disciplined in accomplishing the work they need to do on a weekly basis to complete the project. In today's multitasking environment, it is easy to get pulled off task to go put out the latest fire. In Theory of Constraints, Eliyahu Goldratt reveals that multitasking slows down project performance. A project progress report can avoid this problem by highlighting problem areas of focus and discipline. It can also help to determine if a multitasking team member is not accomplishing his or her work as fast as a team member who is not multitasking. To accelerate the project, your team members need to stay focused on the tasks that must be accomplished and resist the tendency to multitask. Progress reports should be completed frequently to uncover and fix minor problems before they become major issues. In general, projects under two weeks in duration with a high strategic impact should generate daily progress reports. Projects that are longer in duration, or that have lower strategic impact, should generate weekly progress reports. If there is too much time between project progress reporting, your team may procrastinate and do all of its work for that project just prior to the progress reporting date. ? :,
.-.r.:.A--.*x-;,?
,.--
b.~,.a~-,+,.-.,.,*w,-
#
b
+ e7 -.7-7:r
w - Tht? Project l;greement: Ready...St
-.
a
?
....
. ..r=t:-?b
. ~ -...
,
By making decisions about progress reporting at the launch event, there won't be any surprises.
PROGRESS REPOW (SEE 2,1) What type of project progress communication does the project team agree to? Type of Project Progress Report: Weekly project progress report Contents of Report: Major accomplishments, decisions, action items needed from other team members, potential problems Frequency of Report: Weekly, due every Friday Who Requested Report: Project team leader
Project Milestone Reviews Project milestone reviews are a more formal type of communication where decisions to progress to later stages of the project are made. These decisions are based on how the criteria for each milestone are met. Your team determines what milestone reviews may be necessary for this project. Milestones are the building blocks needed for creating the final deliverable. They are not arbitrary events that management sets up to scrutinize the project team. Milestones are based on the steps created in the early stages of the project that affect the work to be completed in the later stages of the project. For example, you have to pour a foundation before you can start framing a house. Once you have the foundation complete,
you have reached a milestone. Note that you need to define carefully what you mean by "complete." In fact, before you can start framing the house, the foundation has to be inspected to ensure that it was poured correctly, meets building code, and can support the house that is being built. You need to make sure that the initial steps of your project are structurally sound before you continue on with later steps. In Cheetah APM, your team decides on the interim deliverables and then on the events that are the project milestones. During the project planning (see chapter 5) phase, your team creates milestones based on how dependent they are on the deliverables. For APM, the number of milestones for any project should be limited to ten, for reasons discussed in chapter 5. Additionally, not all milestones for a project need to have a review associated with them. There are three milestones common to every project: Project kickoff. This is completed during the accelerated project launch session (see chapter 2) The completion of the final deliverable The completion of the lessons learned report In addition to these three milestones, your team can create up to seven more. If your project is so complex that it needs more than seven additional milestones, your team should create several subprojects. The interim deliverables of your subprojects can be used to create the final deliverable for your more complex project. During your reviews, it is common to combine milestones that indicate when the critical interim deliverables are complete. If your organization already has standard project-reviewing practices, take a look at those practices and examine where they are adding value to the completion of your final deliverable and where they are not. Eliminate any review activities that are not adding value.
-
.,.-. ,...*., -. .,.-,---=: s w - The Project ~~kemeRea nt:dy... Set.. tmch!
* . + . I-. , - .--1 pl*+l--2.t.-.
.
.--. .
.!.?-.-
*F-d-?7.,
.~ ..
. e ? n T ?
7&%23 Milestone Reviews (see 2.2) Project Purpose of Mitestone Re view Revfew
Project kickoff
Go live
Lessons learned
e ""----Rleviewera Approval ~ a f r* t o Move
-
Evaluate Project whether the team; project team project sponsor has completed the plan sufficiently in order to get started on the project Ensure that Project the website team; and the em- project ployees are sponsor ready to let the customers place online orders Record what Project was learned team from launching this project to build on these experiences for future projects
'"-.+get
Revia
Forward
Project sponsor
1 day after the project launch session
l ':h
1 hour for each of the 4 team members
+ $495 external costs
Project team; project leader
3 months 9 5 % after project launch date
Team 8 hours each
Project leader
1 week 100% after going live
Team I hour each
When your team first creates a project agreement, it needs to establish several things: the purpose of the review, who needs to be involved in the review, who needs to approve the milestone prior to moving on, and the date of the review. The project launch
IJEGT MAN
facilitator should give the team a short period of time (no more than ten minutes) during the project agreement discussion to get a start on identifying the milestones. More information can be added after the team identifies more details about the milestone reviews during the project planning steps. Table 3.3 displays the standard milestones for the e-commerce project. Since projects similar to this one have been done before, the project team can significantly speed things up by following a template for determining the milestones.
RISK TOLERANCE Risk tolerance addresses the amount of risk a team and the sponsor will accept to create the final deliverable. Risks are a measure of uncertainty, and there can be various reasons for it. The team could be unsure of the skills needed to create the final deliverable, or it could lack confidence in its skills. The team may'also be unsure of how it can acquire the skills necessary to create the final deliverable. Uncertainty can also stem from concern over management's ability to support the project, without intervention or interruption, for its duration. Risk-tolerance levels will also vary among project team members. An individual's personal risk tolerance is based on innate personality, experience with the particular project type, and perception of importance of the project.
Low Risk Tolerance A low risk tolerance indicates that the project team or sponsor
is not willing to accept much risk. This means that one or both do not want to feel any uncertainty in their ability to create the final deliverable. When a team has a low tolerance for uncertainty, the project takes longer and costs more, because there will be a need for more scrutiny of each step to minimize the occurrence of problems. The value that extra reviews add may
,=,.
*-,
4--=
,q*t*+--
*-+FW*~-=-,~
w
-r-. I . _ . , -
I-d*
* -+,T.,.-
r . -~~-m..-<--+-~~!T:.*..",
- The Project Agreemenk Ready...Set... laitnch!
not be proportionate to these costs. People will have a lower risk tolerance if they are more risk averse, don't have much experience with the project type, or perceive the project as significantly important.
High Risk Tolerance Conversely, a high risk tolerance indicates that the project team and the sponsor are willing to accept a high level of uncertainty in creating the final deliverable. Organizations that are well established and stable and have easy-to-use project management processes are more tolerant of risks. And a project team that has significant experience in what it takes to create the final deliverable can also accept a higher level of risk. In Cheetah APM, the higher tolerance a team has for risks, the faster it can move the project along, as there will likely be fewer reviews of the project plan.
Developing Trust from Stability APM can reduce uncertainty about management's commitment because management will be more inclined to support and not interfere with a project that is guided by an accountable methodology. Trust takes time to develop and is ultimately developed by using stable processes that consistently produce successful results. When setting a risk tolerance, your team specifies the level on a scale from 1 to 10, with 1 being a low level of risk tolerance. Your team also needs to document the reasons behind its ranking.
RISK TOLERANCE(SfE 3.0)
Risk Tolerance: Level 2 This project has a high market impact, so we need to get it done. However, we are not experienced in
doing Internet projects in our operation, so we have a high level of uncertainty in what it is going to take to develop the e-commerce application.
CONSTRAINTS Constraints in Cheetah APM fall into two categories: resource constraints and organizational constraints. Resource constraints can include the spending limit that is placed on the project team, the number of people who can work on the project, the type of equipment that is available for their use, and the deadlines for the project. The organizational constraints are any issues that arise in creating the final deliverable regarding the organization itself. The constraints are defined by both the project sponsor and the project team. The project sponsor must specify any resource constraints that are placed on the project team for creating the final deliverable and the priority of those constraints. The project team works together to identify the organizational constraints for creating the final deliverable. For project team members, the resource issue comes down to a chicken-or-the-egg question: which comes first? Deciding on the budget, staffing, and schedules? Or the spending limits and deadlines? By defining the constraints up front, the project team has a better idea of what the sponsor and the customer have in mind. Consider this example. The type of house you would build for $300,000 is probably far different from the type of house you would build if you had $3 million to spend. Accordingly, before you start to figure out the schedule and labor required to build your house, you need to have at least a ballpark idea of how much money you can spend on the house. The decisions you make on the budget and suppliers will vary depending on your deadlines. If you have only six months to build the house, the decisions you make will be different from those based on a .
-
.
-,,,,,... .
-- ...-...,7-. '=-F--,.-, .
,
.c=ll::i.fr..i.---!=-f.*--.-.l> .
..
Pmject Agreement: Ready. Se't... Launch
deadline of five years. If you want to build the house yourself and not use any outside contractors, you will probably need to make a significant tradeoff when budgeting time and money. If you had a time constraint of six months, a spending limit of $300,000, and you could not hire external staff, you would definitely want that information from the beginning of your building project - and you would surely want to understand the consequences of your resource constraints before agreeing to the project.
To Launch or Not to Launch? While going through the project scheduling and budgeting steps, your team may discover that it cannot successfully complete the project with the resource constraints identified in the project agreement. It is the responsibility of the team to work with the project sponsor to bring a balance to the resource constraints and the actual needs of the project. The time needed to work with the project sponsor on overcoming the constraints is determined after the scheduling and budgeting data is collected. This provides your team with documentation on the impact of the constraints on creating the final deliverable. To accelerate the project further, your team needs first to understand where the schedule, staffing, and budgeting insufficiencies will occur before it can engage in a discussion with the project sponsor about the resource constraints. Conversations that occur before the project team collects this data can significantly slow down the progression of the project and unnecessarily increase tension between the project sponsor and your team. If the team decides that it is impossible to create the final deliverable based on the resource constraints - and if it cannot come to a compromise with the project sponsor - it has the right and the responsibility to decide not to proceed with the project p lanning. This is the most appropriate course of action if the resource
constraints are not adequately changed in order to successfully complete the project. Within a registered work force, such as a military organization, the team has a certain recourse if a plan is not well supported and thought out by the leadership. By saying nothing, a team implies consent, which may not only cause the project to fail but may also damage the team members' reputation for the ability to get their work done on time and in budget. During the Cheetah APM launch-planning session, your proj ect team becomes familiar with the project sponsor's defined resource constraints and priorities, and defines the organizational constraints. It is, therefore, important that the sponsor provide the facilitator with any resource constraint information prior to the launch session.
Organizational Priority The project sponsor needs to identify the organization's priorities for the resources before setting the resource constraints. These priorities are specified in terms of cost, schedule, and quality, which are the measurement of the final deliverable based on the customer's acceptance criteria. The prioritization is important for your team to know before it starts planning, because the decisions it makes regarding the schedule, staffing, and budget will be based on the organization's priorities of cost, schedule, and quality.
ORGAWIZATiOIAL PWItOllTlES(SEE 4J) Quality: Has to work very easily for our customers and has to integrate seamlessly into our existing order capture systems. Schedule: Must be finished in three months Cost: Cannot exceed $100,000
I
,,,,:.-:-*p;: -..+-:: .
.
/-.-:-
a <_r
w - The
-
LM-....
t... Launch
Spending Limits It is the job of the project sponsor to specify the spending limits before the project team gets together for the project launch session. The spending limit is a not-to-exceed number, which gives the project team an idea of the financial resources it has to create the final deliverable. Although the project sponsor can set this figure as a to-be-determined (TBD) figure and wait to see what the budgetary requirements will be, a word of caution is in order. If the project sponsor truly has an unstated spending limit and the team comes in over that spending limit by a large margin, the trust between the project sponsor and the project team will suffer. It is best to provide the project sponsor with options to show how much different features will cost and negotiate from that perspective. If the project sponsor has a not-to-exceed spending limit as well as an expectation of what the costs should be, the sponsor needs to be up front about both figures. The sponsor must work with the project team to modify the spending limit or customer requirements as the project progresses. The purpose of the project agreement is to stimulate an open and positive dialog between the team members and the project sponsor, with the aim of quickly creating the final deliverable. The sponsor and team should never use the project agreement to manipulate one another to get the most work for the least cost or the most money for the least work.
SPENDING CONSTRAINTS (SEE 4.2) The e-commerce project team acknowledges that the spending limit to complete the project is $100,000
Staffing Constraints The staffing constraints determine the number and type of peo-
ple available to work on the project, and the amount of time they have to commit to the project. While your project team members may want to use specific people in the organization, those people may be unavailable during the time frame of the project. The project sponsor needs to share with the project team any knowledge of staffing limits and include them in the project agreement. It is easier for people to make a commitment to work on a project if they know the amount of time that is expected of them, especially if those committing to the project are volunteers. This section of the project agreement is also where team members need to specify their constraints for working on the project. Team members should specify when they will be traveling, on vacation, or otherwise unavailable and should think of ways that they will be able to optimize their performance during the project. Accelerating projects is about working smarter, not about working more. Vacations are important, especially with projects over three months in length. To achieve performance levels that help people to have the energy necessary to finish their projects quickly requires that every team member take time for recharging and renewal. We have found that those who take a vacation of three to five days every three months actually perform their jobs faster and more effectively. If you want to have a first-rate project team, make one of your constraints be that everyone who works on the project must take three to five days of uninterrupted vacation time every three months. As well as specifying vacation times, you may want to limit the number of days in a row and the number of hours in a day that your team members can work. People work a lot more effectively and efficiently if they have balance in their lives. For peak-performing teams, limit the work schedule to no more than six days in a row at a time. Likewise, limit the number of twelve-hour days to no more than two per week. -.*,-.
.
s - The P
.
..
- Launch!
If people have a tendency to work long hours in your organization or if the project is high pressure, the project sponsor and team leader need to encourage the team members to exercise. Health advocates recommend exercising for at least half an hour, four times a week. The military has long known that, for people doing intensive work in high-pressure situations, spending some time every day exercising helps them better cope with the pressure. Team members should follow exercise programs in coordination with their healthcare provider's recommendations about what is appropriate for them. Achieving peak performance with Cheetah APM requires that the project team members take care of themselves. The project sponsor and the project team leader set the tone for this.
STAFFING CONSTRWIHTS (SEE 4.3) What staff is required to do the project, and for how long will people be needed or need to be available? one programmer, full-time, one project leader, half -time one webmaster, 20 hours per month one finance person, 20 hours per month one customer service person, half-time The programmer can be an outside consultant if the in-house programmer does not have the skills for this application. The perso4 who needs to do the programming has a three-day vacation planned four weeks into the project. Because of the high-pressure nature of this project, the project sponsor has approved a scheduled --
L e--'=
-- -.-
-.--. W i PROJECT MANAGEMENT
- ---
--,.
? . 7 -
---**,
workout session, where people on the project team can take 45 minutes off per day to exercise for the duration of this project. This exercise program is done with the approval of their healthcare professionals, if necessary. Additionally, the project sponsor has said that the project team can work no more than six days per week and no more than 60 hours per week.
Equipment Restraints There may be constraints regarding the access that your team; will have to equipment necessary for the project. Organizations p a y have limited equipment resources that have to be shared by numerous people on different projects. Also, equipment may be needed for other applications and so may not be available to the project team. The equipment constraint section details these limitations. Cr
EQUIPMENTCQMSTRAIHT8 (SEE 4.4) The server hosting the internal LAN does not have the capacity to host the website for the e-commerce application. The project team needs to use an outside hosting service for the e-commerce website.
Time Constraints The project sponsor identifies the deadline for the final deliverable. Cheetah AF'M sets aggressive time constraints (deadlines) to speed the completion of the final deliverable because of the pf-emise that people will take all of the time allotted to them to plete a task. +.,
.-. - -- . '
. - . A L . Y s -
-.=--=I
,='-
w
'
(.em-
,,
.-
- The IProject d i
-- -* z--*-,:.= eady... Set
_.__..-*-:
.-
-
,
+.-. . ,7 I.'
The project sponsor takes a leadership role and sets aggressive deadlines. Included in this leadership role is a commitment to removing barriers so that the project team can achieve the deadline. The team members set the deadlines for their interim deliverables based on the deadline for the final deliverable. For the project agreement, the team members set the deadlines for those interim deliverables they know they might have to create. Any information recorded for the interim deliverables by the project team during the project agreement stage is open for modification based on information discovered later in the project planning stages. One of the benefits of Cheetah APM is that it eliminates activity that has no value, thereby allowing for aggressive deadlines. For example, one of our clients has a 16-day cycle for completing event planning for every career fair project. Six days of that cycle are spent waiting for the finance department to approve the various budget requests for those attending the career fair. If the eventplanning task is on the critical path - that is, if it becomes a critical activity for completing the career fair project - then it is up to the project sponsor to remove whatever is causing the delay. In this case, the source of the delay is the six-day lag time spent waiting for finance to approve the budget request. APM requires a commitment from everyone in the organization to remove the cause of delays through process redesign. Making a commitment to set aggressive deadlines can provide the motivation needed to remove the waste in a n organization's standard operating procedures.
Organizational Constraints The project sponsor.and the project team identify the organizational constraints. For each organizational constraint identified, the team also has to define the impact that that constraint will have on creating the final deliverable. If an organizational con-
straint has a significant impact on the project team's ability to create the final deliverable, the project sponsor must work to remove the constraint.
What constraints does the organization have concerning this project, and how will they impact the project? Constraint: Has to integrate with existing business systems for accounting Impact: Programming tasks will be greater in order to create a custom patch to the existing business system. Constraint: Cannot charge customer's credit card or customer's internal account until after the goods are shipped Impact: If the website is integrated into the accounting system, an order placed on the website provides the same information to the accounting system and drives the same actions as one taken on the phone. Constraint: Have to use a secure website-hosting service Impact: Cannot use the internal server anyway. Reliable web-hosting services are widely available. Constraint: Must use existing merchant account Impact: May not be Internet enabled. May have to get an Internet-enabled merchant account.
,.-+iTr--*c-
."*r-.
*&a-, ,:-.. . The Project Agreement: Ready Se
-
..
._---,c. +-+*==-.,, . 7-
w
-
...
~n.=-.'-~-s.-.5--, e . .
Constraint: Have to maintain look of existing website Impact: May limit design and take longer.
PROJECT TEAM MEMBER RESPONSIBILITIES The final part of the project agreement is deciding on the roles and responsibilities of the project team members. This section is last because it allows the team members to consider the big picture before starting to think about what they have to do specifically in their roles to create the final deliverable. To create the project agreement quickly, it is crucial that the team stay on a high level; in other words, it should not get caught up in the details. There is a danger of getting caught in the details if the team members get into their roles before they consider the big picture. For projects to move fast, project teams need to be small. The optimal size for a Cheetah APM team is one to seven people - more than seven, and too much time is taken to coordinate all the activities. While teams generally are not smaller than three people, it has been found that a one-person project "team" can be very successful using APM, even without the input from colleagues. In the project roles (section 5.0 of the project agreement), you need to identify the name of each position on the team, the responsibilities of each team position, the name of each person filling that team position, and the color Post-it that will represent their role. Colors are used throughout the remaining project planning steps to quickly show who needs to do what on the project. Color coding allows each team member to focus on his or her tasks quickly and easily. (This book uses shading instead of colors.) The appendix shows the completed project agreement with lessons learned. The lessons learned are added as a separate activity at the very end of the project. y.Tr-
-*-. L
.,.=;
-- +-c=---%? <----.
E &
PRIIJEGT MAN
--. ,,-ar,; .
- --
J -
.'I-.+ ; " 1 . , -
The last column is the commitment the team member will make to the project. (See the staffing constraints section in, this chapter and chapter 4, "Teaming," for more information.)
PROJECT AGREEMENT TEMPLATE Prior to the project launch event, the facilitator works with the project sponsor to identlfy the details of the project agreement that are critical to the project sponsor. This guarantees that, prior to the event, the facilitator knows which issues the team members will decide on and which issues are of sufficient importance to the project sponsor. For the project launch event, the project agreement template is created using a preprinted wall-mountable template. At the launch event, the template is taped to a wall or positioned where it can be easily seen by all project participants. This ensures that everyone participating in the project launch event can review and agree to each element of the project agreement. The facilitator documents each agreement on a Post-it and places it in the appropriate category on the project agreement wall template. Once the project agreement session is complete, each team member initials the Post-it on every agreement section, verifying agreement to what was recorded. During the other project blanning stages, it is highly likely that information on the pdoject agreement will be modified. When this happens, it is necessary to indicate the modification on a new Post-it and have the team members initial that new Post-it. Keep the old Post-it and record why the change was made to the project agreement.
TIMING It typically takes about an hour to lead a project team througfi the creation of the project agreement. You can expect the time to break down this way: Project scope, twenty minutes
.-
- - # r P. 7 r--
.-
- 4 s -
= - -----
.-
_..---- -::.-
w - The Project ~~reernent: Ready.,, Set...
Launch
1
Communication, ten minutes Risk tolerance, five minutes Constraints, ten minutes Team member responsibilities, five minutes.
fi-3
7 Project Agreement
Project Participants: Project manager Project sponsor Project team Project customer Project stakeholder Project Agreement Change History
11. Project Objective [What will the project team be creating (the final deliverable)?]
1.2. Project Boundaries [Where do the team members start their job and when are they finished?]
----
-I4-
5
-
&+---- \#=.
-*-
A& PROJECT MANAGEMENT
+ --------
-- A
fiflm2 '.Project Agreement (continued)
1.3. Customer Definition A. Project Customers [Who is going to use the final deliverable from our project,?] External Customers Internal Customers/StakeholdersI I
B. Customer Needs [What problems do our customers have that the final deliverable with help them solve?] External Customers Internal Customers/StakeholdersC. Customer Requirements [What are the customers' specifications for the final deliverable? Importance ranking - each team member ranks each requirement ( 5 - must have, 3 - nice to have, 1 - can live with or without).] R Have
,-. .- .-;-7-
.
,.,++.& --
-. :-v=---'.-7
-..
.,.-.,. -
-.-~
.. .
...
Ready
et... Launcl
Sl
fifccra2 I Project Agreement (continued) D. Customer Acceptance Criteria [How are we going to measure the customers' satisfaction with the final deliverable? Importance ranking - each team member ranks each criteria(5 -must have, 3 - nice to have, 1 -can live with or without).]
1.4. Business Case A. Market Impact [How will our project impact our competitive position?]
B. Organizational lmpact [What will the organization gain by pursuing this project?]
C. Strategic Impact [From a long-term strategic perspective, how important is it that we are successful with this project? Give a ranking from 1 (minor importance) to 10 (major importance).]
1.5. Project Priority Weighting [From your perspective, please assign a ranking of 1,2, or 3 to each of the elements below. A ranking of 1 is higher importance, 3 is lesser importance. Please rank each element using each number (1, 2, or 3) only once.]
ECT MANAG
fi-3
7 Project Agreement (continued)
A. Overall Weighting -.
Bu Pe
>
--.
je&-L--w'
-
-
- -.
"1>19
-
formance
Frojecr nlanagr I
Projecr sponsor Project team member Project stakeholder
, B. Business Performance
m m --trn
C. Project Performance
D. Team Performance
'~rganiiatioriai-- s t ~"- - '. Impact
lmpa
-
fiflww3 '. Project Agreement (continued)
2.0 PROJECT COMMUNICATION 21. Project Progress Reports [What type of project progress communication does the project team agree to?]
2.2 Project Milestone Reviews [What needs to be reviewed before the project can progress to the next step?]
3.0. RISK TOLERANCE Risk-Tolerance Level [How much risk (uncertainty) can the project team and the project sponsor accept with being able to create the final deliverable? Rank the tolerance level from 1 (low) to 10 (high).Low risk tolerance means that the project team has a low tolerance for uncertainty and will need to have more time and money to create the final deliverable. High risk tolerance means
fifw2 7 Project Agreement (continued) the project team has a higher tolerance for uncertainty (and brobably less uncertainty in their ability to create the final deliverable).] Rating Reason -
4.0 CONSTRAINTS
41 Organizational Priorities [Defined in terms of cost, schedule, and quality.] 1.
2.
4.2 Spending Constraints [What is the estimated budget (money) you'll have to do the project?] External Internal -
4.3 Staffing Constraints [What staff is required to do the project, how much time will they be needed or made available, and what do you know about the availability of people who might work on the project?] Staff Required Availability -
4.4 Equipment Constraints [What limitationslrestrictions may be placed on equipment you'll need to do the project?]
4.5 Deadlines [When does the project have to be complete?] -:.r*.-l-*a
--
-- ..*.
....!. .-.,.* -.ezv,. >>,w'::-w--:T--.-- w - The Project Agreement: Ready set.:.' .-,Y-!---.7
,-
...
--.
Lannch
fipv2 7 Project Agreement (continued)
4.6 Organizational Constraints [What constraints does the organization have for doing this project and how will that impact that project?]
5.0 TEAM RESPONSIBILITIES Team Position Responsibtiity
Name(s)/Color Commitment
-
--
*-.=-.-n_sf--rr
b
-
---,-----
--..-..-
..-----,r
#& PROJECT MANAGEMENT
- .-
Pulling Together
A
cornerstone of Cheetah APM is creating a high-performing project team. Projects are done by people - teams of people. Your project can be completed quickly only if the team of people working on it can work quickly. Alone, most people can undertake project management very well. Get several people together, however, and what was simple becomes complex. It is like a four-person rowing team competing against a solo rower. It takes far more coordination for the four people to pull together than it does for the single rower, although a coordinated team will outperform the solo rower. Of course, an uncoordinated team may capsize the boat! If one person on a project management team makes all of the decisions, the decision-making process moves along quickly but the project will likely get hung up because the team members haven't bought into the decisions and may not understand their interdependencies. Initially it takes more time to get a team of peo-
ple coordinated for a project. The return on the time investment, however, is more efficient and effective project work. A premise of Cheetah APM is that you focus on the positive. Remove all the barriers that prevent your project team from working quickly together and give them the project management tools that will help them get organized and do the work needed - fast! If your team has to focus on resolving conflict, rather than staying positive, it has less time to do the work that is required for the project. The main obstacles that prevent teams from achieving their top performance are: Insufficient resources Inadequate support for their project from management Ambiguous customer requirements Lack of a simple project management process to help them organize their work Poor team dynamics Poor team dynamics originate from a combination of all the other obstacles. On a smaller scale, poor team dynamics come from a lack of skill in developing effective teaming relationships. In other words, you can have a team that works well together, but without a strong system to support them, even a great team will produce mediocre results. The Cheetah APM technique clears away all other obstacles, creating a n efficient and outstanding team performance. Several techniques are covered.in this chapter to address the typical problems that cause poor team dynamics. Often, a project goes awry because it was not set up correctly in the first place. This is why it is critical for the sponsor and the team to create the project agreement together (as detailed in chapter 3). The next steps are designed to help the team negotiate how they are going to work together.
One source of conflict among people is their different expectations. By working through what each team member expects, and how willing they are to work as a team, each person is given an opportunity to first identify and then articulate his or her expectations. By negotiating how they are going to work together, the team members develop a method to talk about their teaming relationship. This conversation must happen before any problems arise. Waiting to talk about the teaming relationship after problems already exist can lead to touchiness that is difficult to overcome. To get the project team started in the right direction, this chapter covers the three areas most important for your team to address when it begins to develop the parameters for working together on an accelerated project: Self-Interest: Defining team members' interests in working on the project Commitment: Deciding on the level of commitment (in terms of time) each team member can make to the project Ground rules: Establishing the rules on how the team is going to work together and how it will organize and hold its meetings Project teams go through various phases when working together. The last section of this chapter covers how establishing positive team dynamics can help project teams work through issues that may arise as the project progresses.
SELF-INTEREST Teams are made up of people, each with their own individual interests and internal motivations. A person cannot consistently be a good team player if his or her individual interests are not in some way being served by participating in the project team. People can only participate in an activity that is detrimental to their individual interests for a very short time. d.-?--.-->
J.+...--.
px+%,
.
-
-
--.<---.-<--
'-,-
w
4v
--
-4--
- Teaming Pulling Togetht
--~-7%-
It takes a strong commitment to participate in APM. If being on the team contradicts a team member's individual interests, motivational problems can occur. One unmotivated person can slow down the whole team. Prior to joining the team, each prospective team member must decide whether or not his or her individual interests will be served by being on the team. Individual interest can range from someone simply wanting to keep his or her job to someone finding the project compelling enough to work long hours for little pay, as in volunteer projects. Regardless of motivation, the most important thing for a potential team member to think about is how the project team will meet his or her own interests. People should be asked or invited to be on a team, not ordered, even if being on the team is an important factor in that person's employment. Teams using Cheetah APM perform far better if the people involved have actively chosen to be on the team. Over time, the interests of the team members may change with respect to meeting their own self-interests. For example, keeping one's job, which might have been important a month ago, suddenly becomes unimportant when there are five recruiters banging down the door with job offers. Sometimes being on a project team can be at odds with a team member's self-interest, causing poor motivation and poor team dynamics. In this event, it is the responsibility of that team member to either develop a different attitude regarding self-interest or leave the team. Team members are encouraged to assess for themselves how accountable they should be for their own performance and motivation in working together on the team. The team members on the e-commerce project defined their self-interest as follows. Because the purpose of the exercise is to gain better self-awareness, they did not share their self-interests with the other team members.
-.
$&
% - -
\*-
THE E-COMMERGE PROJECT TEAM
Alice (project leader): Alice is a woman with great people skills and great technical skills. She acts somewhat like Tracey Ullman, as she is a short, dynamic woman on the go. Alice is a mother of three and has been in the business for the past 15 years. She has a bachelor's degree in industrial engineering from Ohio State University and lots of practical experience in the operations of this business. Self-interests: Alice is interested in developing the skills needed for running an e-commerce project. Bruce (customer service): Bruce is a man who looks incredibly haggard from constant customer beatings, but h e always manages to wear a new-looking company polo shirt and khakis. Bruce has been with the business for five years and originally came from the retail sector, where he was the manager of the men's department at Nordstrom's. Bruce has a n associate's degree in business from courses he has taken parttime over the years. Self-interests: Bruce wants to do less work with managing customer support staff and figures if the customers can order products directly from the website, it will prevent a lot of his headaches. Chris (webmaster): Chris is really creative, kind of kooky looking, but on the conservative side of kooky. He usually wears a t-shirt, jeans, and sneakers with a blazer. Chris has a bachelor's degree in computer -.:---
--.
._._-.l_ . .. ./-.
- _ _-_--
. .-
.
-.*
.---
z*/mG&7z:---
lining: Pulling Togatht
*
T
science from the India Institute of Technology in Bangalore (class of '95), and a master of fine arts degree from Harvard (class of '97). Self-interests: Chris wants improvement of professional reputation by becoming the webmaster of an e-commerce site. Debra (finance): Debra is a reluctant adopter of the new-economy uniform. She looks uncomfortable dressing in business casual. Debra acts very conservatively and gets somewhat uptight around the web people and the touchy-feely nature of the customer service guy. She received a degree in business from Howard University in the early 1980s. Self-interest: Debra knows she needs to participate in this project to keep her job. Ed (programmer): Ed has a number of tattoos and body piercings. He is fierce and feisty but also a very fast programmer, and, consequently, he is always very busy. Ed has an incredible attitude, dude. He was way too busy being an independent programmer and snowboarder to have gone to college. Self-interest: This company needs Ed's time and is willing to pay him top dollar for his services. He's taking this project, but he has to get it done fast so it doesn't interfere with his next snowboarding competition.
COMMITMENT Like self-interest, commitment is not something that can be ordered. As addressed in chapter 3, each person on the team needs to commit to the amount of time required for the duration of the ,Ls.<
-:7r.
72
...-..,.
x-.-.
..<7
7
...,,.,
7--.=--.
f& PROJECT MANAt
.
..,
-~.,. *..-
-
~72-
project. Only a person who has the time can make a commitment to a project. People have many other things going on in their lives, and only they can decide how they will allocate the use of their time. Sometimes a team needs to compromise if it needs a person who has a specific skill needed for the project but who cannot make the time commitment. In this case, the team and the skilled individual need to work together to determine to what extent additional resources are needed. Some companies are organized by function, and the functional manager will make a commitment to provide a specific skill set to the project team. This vicarious commitment is not the same as an individual committing to participating on the project team. The project team will achieve a much higher level of performance if each person develops a psychological commitment to the other team members and to the goals of a project. When we worked in manufacturing environments, we found that workers took more actions to keep their co-workers safe than they did to keep themselves safe. Similarly, in our training programs, we have found that when we give the entire team points for finishing activities on time, or coming back from breaks on time, every individual performs at a higher level to avoid letting the team down. Team members will psychologically commit to the team if they understand the interdependency of their roles. For example, by allowing the project team members to develop the project schedule, rather than simply letting the project leader do it, the team members better understand the impact they have on their team members. In that way, they build a deeper level of commitment to each other and to the project. There are several ways to help team members establish commitment to the project and to their teammates. These methods emphasize qualities that are part of the foundation for all human interaction. They have been proven to work in many settings not just for project teams. One method is to have the team ?-LC? + , .,.>.,.
....-.-:-.-.,.-
*r.*r?..:+.-.
r57=,L
e ~ ~ ! ~ : ~ ~ ~ -,--qq . r ~-.-= ~ - - - - -
15FsPf - Teiming: Polling Togeth~
members agree to the pursuit of a common goal. This is one of the benefits of the team developing the project agreement. And you will find that people who join the team after the development of the project agreement generally do not have the same level of commitment as team members who have been involved from the start. The second method is Socializing. Providing ample time to socialize when developing the project agreement and during team meetings helps establish commitment. As described in chapter 2, it is recommended that the team take a break every hour for ten minutes. This time not only gives the team a chance to use the rest room and relax but also to socialize. A third method is through food. Breaking bread together helps people establish bonds beyond what they would develop if they were just working on tasks together. A common team-building exercise is to have each team member contribute to a shared meal. Making commitment expectations clear is important when recruiting volunteers to work on a project. People are naturally interested in helping out. By committing their time and energy to the project, they tend to gain as much as those they are helping. But people can be reluctant to volunteer if they do not know the level of commitment they will have to make. Prospective volunteers need to feel free enough to commit to a project at a level that is comfortable for them, considering their other responsibilities. If these issues are understood from the beginning, the project sponsors and leaders will have a much easier time recruiting volunteers.
w-
7
0
\.
T!M€ GOMM%TME#TOF ME E-COMMERCE PROJECT T W l
Alice (project leader): 2 5 hours per week Bruce (customer service): 25 hours per week
Chris (webmaster): 15 hours per week Debra (finance): ten hours per week Ed (programming): Up to 70 hours per week (and he charges for every hour he works); to provide this commitment, Ed requires a retainer of 33 percent of the total contract up front
GROUND RULES FOR TEAMWORK There are two parts to developing ground rules. The first is deciding how the team will work together. This means working together to make decisions, actively contributing to the project team, and communicating with each other and those outside of the team. The second part involves working to establish ground rules for meetings. These ground rules may include the time of the meetings, expected behavior during meetings, the atmosphere (location, food availability, smoke free, and so forth), and prelpost activities (agendas and action items).
How to Work Together Do you remember participating on teams or in clubs as a kid? If so, you probably remember the ritual of rule making. This is a natural result of people getting together in a group. We have an intrinsic need to establish how we work and play together. As we get older, we start to assume that people are playing by the same rules that we are. What typically occurs in a group is an initial honeymoon stage in which team members are very nice to one another at first and things just move along smoothly. But then a rockier stage comes, when a minor issue can cause a flare-up, and the team either takes action to correct the problem or moves into avoidance behavior. Corrective action to fix team dynamics may be effective, or it may alienate the team members even further. In any case, corrective action takes time that could be spent R,..?*L4=-.-~.'G-7
,>,-
--ZFYF--.,.-
,&, ", ---"-
w
,-,.
.*,..-fl.---?---74 ~
- Teaming: Pulling Togethe1
--+,.--
.,:
working on the project tasks. If the avoidance route is taken, even a simple coordination of project tasks becomes difficult. By creating ground rules at the beginning of the project before any problems occur, the team acknowledges up front that the honeymoon will not last forever. Ground rules help a team move through the rough spots, thus preventing poor team dynamics from slowing the project. There are three conventions for setting team ground rules: 1. Every team member has to agree to every team rule. 2. Periodically, the team members can revisit the ground rules and add or delete rules as they learn to work together. 3. If a new team member joins the team, the new member must agree to the ground rules or new ground rules must be established. The project launch facilitator guides the team members in setting their ground rules as part of the accelerated project launch session. The facilitator should get the team started by allowing ten minutes to set up the ground rules. The team should write each ground rule on a Post-it, and every team member should initial every Post-it. There are a few distinct subjects that should be covered. By talking about these ahead of time, teams can save themselves a lot of stress and aggravation later on.
Rules for Decision Making Arguing about decisions can take up a substantial amount of time and cause a team to become paralyzed and lose focus. The fastest way to move projects along is to make decisions by majority vote, with the project team leader having the final say if there is a tie. One way to use consensus to make decisions quickly is by giving people a three-way vote. This is accomplished by the team members giving a thumbs vote: Agree: thumbs up
._..--
-
_+--
_-------
@A PRI
... IAGEMENT I-.-+
4
- -
#
P
C
.
-.*-p,-
---
-?-
Disagree: thumbs down Disagree but accept the majority vote: thumbs sideways The project team continues to develop alternative decisions in tenminute intervals until every team member is thumbs up or thumbs sideways. If there are still people with thumbs down after three intervals of brainstorming, the decision moves to majority rules, with the team leader acting as the tie breaker. The team must address the following two issues: Are decisions made by majority rule, consensus, or the team leader? How are conflicts addressed when one or more team members disagree with a decision that has been made?
Rules about Contributions People have differing expectations about the type of contributions made in teams. The first issue here is confidentiality. Some people feel free to discuss anything with everyone, whereas others feel this behavior is a breech of trust. From the beginning, team members must establish the level of confidentiality that is appropriate for the team. The next issue is attribution. Some people are not forthcoming when it comes to taking credit for anything. But when they hear others tooting their own horns, they may feel as if they have been slighted because someone stole their thunder. All team members need to understand that people have different needs for recognition and, therefore, should establish how they will communicate their accomplishments to others. The third issue is participation. Some people are content being more passive during team meetings, while others are more assertive and like to take charge. It is the responsibility of the more assertive team members to seek out the ideas and opinions of the more reticent team members.
w - Tear
The team should discuss how to positively encourage participation from each member. This can be as simple as allowing each team member to have five minutes to discuss an issue or topic during each team meeting. The last issue to address is acceptance. Sometimes it is good to have disagreements and conflicting opinions - they can stimulate thinking that will solve problems. At other times, conflicting opinions can significantly slow down the progression of the project. Team members need to decide when it is acceptable to have freewheeling discussions and disagreements and when it is time to rally together and keep the project moving along.
Rules for Communication When looking at group communication, it is important to keep in mind that everyone has a different way of viewing things. What means something to one person may mean something completely different to another. Try to step into each other's shoes as much as possible. If you do this, you will find that it is much easier to communicate and work productively together on your project. To complicate matters further, different people have different communication styles and comfort levels regarding communication. Team members need to decide on the necessary level of sharing problems. A rule of thumb is that team members should solve problems that are within their circle of influence without burdening the other team members, project sponsor, or customer. However, if the problem is of a significant magnitude so that it impacts the performance of another team member, then it should be disclosed. Also, the team may want to set up a system to share problems with each other before bringing them to the project sponsor, and definitely before discussing problems with the external customer.
Feedback is another important communication issue. People have different ways in which they prefer to receive feedback. If you are dissatisfied with another's performance, it is usually a good idea to take some time before speaking to consider how your words may impact the future relationship. By taking a step back, you can prevent more problems from cropping up in the future. Before giving someone unsolicited feedback, it is best to take time to understand the other person's positive intention. People often judge themselves by their intentions yet judge others by their behavior. One primary rule of feedback is not to give it unless requested. Giving someone unsolicited feedback to correct what is considered a problem denigrates the other person and hurts the relationship. Another rule is that all feedback must be positive or constructive. Being honest is not an excuse to be negative or hurtful. If the feedback you give has not been requested, and if you cannot provide your feedback in a positive or constructive way, then it should not be said. "Constructive criticism" is an oxymoron. It is also important to avoid using a positive statement followed by the word but. The word but negates the entire message before it. Think about performance reviews. Often they go something like this: "You are so good at A, but you really need to work on B." The truth is a person doesn't remember anything that is said before the but. And the but does not soften any statement that follows. (Similarly, apologies that contain the word but are self-negating; in fact, they are not apologies, but excuses.) If any of the team members feel that there are problems that need to be addressed, it is up to the individual who perceives the problem to determine the source of the problem. The team member can do this by examining the rules and expectations of the team, the customer, and the project sponsor. The discussion of the particular problem should focus on how to fix the system, rather than how to fix the person. -/---.. -
-.c-
--
- Teamir#: Pulling'
Regarding communication, teams also need to consider their members' different tolerance levels for acceptable discussion topics. Avoid discussions about religious beliefs, politics, and sensitive issues in your personal life. Trained professionals, not co-workers or project teammates, should handle long-term personal problems. And while it is common for project team members to become friends, having to listen to daily personal issues can be quite distracting, even if those issues are positive - such as a new baby or planning for a wedding. The e-commerce project decided on the following ground rules. C
GROUND RULES OF E-COMMERCE PROJECT
Decision Making: After three tries at a consensus ruling, it is decided that majority rules, and project leader makes the decision in the event of a tie. Decisions are documented. If they are not documented, they did not occur. Decision-Making Conflicts: Team members who are bent out of shape about a decision agree to reflect on the cause of their discontent and see what they can learn from the situation rather than having their discontent drag down the team. Confidentiality: What is said in the group stays in the group. Formal review meetings provide a venue for the project team to discuss team activities with outside parties. Attribution: We are a team and all contribute to the success of the project.
MEGT MAN
Participation: We each have five minutes in every project progress meeting to describe our progress. We have a penalty flag for people who filibuster during meetings (that is, talking for more than five minutes before letting someone else say something or continually bringing up a past issue). We encourage each other to freely contribute without criticizing any ideas. Acceptance: Ten minutes is allocated to every progress meeting for letting people share their different ideas. Problem Disclosure: The team follows the rules on confidentiality. The project team leader acts as the problem clearinghouse prior to review meetings with the project sponsor or our customers. Feedback: Every month we will ask our teammates for constructive feedback on what they learned from working with us and what they would like to learn from us in the coming month. Acceptable Topics for Discussion: Team members will refrain from discussing political or religious issues and doing the "daily grind whine" on their teammates.
Meeting Guidelines Setting guidelines for meetings is the next thing the project team needs to do. The following issues should be covered: Meeting times: Determine how often and for how long the project team will meet. This is specified in the project ,.-iss-.-*
....-. -. m -.,. '
A
:,,..
;-.
.;+=::-".7:2x,.
s - Teaming: Pulling Together
w
progress reports, which are decided upon in the project agreement. It is preferable to limit meetings to one hour. Working sessions with other team members are not considered meetings. The intention here is to keep team members out of unproductive meetings, and instead keep them focused on completing their tasks to create the final deliverable.
* Acceptable Behavior: Determine acceptable behavior at meetings, such as: Deciding on alternative ways of accomplishing your goals without a meeting Starting and ending the meetings on time Having the leader fill out the meeting checklist and distribute it a predetermined number of days prior to meeting (the number of days is decided by the team) Deciding on each and every agenda item alternative for accomplishing agenda items outside of the meeting; for example, including on the agenda only those items that are absolutely necessary for a particular meeting
-
Deciding if there is going to be food at the meeting and who is going to bring it
-
Sticking to the agenda and the times for the agenda items Forbidding filibustering; say what needs to be said once and move on
Having the time keeper alert the team that the time is almost up by issuing two-minute warnings; the person responsible for the agenda item has to use the remaining two minutes to create the solution if a decision for action has not been reached Providing solutions and the means to implement them for every problem that arises; no one can complain who is not willing to be a solution to the problem Set the agenda and create a meeting checklist: Set a meeting agenda (figure4.1) and distribute it at least one day prior to the meeting. The first section reports who will attend; the second section records each agenda item, the goal of covering that agenda item, who is responsible, and the time allocated during the meeting for the agenda item. The meeting tools and meeting activities prepare attendees for what they need. The last section of the meeting checklist is to record action items. These are actions that specific team members must take as a result of decisions made during the meeting.
WEATHERING CHANGES AND CONFLICT RESOLUTION Now that you have the preliminary work done and have established the parameters of your teaming relationships, your team should be able to weather the post-honeymoon stage with fewer problems. This does not imply that there will not be any problems. Conflicting expectations can be a continuing source of trouble. Even though the team identifies its expectations for how it is going to work together during the project launch, over time, each individual's expectations will change. But rather than being a distraction, changing expectations can provide opportunities to further develop the teaming relationship. The more that team
1-'-'"
.-.I
r.-.-;*'-.
,--,-
...
- b . - - w 7 *
.
.
Lg: Pulling Together
83
fi#m k I Meeting Checklist (continued on p. 85 ...) Location:
Date:
Agenda Item
-
Start-End Time:
4
rson
G
sponslble
Tlme (From-To)
1.
2.
3.
1
4.
5.
Meeting Tools: O Flip chart O Markers O Note paper O Post-its O Pens O Name tags O Tape O Overhead O Transparencies R LCD Panel O Laptop O Handouts O Other Meeting Activities: O Working groups O Brainstorming O Presentations O Moderated discussion
.---= --,.-.-
n-..
E
riPt&
*7.,.m'-=3?-7-:.
,*, " -,.-.,,.,."'7
;
I
PROJECT MANAGEMENT
sTtf-->..,>r;,.
-..*z.*r¶Fi'v7:~--7-
.-
6 9 .k I Meeting Checklist (continued) Summary Action Items from Meeting . .--
...
Action It
,-a-
Person
Resiponsible
-
1.
1
-
2.
3. 4.
5.
members learn to constructively work through issues, the easier problem solving becomes, and the faster interpersonal issues are solved.
The Low/High Mode of Conflict A basic rule about managing conflict with Cheetah APM is to deal with problems quickly, while they are small and there is less pressure surrounding them. Figure 4.2 illustrates the lowthigh model. This model shows that if people address the underlying cause of a changing expectation under low pressure, then it is much easier to renegotiate the relationship. However, if people wait until they feel the conflict, or "high" pressure, then a lot more work and time is needed to fix the relationship.
From Destructive to Constructive Conflict No matter how often teams engage in a dialog on expectations, sometimes people have angry outbursts that can be destructive to the teaming relationship. Figure 4.3 illustrates two systems that describe conflict in teaming relationships. The circle on the left represents what occurs when there is destructive conflict: the conflict becomes reinforced and accelerates.
..
. .. *-- ..?.~..., - -.d.-~-
.
:,
--A-
-...,-.
._.,...
.
,--.
..-=--T.-zr-
.---.- --._ _. -
ning: Pulling Together
6 -
k 2 Low/high model
Commitment
Stability
Low pressure
Disruption of Shared Expectations
The circles on the right show what occurs in constructive conflict: these circles are called balancing loops. If just one person chooses to respond in a positive manner to the conflict, it will stop. In other words, it takes two to tangle. Gandhi and other peaceful leaders through the ages have proved this with their principles of nonviolence. You will find that in the long run it is far easier
,
,t--.sr-L---
S
z+-da?F=.
-*,3*pw--""L1'--n,.~-
F&& PROJECT
---,,
~
~
-
:
x
~
w %3i ~
MANAGEMET
~
~
~
6 -
k 3 Conflict Resolution
Destructive Conflict addmmes unmst
~ e i forcing n
0 Person A annoyed
0 Pemn B
Feedback
snnoyed
Replies to A In a negatlve way
Conflict Resolution
J ~ q ~ > v ~ expactahon with 5
0 -4 identifies
what waa learned
3alancinp Loop
c.3 annoyed
Ralanr Loo
positive intent
J
to take the conflict resolution approach when problems are still small in the low-pressure realm. When someone is behaving negatively, how do you refrain from responding in kind? In helping project teams communicate, we have shown that the first way to resolve conflict is to take an observer role. In this role, try to understand the point of view of
----- .--.-
--
F -
-
-.
--------ming: Pulling Tagettre~
<-- =
-"a
7&%
k I Perceived Behavior and Positive Intent
Perceived 0&avlor
Posslble Fos~ive"lnGff'n"'
Controlling: Takes over and acts pushy Motivated: Pushes ahead and gets the
job done able flaw and potential error Needs approval: Brown noses or currys Seeks a connection: Wants to get along favors Attention getting: Shows off to outs ne others
Seeks appreciation: Wants to be fairly recognized
the person with the negative behavior. Do not make any judgments about what the person is saying; just listen. Encourage the person who is angry to tell you more. This alone usually helps the person to blow off steam and ultimately begin to see the situation differently. Do hi not take negative behavior personally. There could be a number of reasons why someone is angry, none of which has anything to do with you. By staying calm and remaining in the observer role, you will serve as a role model for your teammates by showing them a n effective way to handle people who are having a difficult time. When you finally do respond to a n angry teammate, do so with insight and sensitivity. It is a good idea to repeat what the person has said to you, turning the words into positive intentions. Positive intent can sometimes be extracted from apparently difficult behavior. If, for example, one of your teammates is angry that your other teammates are missing deadlines, you could assume an observer role and say, "It sounds like it's very important to you to get this job done, and you don't feel like this is happening." When you acknowledge what someone else has said and you see the positive intent, then that person feels validated and heard. When you remain a calm observer and repeat back the angry
teammate's positive intent, you defuse the situation and reduce the chance for a negative response. Once the teammate who had the angry outburst has calmed down, you can ask if he or she would like to see how to prevent the situation from happening in the future. In figure 4.3, the circles on the right indicate how an angry team member can choose another approach the next time he or she is upset. Taking time to reflect on the situation - and to understand why one became angry in the first place - helps the team member to determine a more appropriate response.
Learning and Maintaining Good Habits of Conflict Resolution As you work through this different way of dealing with annoyances, you can start to renegotiate your relationships. In all negotiations, it is important to start from an objective point of view, rather than from the position that one person is right and the other person is wrong. Since the objective of Cheetah APM is to create the final deliverable as fast as possible, you should work with your teammates to resolve the conflicts that prevent the team from moving quickly toward the final deliverable. The first step in conflict resolution is to establish the ground rules that deal with conflict up front, setting the stage to move quickly through conflict when it occurs. When conflict does occur, it takes only one calm person to prevent it from escalating and to move toward a quick resolution. If done routinely when problems are still small, this method prevents any conflict from developing into a more destructive problem. The techniques for developing high-performing teaming behavior - assessing self-interest, developing commitment, deciding how to work together, establishing meeting guidelines, and constructively addressing conflict - may seem like a lot of work. But like any other habit, once the behaviors are learned, they are performed without a second thought. Conflict can be a n opporr*
--
-.--<--.+ -L#---
_--
-
_I..I
?.K--*---=:Y.-
mtng: Pulling Together
==-L
89
7 d '
tunity to learn the good habits that will enable teams to obtain long-term sustainable peak performance, as people move from one accelerated project team to the next.
TIMING For developing team rules or meeting guidelines during launch facilitation sessions, people should have ten minutes to develop their rules and ten minutes to develop their meeting guidelines.
~
e
9
-
.
~
-
-
-
.
~
-
-
.
PROJECT MANAGEMENT
--
Project Planning: Bringing Your Ideas to Fruition
7
his chapter addresses the strategic methods used in Cheetah accelerated project management. During project planning, ideas and dreams start to take the form of what needs to be done in order to create the final deliverable. Each step should build easily and naturally upon the previous step. All the data collected as a result of planning will help you quickly build the project schedules and the project budget. This chapter shows how a team defines the interim deliverables necessary for the project. It also gives you a good idea of how the APM methodology works, with the use of Post-its and wall templates. In this chapter, you will learn about: Assembling your information project planning approaches High-level final deliverables and their acceptance criteria Lower-level interim deliverables and their acceptance criteria
Processes Conflicts The tree diagram Milestone reviews
ASSEMBLING YOUR INFORMATION During the launch session, the facilitator guides the team members in assembling the information for each planning step and then has them record this information on the wall template for project planning. Let's look at the benefits of recording the information on Post-its and placing them on the wall template: Everyone can see the decisions made at each step of the process. Color coding the Post-its shows at a glance who is responsible for which decisions. The information can easily be changed as the project progresses. At the end of the day, the project team gets a very quick visual overview of the decisions that were made in order to create the project's final deliverable. After all of the information is collected during the project launch session, the facilitator and the project leader put it into electronic format. This includes recording the work breakdown schedule (noting the final deliverable, the interim deliverables, and the tasks needed to create these deliverables) and the budget data in a project management software tool (such as Microsoft Project) so the performance of the project can be tracked quickly and easily. In this chapter, the planning templates are shown for each project planning step. At the end of the chapter is an example from the e-commerce project, summarizing all of the information collected from the project planning facilitation templates.
There are seven basic steps for the planning stages of a project launch session. During the project planning, the project team should: 1. Identify the high-level deliverables and their acceptance criteria corresponding to the final deliverable. A deliverable is any concrete product or outcome that is needed in order to progress to the next stage of the project. The final deliverable is the final outcome of your project's activities. It is a distinct service, product, or event. A final deliverable for a service project might be a n e-commerce website; for a product project, production of 30,000 annual reports; and for a n event project, a yearly sales conference. 2. Identify the lower-level interim deliverables and the acceptance criteria for each main interim deliverable. Interim deliverables are products or outcomes needed in order to create the final deliverable. For example, a n interim deliverable for the e-commerce website would be the Internet-enabled merchant account (to accept credit card payments).
3. Identify the processes already in place that the team will use when creating its interim deliverables. 4. Identify potential conflicts that could occur when creating the interim or final deliverable.
5. Look at the overall responsibilities for the whole project and assess the work distribution and the ability of the project team members to complete the interim deliverables.
1-
-
-
-
-- /----- . ---, -.------. fivii7:.~ruject Planning: Biingng Your Ideas to fluitio ,
7-
8
I
6 . Revisit the milestone definitions created in the project
agreement and determine which interim deliverables need to have formal reviews. 7. Assess and quantify the risks for creating each of the interim deliverables. This step is covered in chapter 6, "Risks."
PROJECT PLANNING APPROACHES Two approaches are used to define the interim deliverables. The first approach is called top-down planning. The project team members begin with the ultimate output of the project and then work down into the details of the project to see how they will create that output. This approach is carried out if the team knows what high-level deliverables are needed to create the project's final deliverable. Team members who have worked on similar projects in the past may have this information already. The second approach is called bottom-up planning. The project team members brainstorm and identify all the aspects of the project that must be completed in order to create the final deliverable. These aspects are then grouped into a logical order. This approach 'is used when the project team does not have a clear idea of the interim and high-level deliverables needed to create the final deliverable. The facilitator leads the team in a technique called afinity diagramming to decide on the interim deliverables. Recall that the final deliverables and the interim deliverables are acceptable only if they meet acceptance criteria. If you do not know what makes a deliverable acceptable, you probably do not know enough about why you need that deliverable in the first place. Acceptance criteria for a service project might be: e-commerce orders that can be processed in less than 60 seconds on a slow modem; for a product project, the production of an annual report in three colors, on glossy #50-lb paper, at a print run of 30,000; for an event project, a yearly sales conference in May for ,,-s;?;-7-
96
7.
y--P-----
-'_ --..---r-
PROJECT MANAGEMENT
-*-- - -,-< . * : r -
= + .-
-.
3,000 people in New Orleans. All of these criteria can be measured. If an acceptance criterion cannot be measured, it is not an acceptance criterion, but a feature.
PROJECT PLANNING STEP 1: IDENTIFYING HIGH-LEVEL DELIVERABLES The team uses this top-down approach if the team members know the high-level deliverables. If they do not, they should start with a bottom-up planning approach. The team members identify three to seven high-level deliverables that are needed to create the project's final deliverable. Since the deliverable is a concrete event, service, or product, it is specified as a noun. Be careful not to confuse identihing deliverables with defining tasks, which are the actions needed to create the interim and final deliverables. At this initial stage, you are not looking at tasks (which are specified with a verb and a noun). The team members use colored Post-its tc identify the highlevel deliverables. Every team member uses his or her unique Postit color that was identified in the project agreement so that it is easy to recognize a team member's contributions on the wall templates. The Post-its are placed in the first column on the project planning wall template. If a team member has more than one high-level deliverable, the more important one should be stacked above the less important one, with both fully visible. In the second column, each team member identifies the acceptance criteria for the high-level deliverable(s). Figure 5.1 illustrates the high-level deliverables and the acceptance criteria posted on the project planning wall template. For the e-commerce example, the different shades represent the different-color Post-its for each individual team member as specified in the project agreement. Each high-level final deliverable is represented by its own Post-it color. This color coding is maintained throughout the remainder of the planning sections and into the scheduling and budgeting sections as well. . --
----
-
--+--*-.
. -.
& ..
.-....
--rrf.-- -
-.--
d
$ Bringing Your Ideas
.--M%---
fifccra
5I Project planning, Step 1: Identifying high-level deliverables. 1
ance Critaria
ce
'Im Deliierabl~ ria
Custc
click
, CI 1st c: inqiri
gardi j minu
h thr site. open [2Qi
.-.,l,',-,,F!,..rl;.. . , 4: 1 1 , ,.
!!:,: e
'I.::,
* :1.,:.,1,.,,.,
!.,".1
.I,,,
;,t
,,...,
\
.,:,,,:
1.
,
I<,;\,.:;
,I'
Continued on p. 99...
. , . , , y 7
9t
--
.r,
.----.
S t . . PROJEGT MAHAGEMEHT
/-----%-a--Y-3-
-
fiyww5I Prqject planning, Step 1: Identifying high-level deliverables. (continued) for IrRerirn E
m-r.==qI
"...-.w,&
r*Cr*Cr:r*7a---
@-
x..,
Project Planning: Bringing Your Idea!5 to Fruitio
fi9w5f Project planning, Step 2: Identifying interim deliverables. !step I Accept
grated with order processing. Jmer servir remrnlsl :P
click
/ CUSlO 11 beta tcsr ring llas the
T
I
require-
rrrcnt5 5~ecurcsire, lio~ting
'hrc modificatlnn5
69- 53 Project planning, Step 2: Identifying interim deliverables. (continued) -sep3, ..
. .-
...
Step T'
Prdw Con!
Procwm for Interim II
.i
-
,I:
-.
~
1
r
r
* ,, -
,,.
':
I
-,,'
,
'*?? Pr(>ii,t-~ IT,:(C ! ~ j c lr.,i,<-<.!:
LIi
,.t,
,!
i,,; 1 7 [ . l : :
i;>;~-,i:>s )l.;,>r,I J ; !
;,
.. ,,:
; :..I;
.
, i ?,,'.
,,
--,
I
: I ; . : : - l l - : ! ~ : ~ - ; : ? i ~ ! : : ; ( j ~ - ~ ;;\;:,;
"
.,(;,.-\
:, ,. ! :
$ ;
L,
. # . (
! i I~ 1 ; >"-
71
17tt.
ir~r1.~1,.t.
L;II
;,!:!:.irit-:=. ,>I * , i i , .
0;2....
8
I
!1;1r;, [:
r!-.:-, 1 1
;~.i!y7!~:'~
:
,-I:
:;lit!,
r l ,,">
7 - l r :!:TI.
, - ! ! *I!-I~I!-J<.
! # . . , . 4 i \ I >bf,
!>.gl?: ;I,-{:(>;:?r
. ,,.. ,, I,, I;,,.;! ,, , ,, ,;-.,., ; i . . ; '<,.,.,.....' 3 . ....
,
,[
' j : l ~ ~ ~ ~ ~ - i , :#:.,:.:!
I : ~ I # ;. r . . 8 1 i ,~ z ,--;.,!-E-~,
1>::.7<
y;.;J!].: 1 ,-,.,!,'
..;,-,:!,\ ,
,,<,;;,r, Iill;3v~+
~TOCC-L:
i: :i,;!I
::I,
!
.;::.
-'I
a::,\
111 . , \ I
j t ; : - ~ i ~ : !I:: ~
' ; 1,
<
111; 7 ,
L < ,
T7,(A!ll
l!i)~i:ic-~:
. .I;;(,.:
.,,, $ p f l ~ : ; ~ ~ ; , 4 ' .,l,i,!:-
%:I ,;T-~..I i L!:
I,, t.;
I-
,,{It
:,:'TT~,
(.,:I7)>,,-:
;!.I!.!!
I ,,,
, > ! v : , : : ' *,:I!:;:
..,ir\ <,,,',
1'. -1
-;;br;-r<
!
,:I
!!:., :.
'.l;y$;[~r:,
I ,;'I:,:!-
7
',
1,
is,1i!
.,;,
;,?;-
.:,;<; ' ,\,;:<,
t c :!.II<. ~
,.,,
-
,>!.,
,
,..*;.
::.i,;l:
.
!;.!a
,:\
2:: :,:!,::,,,
F ~ i * i k ~yT I X :~I(:I?: p y n c v x < 1 - 1; ,,.':I; ,!#:%! r \ i . ~ ; ~ ~ j : ~ l I; , ,, ,,!l ,~ , 1! : ~ -
lr~?;>>c
!1:\.:51-2!..
m
'>!!#I
I(.'-.!,-;.:,
'-',t;!(.l?l.
:.:~~>:-~pi;~k tvL:? 1 :jr:,{,p\q !3t : i j > c ~ i g p 1 .q..--., ,&, l l ,81.. !>> 1 .,.,. ,!hm!I:;.!:-. I , I
,- .,
-
%.,=
3 . 7
I
,
;
I
-8 ,, .
.-JT--.
-.. ...-.."-,
fi
.
. , ,
:
.,
i?r, .,-:: , , ,.
,
,
-
r;
.
i-h s .
....;!v! ,I:.,
., ..::-. . ,.
,,
:--r.r.,\,:+;,:
i,7:,ll;:,
,
:I
p , ,
,-----"--A.-
& bring@ Your Idea:
im:,t.,;::)p
: :,>.
,-,,2,!,.,(-.-;>!-
,:.k3t
,,(>I::l,
!;., ; > >., .
-
--..fin-
-.1.1.1
PROJECT PLANNING STEP 2: IDENTIFYING INTERIM DELIVERABLES The team uses this top-down approach if the team members know the high-level deliverables. If they do not, they should start with a bottom-up planning approach (which is addressed in the next section). In this step, the team members identify no more than seven interim deliverables they need to obtain in order to create each high-level deliverable. In planning Step 1, the team specified a unique Post-it color for each high-level deliverable. The associated interim deliverables are identified with the same Post-it color. The team uses one Post-it per interim deliverable and on that same Post-it identifies the acceptance criteria for that interim deliverable. Often, team members want to jump quickly into defining tasks that they need to complete in order to create the deliverables. It is easy to identify when this is happening and it's easy to prevent. The facilitator needs to remind them that an interim deliverable is specified with just nouns. If they put a verb and noun on the Post-it to specify the deliverable, then they are defining tasks needed to create deliverables. Team members record the acceptance criteria on the same Post-it under the interim deliverable title (figure 5.2). Then when they post them on the project planning facilitation template, they layer them so that just the interim deliverable is showing.
PROJECT PLANNING ALTERNATIVE: BOTTOM-UP PLANNING If the team does not have a clear idea of the project's high-level deliverables, the facilitator leads them in a three-step affinity diagramming activity.
Affinity Diagramming Step A: Brainstorming During this step, the team members brainstorm individually to list everything that is needed to create the final deliverable of the project. To foster a broader range of input, the team members do not
6-57
Affinity d i i m i n g Step A: brainstorming What do nl
want?
How dors i t R I with
Easy 4gfir navigation
n Link 16
wt1I>sitr?
Role of existing 5talf
Shopping
pq Online
o'nc-click ordering
crayittiyi For site
speak during this step. This is especially important in situations where some of the team members may already have strong points of view about what must happen in the project. Suspending discussion at this stage gives everyone an equal voice in determining what has to happen to create the project's deliverable. Follow these instructions for brainstorming: 1. The facilitator passes out pads of three-by-three-inch pastel yellow Post-its and has everyone on the team individu-
ally brainstorm to come up with everything that the team must do in order to create the high-level deliverable. 2. The team members write one idea per Post-it. They do this without speaking to one another. The allotted time to complete this step is ten to fifteen minutes. 3. The team places all the completed Post-its on the wall in random order (figure 5.3). .
Affinity Diagramming Step B: Grouping In this step, the team groups its ideas into categories and then dis&cusses them. Again, the first part of this step is done without any verbal communication among team members. 1. The team takes five to fifteen minutes to categorize the Post-
its into no more than five groups. They do this without speaking. Sometimes a Post-it will be moved back and forth between categories. When this happens, the facilitator advises the team to create a duplicate Post-it so that it can be included in both categories. 2. Once the Post-its are categorized, the team has a discussion about the titles for each category. The Post-its used to identify each title should be of a contrasting color - say, pastel pink. In figure 5.4, the titles are depicted in black. The titles typically correspond to the team members' specific roles and responsibilities.
Affinity Diagramming Step C: Deliverables and Acceptance Criteria Once the team's ideas have been categorized and discussed, the team organizes the Post-its into subgroups, identifying the name of each subgroup with Post-its of a third color - say pastel green. The pastel pink Post-its become the team's high-level deliverable~,and the pastel green Post-its become their interim deliver-
JECT MAN)
fifrcra54-Affinity diagramming Step B: grouping
Link
rtl
x -k ~ s it? e
inli to
hank
svsre
I
iet?
ables. The pastel yellow Post-its represent the acceptance criteria, and are placed under each category. Figure 5.5 shows the highlevel deliverables, interim deliverables, and acceptance criteria (depicted in black, white, and gray, respectively).
Affinity Diagramming Step D: Color Coding In Step D, the team develops the color coding for the high-level deliverables that specify which team member is responsible for which deliverable category. For each pink Post-it, the team assigns another bright color Post-it to show which team member is responsible for which category (figure 5.6). This color-coding is ,,,,..'* -. *b..
n-'
--7
9
,,.
-*--,-
3'--.,-,4
---~,~..~*:-~--G%~Z-~,*L
- Project Planning: Bringing Your Ideas to Fruitio~
>
-
fiyccra55 Affinity diagramming Step C: deliverables and acceptance criteria
Customer
Customer
Customer
mmm Rmpl training
(:~l\tolller
pswe$si&g
rmricl'l
systems
training
service?
manage-
readlness
readlness
existing staff catalog market?
RmFl
load ume
program
server
processing
L ~ n kto
Online
fi9m56 Affinity diagramming Step D: color coding
mmm processing
restricts?
customers
customers? training
systems
Systcm integration
customers use il?
% I
bar.
when?
catalog
<;,,,.?*.?.-,
-.--! .-,:
: :
A*5<.
.c!:Ty .?'+,
,,,..+-,
.+qe..,-;::.,.,..
- Project Planning O&hnb
,
9
,
.:.-
*?.~.F-P&.--:W,
your Ideas to'~ruition
'"
maintained throughout the remainder of the planning phase and into scheduling and budgeting. Once the team has determined the high-level and interim deliverable~using the affinity diagramming technique, it transfers this information to column one of the project planning facilitation template (see figure 5.1). The team summarizes the acceptance criteria for each high-level deliverable in column two, then places the interim deliverables for each high-level deliverable in column three. The team records the acceptance criteria right on the interim deliverable Post-it. Now the team has the information it needs to proceed with the remaining project planning steps.
PROJECT PLANNING STEP 3: PROCESSES Once the project team identifies what it needs to get to create the final deliverable, it needs to identify processes that may already exist to create the interim deliverables. For example, if it needs to purchase items to create the interim deliverables and the company has an existing purchasing process, then it will need to follow that process. If the team does not know about - or does not follow - company-established processes, it puts the project at risk in terms of both schedule and budget. To identify the appropriate processes, the team can use the following method: 1. Each team member identifies existing processes that may be needed to create the interim deliverables. If there is no existing process, then the team member does not have to create a new one at this point. 2. The team looks at each interim deliverable for which the team is responsible. They must determine if there is an existing process that they must use or if there is an optional
process that would help in creating the interim deliverable. If there is a process available (mandatory or optional), they record the name of the process on a Post-it in that deliverable's color Post-it. 3. The team records the impact that a process will have on cre-
ating the deliverable. Using the e-commerce example, if the programmer needs to bring in an outside contractor to create the shopping cart application, the team might have to use the company's consulting contracting process. This may take up to a month to get through the approval cycle and, therefore, will impact the time needed to create the shopping cart. 4. The team puts this information on the project planning facilitation template in the fourth column. Figure 5.7 illustrates this for the e-commerce project.
In APM, any existing company processes that the project team must use in order to create the final deliverables may slow down the project team. If a process that a team has to use is going to significantly slow down the project team, it is up to the project sponsor to reduce the cycle time of those business processes. While it is outside of the scope of the team to redesign the organization's inefficient business processes, the need for speed in an accelerated project does point out where improvements need to occur within the organization's business processes. Figure 5.7 is an example from the e-commerce project. Debra, who is in charge of the finance deliverables, has specified that many of the existing finance processes have to be used in order to create the finance interim deliverables. In chapter 4, it was noted that Debra is a reluctant participant on this team and only sees the project as something she must par-
.....:-..
wYY~ I : :.-:. =;-
..-....-7xlF '"*??--=.
,. ...~
,wq-.-,,:,73,97,:
= a : ~ ? c A * . . - * 7 - ~ .
- Projet:t Planning:~Angingyour Ideas to Fruition
,---.w. --E,i
f i v 57 Project planning, Step 3: Processes !sfel
r~er
ap 2 :rim Doliwrat eria
Integrated e-com- Customers can order products merce site for from our website in less time, product ordering at lower cost, than any other way, and all the data is integrated with order processing.
'
Project plan System requirements Project status reports Project plan
~ u s i & m e r s e ~ cI eCuatomers car1 order in rrq i click: Irom mai n page, ar cerv I CLI
Customer requikmeiis Custnnlrr servicr plan Cuqtcrn~ercervice training mallil
I
e-CoGnnerceiveh- 'ISeasy ro navigatr lo or;l 011 01 the cvehdle an :ame look anti feet o
mom
site
I
1C>L
-1
.L,.
Securr sir!c hosting
..:..
.-#*..
way
--
I
Graphin
,I
1 test plan - . Site rnndi~cat~ons
Continued on p. 11 1...
--. ---
-*v-e-qw
rln
2x2
+-.<-r=-
---
T--.. ----.-*--
UECTMANAGEMENT
4--
= ?
>k?'--
-3
fig-
,-
57Project planning, Step 3: Processes (continued)
. . 1 1 . .
-.;-
=-
-
-
.
--
..
- Projeclt Planning: ~
--. --
..-
k ~Your i Ideas n ~1
--
I
ticipate in to keep her job. Debra is saving herself a tremendous amount of work by requiring that all the existing systems in her part of the operation be used. However, this is creating an additional burden on Ed (the programmer) with his programming deliverable~and on Bruce (customer service) with meeting the customer service requirements. It also may ultimately hurt the overall performance of the final deliverable. When someone on a project team falls back into "this is the way it's always been done" mode, it is the responsibility of the project leader to perceive the true impact of using existing business processes on the project schedule and the performance of the final deliverable. The project leader must then determine whether those processes should be used.
PROJECT PLANNING STEP 4: CONFLICTS Other projects may conflict with interim deliverables that the team is planning on for the project. This part of the planning section is where the team specifies what else is going on in their environment and how that will impact the project. For example, if the team is planning an event where they need the president of the company to perform the keynote presentation, but the president is going to be out of town, this particular interim deliverable will be significantly affected. When evaluating conflicts, the team members must look at the projects and processes outside of the project's scope that may impact each interim deliverable. For example, the sales team on the e-commerce project is also working on the annual conference and has planned to create an online conference registration system. This might tie up inhouse resources for web design and programming. The team records the conflict on the same color Post-it as the deliverable it affects. The team not only needs to identify how these conflicts may impact creating the deliverables, but the team also should list their suggestions for overcoming the conflicts (often termed
"work-arounds"). Figure 5.8 shows how the project planning template addresses conflicts in the e-commerce project.
PROJECT PLANNING STEP 5: THE TREE DIAGRAM Step 5 summarizes each team member's task for creating each interim deliverable. By creating a tree diagram, the team can check for overlap or duplicate deliverables. The team also looks for situations where one team member may be better suited than another for any of the assigned interim deliverables. The tree diagram is also used in the scheduling activity described in chapter 7. To create the tree diagram, the team members simply copy the interim deliverables that they identified in Step 2 (or in the bottom-up planning process) and put them on branches of the trunk of the tree diagram. The team reviews the tree diagram to check for duplicate deliverables and to make sure that the correct team member is creating each interim deliverable.
PROJECT PLANNING STEP 6: MILESTONE REVIEWS In chapter 3, we discussed the way the team should identify the reviews and milestones that they know might need to occur. In this step, the team looks at each of the interim deliverables and determines if it needs to have a milestone associated with completing that deliverable. A rule of thumb is that if there are one to two other people relying on the successful completion of an interim deliverable, the project team should consider having a formal review of the deliverable. Additionally, if three or more team members have interim deliverables due at the same time, the team may want to consider scheduling a formal review/milestone to ensure that all team members are progressing on schedule. As mentioned in chapter 3, the team needs to limit the number of milestone reviews to no more than ten. Since there are already three milestone reviews for every project - kickoff, final deliverable complete, and .~.. .
- Project
)ur Ideas t~
f i 9 . 5 8Project planning, Step 4: Conflicts 31
dance Griieri
tomer sen lirementsl rice ing man1la1 Custome r beta test
inqlliries from customer garcling website in unde min.utes 191, Irl I M V ~
5eci iur~r l l thr I lte
w r n r look 5 dl-
.. *
continued on p. xu...
DJECT MAN
fi9ccra58 Project planning, Step 4: Conflicts (continued) Step4 )roJectConflic Cheetah project management
Impact: Have to input data and keep information up to date.
nd finance system integration 5nsure that sales gu)IS know " ihnut ncw rce appli-
......
*
- Project Planing:
to Fruition
:.
6 -
59 Project planning wall template, Step 5: tree diagram Pmject plan
Alice
Systent rcquircs
Project
menu
Leader
t'tu~cctstnkus
repofis LLcssons learned
L
-b menrs
c,,
I -
Chris
Color-Coded Key
Alice Project Leader
Bruce Customer Service
WECT MAN
Chris Webmaster
Debra Finance
Ed Programming
lessons learned -this limits the number of milestone reviews at this stage to seven. The facilitator guides the team in determining the project milestones, starting with the interim deliverables and assessing whether the completion of each one would be a milestone requiring a formal review before the project can progress. The team also looks at who needs to be involved in the review and when that review has to occur. Using the project planning wall template for milestone reviews, the team identifies the following, using color-coded Post-its: Milestone reviews The reviewers The approvers The dates of each milestone The information collected here is used to build the milestone schedule, which is presented in chapter 7, "Scheduling." With the milestone template, it is more important that the team identifies the milestone reviews they need to have, why they need to have the review, and who needs to be involved in the reviews. Dates should be specified if a project team member knows how much time he or she has to get a task accomplished. If the date of review is not clear, it can be set as to be determined (TBD)and identified when the team creates the milestone schedule. In the e-commerce project, Chris the webmaster and Ed the programmer know from previous experience that the test verifying that all systems are go has to be completed at least a week before the go-live date. This allows time to make any corrections if problems come up. Figure 5.10 shows an example of the project planning wall template for milestone reviews for the e-commerce project.
-.
-..:.-
-
-.-
-
+.---
-
- .. ___ ---.-- _ :Bringing 'Your Ideas It
_
_&
-.
-+ .-
6 ~ 5 7project 0 planning wall template for Step 6: milestone reviews 'project M I l b 'Purpose of Review IRevlew storle Review I (Intierim
Deliverable)
IArknnwml ppa V W U
it(I Move
I
~
~
~
Prrtjcr,t li~c-Ctrfl' Is plan done in wl- P~-ojr.cttcam ficient detail to start and prclicct launch the project? facilitator System Understand impact i Project team requirements on existing systems and all components needed Go live Ready to handle on- [Project team line orders? lessons learned What did we learn? iProjecr ream report
3rwat-d FC
r sl)on\or
Project leader
1
I
/Project 1 sponsor 'Project
l
,If) iI
sf&. *f...,
.
... .
I
!
' i b \ ~ r r2l ~
(one riay aher project launch session) March 18
June 2
Tellmaster :March 9'
L - Can ~ S I
- site rvorli
Inl-uie
hlict.
r'rc,ject Lcadrr Customer Service
...,-;C..'7---.'-:7'-
I
-
C
011-i\
I
\'a'c.h Designer Finance
- -.. &ak- PROJECT MANAG'EME@'~
;-,--.-,..
-T..
-
tram
-..,.-:-.. +-,
--
'm
it1
P~.ogra~urning
.-,.
Tf;T--TT---:-w.:,
TIMING To do all of the planning steps should take about eighty minutes: Steps 1 8- 2, identify deliverableslacceptance criteria thirty minutes Step 3, identify processes - ten minutes Step 4, identify conflicts - ten minutes Step 5 , tree diagram - ten minutes Step 6, reviews - twenty minutes
....
.,
.-.-...-gSpg*8.--. -. :--.
TI .
u - Prgie
lul
....
, ,.
.. . . .. . ..__ ,
____ -.
,r$-*7y,.
,
,--.. zm:Trn?!---.-:~T
g: Bringing Your Idea:
Project Risks: What Could Go Wrong?
isks - every project team faces them. In chapter 3, we noted that team members must specify how much risk they can tolerate while creating their final deliverable. In this chapter, we'll examine the way team members can assess and quantify the risks that they may encounter while creating their interim deliverables. We'll also look at how to determine the countermeasures that team members need to develop for each risk based on their risk-tolerance level. These countermeasures can be either preventive - to ensure that the risk will not occur - or contingency plans designed in case the risk does occur. This approach was developed over a ten-year period by adapting a reliability engineering technique called Failure Modes and Effects Criticality Analyses (FMECA)thatis used extensively by reliability engineers for complex military and aerospace projects. This approach will be discussed in greater detail later in this chapter. The approach presented here has been tested and verified in a wide -.
= -.:
-
-.-..-.7
>,
,.
--- --
---
-.
& PROJECT MANAGFl
A >
,--
.:--
-
. T
w-
.=:=-
-
variety of project settings. It works well in identifying the major risks that could derail a project. It helps a team to know that at an early point it can identify the risks involved in the project. This helps the team to focus on how to get the project launched during the other stages, instead of being distracted by all the things that could go wrong. It is the role of the facilitator to bring the team back on track if it wants to jump right into identifying all of the reasons why the project might not succeed. The facilitator should remind the team members that they will have the opportunity to identify those reasons in the risk-assessment section. By examining potential risks, risk assessment actually alleviates the shadow of doom and gloom that can slow down a project and hurt team members' motivation. There are four steps to completing the risk-assessment process: 1. Identifying the risks 2. Quantifying, or calculating, the risks 3. Developing countermeasures 4. Assigning responsibility for completing the countermeasures
IDENTIFYING THE RISKS Risks can be anything that the team thinks of that could prevent it from successfully completing any of the interim deliverables. The idea here is not to quibble over what is or is not a risk - rather, the goal is to record anything that team members think could prevent them from creating their interim deliverables. In this section, each team member individually identifies the risks for each of his or her own interim deliverables and for the interim deliverables of his or her teammates. One of the reasons that people skirt around the issue of identifying risks is because it could point out a potentially embarrassing competency issue either with their own skills or with the skills of a team member. Keeping the risk identification anonymous helps the team to better bring all of the risk issues out in the open.
The team members identify all of the risks by recording each one on a yellow Post-it, using one Post-it per risk. To help keep the assessment of risks anonymous, all of the team members use the same color Post-its and black Sharpie markers with medium tips. The team uses the following process for identifying risks: 1. The facilitator gives the team ten minutes to record their risks and encourages the team members to try to limit the number of risks for each interim deliverable to fewer than five. 2. Once the team members have identified their risks, they place them on the risk template that is on the wall, near each respective interim deliverable. Duplicate risks are combined. 3. The team members review all of the risks that have been posted by all of the team members. When team members review each other's risks, they may think pf more. These can be added at this point. Figure 6.1 illustrates the first step of identifying risks for the e-commerce project. This example shows the e-commerce team members identifying eight risks for the five high-level deliverables. Typically, team members will identify more than eight risks for a project. Many risks are similar and can be grouped together. For practical purposes when doing this activity, attempt to limit the groupings of the risks to three per deliverable.
QUANTIFYING, OR CALCULATING, THE RISKS Criticality analysis is an important part of the Failure Modes and Effects Criticality Analyses performed on complex military systems. In this complex analytical technique, the reliability engineer along with the design and systems engineers estimate the probability of the risk events occurring. Assuming the event does occur, the engineers estimate the impact it would have on the system achieving its overall mission.
_
-
_
__.......... -.
-...
..
I - -
3:
....
.,.
... ............................ . ,
What CouldI Go Wrong
In Cheetah APM the project team members perform their own criticality analysis on the risks they have identified - but they do it in a very simple way using quarter-inch colored dots. There are two steps to this process: voting on risk probability and voting on risk impact.
Voting on Risk Probability The team members look at the probability that each risk will occur by voting on every risk posted. Each project team member votes on every risk posted - not just the risks for his or her deliverable~.They do this very quickly using a highly scientific technique called the "gut-feel-index" (GFI).They use the GFI because they may not be able to quickly articulate the factors leading to their ratings. If this is done quickly and the team provides the first rating that comes to mind, the risk assessment may have greater accuracy than a more analytic approach. It is important to remember that if a project is of a nature where human life may be at stake due to a failure of the final deliverable, the team should do a full criticality analysis. For more information about full criticality analysis, look into MIL-STD 785, Military Standard Reliability Program for Systems and Equipment, Development and Production, which provides details on how to do a complete Failure Modes and Effects Criticality Analysis. To calculate risks for many projects, the GFI approach provides sufficient information to proceed. The facilitator hands out two colors of dots to be stuck on each Post-it. The dots indicate the expected probability of each risk. Using their GFI, team members vote on every risk identified. Table 6.1 illustrates how the risk probability dots are color keyed. For five to ten minutes everyone votes simultaneously, without speaking. This process helps everyone on the team to have his or her say on each risk probability. It has been found that this
-
f i r 6 . 7 Project planning template: identifyingthe risks ste P D ect Risk-
re Causes lI~-l,:"d
Tor bunte measure
too much clutter
able to handle
Mpersonnel ~
W
makes
programming too com-
Alice Project leader
Bruce Customer Service
a
Chris Web design
Debra Finance
@ ~ e dHigh Probability O ~ e l l o wMedium Probability @ ~ l u eHlgh Impact
,---
.~
4-1.-
'_
--
-
--
.d.. . ,. ...77.
1 _?
---,
-
--.>.-,LI.
-----
Ed Programming
@ re en
Medlurn Impact
-.-<-- -.
What Could Go Wrong
-- -
, '---
Z&!h 6.1Dot Voting for Risk Probabiii Sablllty of Occurrer
Mec
Low
-
I
1i)rlc ~-cci~ i o ~
Rirb Itirntificd
0 1 1 rycllolv riot
N o (101
method provides a much higher level of disclosure than if the participants engage in a discussion regarding the risks. It is also much faster - up to ten times faster - which is the aim of Cheetah APM. By ranking all of the risks, each team member is obliged to assess the overall riskiness of the project.
Voting on Risk Impact Once the probability of the risks is assessed, the team votes on the impact that each risk will have on creating the final deliverable. A risk might have a significant impact on creating an interim deliverable but might not have that great an impact on the final deliverable (or vice versa). The importance of looking at the impact of a risk event on the final deliverable is easily seen in the example of the space shuttle Challenger disaster in 1986. The cause of the explosion was shown to be the effect of cold temperature on the O-rings in the rocket launcher. The probability of the temperature being as cool as it was that morning in Florida was very low. However, the impact of the low temperature on the O-rings in the rocket launcher was very high - in fact, catastrophic. The team members vote on risk impact in the same way they voted on risk probability. Each person votes on every risk in a fiveto ten-minute period. This time, the team uses blue and green dots for voting. Table 6.2 shows how the risk impact dots are color keyed.
.
.-
#A PRO
Gh%6.2Dot Voting for Risk Impact Impact of Occurrence
-
-
High
Medlur I
Rlhk
~ ( l r r ~ ~ i l i u r l C)nc blue ilot
Orir grre11 dot
No t l o t
Interpreting the Results When the team is done voting, it should be clearer which risks are significant. The Post-its with the highest number of red dots (high probability of happening) and the highest number of blue dots (high impact if the event does happen) are the risks that are the most significant. Dot voting gives the team a rapid visual display of those areas where there is consensus and where countermeasures should be considered (figure 6.2). The team can also put all of the information in a spreadsheet and get an average rating for probability of failure and impact significance. The visual display, however, is usually enough to alert the team to areas where they need to develop risk countermeasures. In figure 6.2, the risk of losing management support received a high probability rating from three team members, and a moderate probability from two team members. All five team members ranked it as having a high impact on creating the final deliverable if it did occur. Some of the team members did not place dots for probability or impact on the next two risks. This means that they consider this risk as having low probability and low impact. On the fourth risk, however, every team member gave a vote of high probability, with three team members indicating a high impact and two team members indicating a moderate impact. All of the team members judged the fifth risk as having a high impact, but only two rated it for probability of occurring, giving
-.... . --,-
-
.
_.".-
..
.,.-..:.-
5
+ . .
.
..-. ..
-
-
:et 'Kiks: What Could Go Wrong'
-...
it a moderate probability rating. The remaining risks received lower impact judgments and lower probability ratings.
DEVELOPING COUNTERMEASURES A risk countermeasure is a preventive action or a contingency plan. Here, the team addresses the risks that the dot-voting process showed to be significant. At a minimum, the team needs to identify risk countermeasures for the risks with a high number of red and blue dots (more than 60 percent of the team voting red and blue). Depending on the risk-tolerance level, the team may also need to develop countermeasures for Post-its with a number of yellow and green dots (moderate probability, moderate impact). The risk tolerance, as set forth in the project agreement, specifies the amount of risk (or uncertainty) the team is willing to accept in creating the final deliverable. If the team is willing to accept a low level of risk, then the risks they have deemed as having at least a moderate chance of occurring, with at least a moderate impact, need to have countermeasures as well. Even risks that the team decides are not significant enough to warrant developing a countermeasure should be documented. The reason to document all the risks identified is that often people external to a project will identify a risk and ask a project team member what he or she is going to do about it. Having documentation of all the identified risks allows the team member to explain that the team considered the risk but determined that it did not warrant a countermeasure. For each risk, the team determines if there should be a countermeasure based on the voting and the risk-tolerance level. In column three on the project planning wall template for risks, a Post-it is placed to indicate "Yes" for the risks that need countermeasures (figure 6.3). In the e-commerce example, the team first discusses the risk tolerance as identified during creation of the project agreement.
f i r 6.9 Project planning template: quantifying the risks
dering page because of too much clutter
Project leader
Customer Service
Web design
Finance
Programming
@ ~ e d High : Probability O ~ e l l o wMedium : Probability @ ~ l u e High : Impact e ~ r e e nMedium : Impact
.--- . -
-
-+*".h4-~---.--
y
_ *7 =-+7 *.
------ - -
- project-kks: What Could Go Wrong
2.t&
PRO
The team decides that since it can tolerate very little risk for completing the final deliverable, it will develop countermeasures for any risk that has over three votes for at least medium probability or impact. The facilitator should advise the team to keep the risks on the template even if it has decided not to formulate a countermeasure for that risk. The documentation of the identified risks and the team votes provides an easily accessible decision trail showing why the team came up with countermeasures for some risks and not for others. During this stage, the team documents the countermeasures on pastel blue Post-its. (Remember, each team member has already been assigned a unique bright-color Post-it for his or her respective deliverables.) Pastel blue is reserved to represent risk countermeasures in APM. Whenever a pastel blue Post-it shows up on a template, the team members immediately recognize that it is a risk countermeasure. For each countermeasure, it is determined whether a preventive measure or a contingency plan is needed. If the countermeasure is preventive, the team annotates that with a "P" on the blue Post-it. If it is a contingency plan, the team annotates that with a "C" on the blue Post-it. Figure 6.4 illustrates several risk countermeasures from the e-commerce project. In this example, the first risk countermeasure is preventive, as annotated by the "P." The project sponsor obtains the management-signed endorsement, based on the business case developed in the project agreement, and has the funding for the project put into a separate account. This ensures that the team has the funding needed to complete the project. The second countermeasure is a contingency if the programmer becomes unavailable. This countermeasure is not as aggressive as the first one, as the team does not think that this event has a high probability of occurring and only three people think that
fi$wm6. &Project planning template: developing and coding countermeasures Step D ml Hnal
project Risk,.. .*
ahb
't'
te fnlo psisling lt.gacy
d& PRO,
it would have a moderate impact. The other countermeasures are identified and annotated according to whether they are preventive measures or contingencies.
ASSIGNING RESPONSIBILITY FOR RISK COUNTERMEASURES Some countermeasures truly are a team effort. However, it has been found that when everyone is responsible, no one is accountable. With Cheetah APM there is single point accountability. This means that one person is responsible for each deliverable, and this extends to the risk countermeasures as well. In the fifth column on the project planning wall template, the team identifies the member responsible for each countermeasure using that team member's role-specific color Post-it to identify him or her. Figure 6.5 is an example from the e-commerce project of the team members responsible for each countermeasure. Figure 6.5 shows that even though the countermeasure for the programmer becoming unavailable is the responsibility of the project leader, the person responsible for developing the contingency plan is not the project leader; it is the programmer, Ed. The other people responsible for the countermeasures correlate with the project team member roles. Facilitating the risk section of a project launch event includes moving the process along. People have a tendency to run away with doom-and-gloom scenarios and war stories, especially if they need a break. The role of the project launch facilitator is crucial during the risk session to keep things on track and on time. In the sample agenda supplied in chapter 2, the risk session is scheduled right before lunch. The lunch break usually motivates the team to complete the risk template in a timely manner.
TIMING Altogether, the risk assessment should take about an hour: Identifying risks - ten minutes .----:-..- - .-...,-.*
.------
-.
-
. .J.-f-f-
9 x - Project Risks: What Could Go Wrong
-
7.
f
i 6.5Project ~ planning template: determining countermeasure responsibilities ! kina
1 measu
Voting on risk - fifteen minutes Deciding on which risks require countermeasures - ten minutes Developing countermeasures - twenty minutes Assigning responsibilities- five minutes
--
?.
-
-..
- .,--.
..,.
-.
--.-.-
....
..,.
-
, .
-
project Risks: ~ h a(t
..--
.-..I.--!-?.
rong?
---.---. -..-13 5
Scheduling: You Want It When?
7
cheduling is extremely important when you are working on a project, especially in Cheetah APM. You should always make sure that you have plenty of time to complete the tasks needed to create the final deliverable. Using the information it has found during the project planning stage, the project team builds the following three schedules: Milestones schedule: the project timeline Deliverables schedule: when the deliverables will be done and the dependencies of the deliverables; also shows the duration for each interim deliverable Activity tasks schedule: the tasks that need to be completed to create each interim deliverable; used to create the labor time estimates and the internal cost budget for the project.
The milestone and deliverables schedules are created on WriteOn Cling Sheets (erasable sheets that cling on the wall) so that team members can easily make any necessary changes.
MILESTONES SCHEDULE In chapter 5, the team identified the milestone reviews needed for the interim deliverables. These reviews are now used to make up the milestone schedule. The team creates this schedule on erasable whiteboard paper (Write-On Cling Sheets), using three-bythree-inch pastel yellow Post-its. The milestone review title is written in red ink on each milestone Post-it. We use this convention so that the team can quickly recognize all the significant milestone events. It is recommended that the team use a separate one-by-two-inch pastel yellow Post-it to record the milestone date because as the team lays out the milestones and the deliverable~schedule, it is likely to change the milestone review dates as it discovers new dependencies among the deliverables. As explained in chapter 5, there are three milestone reviews standard to every project: project kickoff, delivering the final deliverable, and lessons learned. The team should try to identify no more than seven other milestones, so as to follow the rule of thumb that a project should have 10 milestones at most. In some cases however, such as in our example, there may be a need for 11 milestones. It's important to keep in mind that milestones are significant. If there are too many milestone events indicated, then they lose their significance. Figure 7.1 illustrates the milestone schedule for the e-commerce project. The first milestone is the project kickoff, the interim milestones are related to the project's requirements, and the last two milestones are Go live and Lessons learned. The Go live milestone is the final deliverable.
-. .
---
1:
-
-
.
.
.
d$ PROJECT MANAI
.
-.
--
. -.-- ,.
-
--
,-
R$
-
You Want It When:
--
.
DELIVERABLES SCHEDULE Once the timeline is established, the next step is to decide when the interim deliverables (refer to figure 5.9) will be done in accordance with the milestones on the timeline. It is very important that the color coding be maintained during this step so that there is no confusion about where all of the information is placed on the wall template. From the tree diagram, the team places its interim deliverables on the place in the milestone timeline where they will be completed. Rvo one-by-two-inch Post-its are used to identify the start and completion dates for each interim deliverable. The team members place each of their color-coded deliverables in the same row across the schedule template to make the schedule easier to read. Figure 7.2 shows the deliverables schedule of the e-commerce project, including the start and completion dates. The interim deliverable~were taken from the project team diagram (refer to figure 5.9). After the team estimates the start and completion dates for the project, it evaluates how the deliverables are dependent on one another; if needed, modify the start and completion dates based on these dependencies. When the start or completion date of one deliverable is dependent on the completion of a previous deliverable, a dependency line is used. With this method, each team member receives Write-On Cling Sheets and a colored marker which corresponds to his or her color-coded identity. Using the color-coded markers, the team members show the dependencies from their own interim deliverables. The dependency drawing conventions are as foJ1ows:
I
I
The dependency line is drawn from the originating deliverable in the originating deliverable's color. For example, in the e-commerce project, the customer requirement deliv-
.
..-. --
>
fipm Z Z The derirables scheduie dthe e-commerce project Pmject plan
Project status
System
reports
Customer
Systems
Dntabaw
requirements
integration
Go live.
Lessons
erable starts after the team leader completes the project plan deliverable. The line on the deliverables schedule is drawn from the project plan (the originating deliverable) in the project plan color (pink) to the customer requirement deliverable. The reason for this convention is that each team member can quickly look at his or her own interim deliverable and see which other team members are creating deliverable~that feed into his or her own deliverable. For each dependency, there is a distinct line that comes out of the originating deliverable. This is so team members can see how many other deliverables are dependent on their own deliverable. Where a dependency line crosses another dependency line, a semi-circular bridge is made over the intersecting line. In figure 7.3, the A with the circle around it illustrates this convention. Where a dependency line has to go through an interim deliverable in order to get to another interim deliverable where there is a dependency, a dashed line is drawn in the originating deliverable's dependency color. In figure 7.3, the B with the circle around it illustrates this convention. The key to this method is the visual representation of the project schedule; therefore, maintaining the integrity of the color-coding is essential.
ACTIVITY TASKS SCHEDULE The deliverables schedule shows the duration of time needed for creating each deliverable and the due date. It does not show the effort needed to create those deliverables. .. .
&& PRO
AGEMENT
-
6-
7!7Detverables schedule with dependency lines
Project Leader
17inanre system requirements
Systems
requirements
integration
To determine what needs to be done and the effort required to create the deliverable, team members identify the tasks that they need to complete in order to create each deliverable. They also must estimate the time and effort needed to do those tasks. Each team member develops his or her taskltime estimates using the template shown in figure 7.4. Figure 7.5 illustrates the tasks identified for one of the interim deliverables on the labor and budget estimate wall template. Budgeting can also be done very quickly on a spreadsheet. However, the wall templates are used during the session to make sure that all of the team members quickly absorb the information. Letting the team work on individual spreadsheets would break up the flow of the session. Also, the use of Post-its enables the team to quickly list the major tasks for creating the deliverables. To avoid getting bogged down in detail, team members should list no more than five major tasks to create each of their interim deliverables. It is a lot easier to get stuck on detail while using a computer. The use of Postits and wall templates encourages a broader level of thinking. After listing their tasks, the team members should estimate the time it will take them to complete the tasks they listed to create their interim deliverables. If the team member is not sure of the time it will take to complete the tasks, they can assign a confidence rating to get an estimate. The estimates are ranked as high confidence, moderate confidence, or low confidence. If the team members have done the task a number of times before, it is safe to give the task rating a high confidence level of rating. If the task is of minor importance, it is also safe to give it a high confidence level of rating (see figure 7.6). For example, if a person lives ten miles from work, on an average day it might take a half an hour to commute. On the best day, it might take this person twenty minutes to commute; on the worst day, forty-five minutes.
dR.PRIMECT MAN
f i y m Z 4- Activity tasks: labor and budget template Activity Task Schedule Labor and Budget Estimates
Interim Deliverable: Secure Site Hosting Due Date: 511 5 ~. .
7 Con-fl- Max Mln iaijbr tbst .,
.
,
dence Rating H: High M: Mod L: Low
Time tlme Rate H: l.txT k0.9xT (LRI M:1.25xT1U:( L:
-1t S q L t H i h -
I '
., .i.t, .
,
'I:
.i
: -
;icii,xx
Ul x T
-Max -
lE-
r LR x Ma:
LRx Mm
L Time
I
-
L
jlvli-
Ilia,i.!t(9
!rti'.iic ii;!sc:ti
crll
i~ii'~C'iidril
ilct.<J!;nt Ta<:,,cY1!
cil
.%I
\ i ~ + ~ ) ~ ~i:3 f8:;. -
1,;.
!
c
IIIL-.
p.25 s:: '~(,bt;rs$ t;i\<:,
bsi ' -
Si./iX : .
AIrlX.25
345:
q 180
$27(j
SC)t'i
S.45
$&%V,j{)
,:~:~o. 5{)
S"2.j
s,;"?.50
S,j{).i()
5 # ? 2 -,
I:
i31g O ~ ~ ~ i < Y l '
'
a
,:
6 ho;iji
? ~ O L .,, I
!>
x . y j f l j 5 1 ~ ~ t:t)ijls . i::
in?,
\:*~~>(i(q"~
i
I
i!
!:
J
i
,
'4.k-1
!W$l!,
h<>i:$?! l O ~ i ?
I.!
\)'>
54,'
&<>ti:.>
iic>iil.~
i:i~iir
<2;>p:<%T\l
jitr ~f'!c*(ta::9 $i!<'-
?!o~<~~ng ;'.,'1ld<33.
Dcvi.l
!
SI!C
hi..
$1 I , s. gI
tq>ioiuiir:g ;\f!>c
I i:
i;.>+.!:.
1 $,$j's iro:iri
6.0 5 !i
6.1
3
' '
-
':
f i g m 75Activity list for interim deliverables Activity Task Schedule Labor and Budget Estimates
Interim Deliverable:Secure Site Hosting Due Date: 511 5 Ta5
'i'ime I ~ o n f i - Max ce Time
1 ahnr
'
r
ing k1.l x
Rate (LR)
Cost LRxT
xTI M:0.7!ixT
- 'Mln
Max
Cost Cost LR x Max LR x Min Time Tim
-I
~ [ ~ a l l ~
requirements for site baqed on merchant account Research site-hosting options Negotiate with sitehocting vendors
I
1
I
I
I
I
/
I
I
I
L -
I '
11
'
'
-
\
,
I
I
Get
,
contract approved Ior selected siteho~ting vendor Develop siteuploading procedures
I
I
I ,
.) 1,)
I
I
1 / 1 1
1 11'
'I
I
1
6 -
Z6 Time estimate and confidence rating for activity tasks
Interim Deliverable: Secure Site Hosting Due Date: 5115 T *
Finalize requirements for site based on merchant account Research site-hosting options Negotiate with sitehosting vendors Get contract approved for selected sitehosting vendor
h e Confl- Max (TI dence Time
Activity Task Schedule Labor and Budget Estimates
Min Labfir tlme Rat Rating H: i d x T H:O.qxT (LR H: High M 1.25 x T M: M: Mod L 1: Low -
1 H hour
ilotlis
1zot;rs
3 M hours
5.75
2.25
545'
I
tluurs
hour
4
L
1 hour
10
5135
Bl(t8.75 S I O I Z S
5180
5270
t00
$45
$49 50
S30 50
545
S49.50
S40N
3450
$58725 531277
'.,otr.r
H
1 H Develop sitehour uploading procedures
hours
i
Time
hour
6 hoitr., 2 hn111\S44!
hours
Max Cost LR x Ma
Ipfic+-
X X
I
i!'l
: hrai~s
l l 09 ho~r-4 X I O C I I \
1307 o r
5451 130~1~
5451 X~our
595
Iro~;r\
-
-
-
7,--
g: You Want It When?
If this person had an important meeting at 8:00 a.m. and left at 7:30, there would be a relatively low confidence rating that this person would be on time for the meeting. This rating is based on the estimated time of the commute, from twenty minutes to forty-five minutes. In order to ensure that the person is on time, he or she would probably want to leave at 7:15, based on the worst-case scenario for commuting time. Likewise, on days when there is not an important meeting, it may not make sense to leave so early. In other words, team members should rank their confidence levels based on their own estimation of each individual situation. The benefit of the confidence rating is that it prevents team members from overestimating the time available to them and helps the project to progress quickly.
Time Calculation Once the tasks, time estimates, and confidence ratings are decided upon, the team totals up the time (maximum time, average time, and minimum time) and checks it against the availability that was allocated during the project agreement. If a team member has reached the maximum amount of hours that he or she can allocate to the project, that person needs to find other people who can collaborate or should find ways to reduce the time needed to complete the tasks. , Time is a strange phenomenon. People typically take all of their allotted time to complete tasks. To accelerate the project, team members need to work the minimum amount of time that it takes to perform the tasks to complete the project. The project leader adds up the difference between the maximum and minimum time estimates for all the tasks. This difference is added to the end of the project as a task called time insurance. That way if the project team needs more time to complete the project, it has it, but the team is working toward the more accelerated minimum time estimates. k.-L+
A-~-.
-
I
--.
-
--...?,-
, =,
-
-, AGEMENT
> +-
->. -.=
-
%& Z I Value Ratings for Calculating Time for Tasks
To calculate the time for the tasks associated with high, medium, and low confidence, the ratings are assigned a numerical value of .9 (high confidence),.75 (moderate confidence), or .5 (low confidence). Table 7.1 illustrates what each value means. The maximum and minimum times it will take to complete a task are calculated as follows: Max. time to complete a task = Estimated time of task x [ l + (1 - confidence rating)] Min. time to complete a task = Estimated time of task x (confidence rating) You can set up these calculations on a spreadsheet if you wish. For those who are unenthusiastic about math, the maximum and minimum times can be calculated as follows: Maximum time: ' High Confidence Time Estimate x 1.1 Moderate Confidence Time Estimate x 1.25 Low Confidence Time Estimate x 1.5 Minimum time: High Confidence Time Estimate x 0.90 Moderate Confidence Time Estimate x 0.75 Low Confidence Time Estimate x 0.50 .-...
--
---7--. - .
,
,q-m
--r*:-=+-R-
-..-..
.--
, <:, ,.,. -7-,w7?-- '
.
.:,.,
. 2 . .
7.- ."~??-..!?-!7*v.
~keduting:YMI wartt It When?
I
iqs
..#%
f i y w Z 7 Maximum and minimum time estimates for activity tasks Interim Deliverable:Secure Site Hosting Due Date: 5115 Task
.
-.
'-me
Max :e Time 1% H:lSxl
[confl-
"' "'5,h
'"'
Activity Task Schedule Labor and Budget Estimates ''V ' ""'in labor Cnct
M:~.~~~TIM:~XIXT
M: Mo 1: Low Finalize requirements for site based on merchant account Research site-hosting options Negotiate sitewith 1 hosting vendors Get contract approved for selected sitehosting vendor I
1 H hour
1.1 hours
0.9 hours
3 M hours
3.75 hours
2.25 hours
4
L
>st x Mln ne
C U TI
-X i
Ibok~r
i
4:;
6
\it11 25
tl,, tI
6 hours 2 hours G.5
hours
".9%'
2
$1
t - ~ i ~ :
1 hour
H
1 Develop sitehour uploading procedures
H
10 hours
I
Rate (LR)
1.1 hours
0.9 hours
5 4
1.1 hours
0.9 hours
$47
13.05 hours
6.95 hours
'.
T
T~,I
5f)
ii
-'40
To~ir
S ti*'
\-&- 23 \3:2 7 2
Figure 7.7 illustrates the summation of the maximum and minimum times for the e-commerce project. For this deliverable, the minimum time it will take -based on the time estimates and confidence ratings of the tasks - is 6.95 hours. The maximum time is 13.05 hours. Therefore, 6.1 hours will be added in the time insurance to the overall time to complete this project in a buffer at the end of the project.
COMPUTER-BASED PROJECT PLANNING TOOLS It is important for the members of the project team to be collectively focused on the big picture of the project. This includes knowing who needs to do what, when each task should be completed, and how the roles of each team member are interdependent during the process of Cheetah APM. This is difficult to do with most of the computer-based project management tools on the market - and it's especially difficult to do quickly. However, it is recommended that once the team has come to a consensus through the project launch event, the facilitator or the project leader record all of the information into a computer-based project-scheduling tool, such as MS Project or Primavera Sure Track. Typical project charts associated with project management, such as a Gantt chart, are easily created using the computer-based tools.
TIMING Schedule development should take a little over an hour and a half: Milestone schedule - twenty minutes Deliverables dependency schedule -forty minutes Activity task schedule - forty minutes
--..-l.=.-..--_-f-;..L
.,..-...---.'--..-: . ....,
*Fa=
,r"----
.-*,.w-+-2-.,
----
=--:=-
Scheduling: You Want It When?
,,-,
Budgeting: Money Changes Everything
I
n the project agreement, the project team documented the spending limit for the project. That figure sets the amount of money the team will have for creating the final deliverable. In this chapter, we will discuss the way the project team members re-examine the interim deliverables and determine the internal cost (labor costs) as well as the external costs (including materials) and when they will need the money for the completion of the interim deliverables (cash flow projections). Depending on the company, there can be detailed cost-accounting methods for determining the budgets and procuring the funds necessary to produce the final deliverable. During the accelerated project launch, the intention is to get input from the team members for their budget needs to create their interim deliverable~.The project leader works with the facilitator after the launch event to create the detailed project budget that is in line with their organization's accounting practices.
In the event that the budget is over the allotted spending limit, the project leader needs to work with the sponsor and the team to align the spending limit with the project budget. To accelerate a project, the team needs to secure the funding up-front to complete the project, preventing any delays and distractions. Without the funding, the funding mandate, or discussions about funding, you can lose the pace of your project. This chapter includes all of the information you need to make sure that you stay within your budget to the best of your ability. You will also learn what you should do if you go over your budget. This chapter includes information on the following: Labor costs ExternalIMaterial costs Cash flow Aligning your budget and your spending limit
LABOR COSTS The largest cost of most projects is the internal labor costs. Calculating labor costs can potentially be straightforward - just multiply a person's labor rate by the number of hours specified in the task schedule, as described in chapter 7. However, in many companies, the true cost of labor is buried in complex overhead calculations. Furthermore, in the business world there is usually a culture of secrecy regarding salaries. Given that these two business tendencies are so widespread, determining a labor rate for each project team member may, in fact, be quite difficult. To cope with the secrecy issue, it is helpful to find the going salary rate for outsiders and use that. For outside contractors, a flat-fee based on the contractor labor rate may be charged for a specific deliverable. For the purposes of the accelerated project launch event, each team member needs to identify or estimate -prior to the launch =.---Fp-*--<-. ..
1
..-
-*...-
~r-.-
-T..-.+-.,.-
PROJECT MANAGEMENT
-.
. . .
f i y w 8. I Labor cost estimate Interim Deliverable: Secure Site Hosting Due Date: 5/ 15
Activity Task Schedule Labor and Budget Estimates Mln 3~
hours
Develop 1 H sitehour uploading procedures
-
-.c:.::<
..-. . nc .-r.-...+ ,
--.*lr-"---
Cost t R x Mir
hours
1.1
0.9
$451
hours
hours
hour
13.05
6.95
---.... t - Budgt
i:
$45
$49.50 $40.50
$450
$587.25 $312.75
I
!y Changes
fi-
B. 2 Material and external cost estimate template ExternaIMaterial Cost Estimates
Interim Deliverable: Secure Site Hosting Due Date: 5115
+itern
In--'
'- nfldence Max Cost ' in cost I When ting ligh lld
111, 1
1: LC
H: 0.9 x T M: 0.75 x T I
'-salva ' ~ge/ j
Resalle
Value!
[*"L"P
--
-
event - his or her labor rate to be used in order to develop the internal labor cost calculations. This is specified in the sample agenda, which is provided for the project launch event discussed in chapter 2. Using the labor rate data, the team members calculate their internal labor costs by multiplying their labor rate by the task time information they collected in their activity tasks scheduling. See figure 8.1 for an illustration of the activity task schedule/labor/ budget template for this calculation. The team members develop their average cost, maximum cost, and minimum cost based on the average, maximum, and minimum time estimates. In the e-commerce example, Chris, the webmaster, has a labor rate of $45 per hour. This is specified in the labor rate column. In the event that Chris must have someone else do a task for one of the deliverables, he will have to specify that person's labor rate.
- - ~.----
--=-
156
dh&&
&'- " - --.--+-PROJECT MANAGEMENT
----
a*---~.
-_
_t
f i y w 8.3Material and external cost estimate template for the e-commerce project ExternalMaterial Cost Estimates
Interim Deliverable: Secure Site Hosting Due Date: 31 1
Ite
'
ZpZF-l
hnfidence!Max Cost ! Mln Co7Fiz , Meed H:llxT H:O.gxT I :High !Fn:l.%xT M:O.75xl I: Mnd : Low
I
Value
ilig
Cali
The internal labor cost maximum and minimum range is based on the confidence rating for each task. When budgeting, some people put in a factor of safety and pad the budget. The method presented in this chapter provides a ra*I -.--" ,
,
r
.--,
..- ".. -..--
---.r . 7 , w-l'rpw,TT-'
-
. -*..- ...?"c-*--.?*=<: p?.-r-?::. * ' I-?~'
.
i5-M- ~udgeting~ o n e yChanges Everything
tional way to develop a margin of error in budget calculations based on the confidence the team member has in his or her task time estimates. This eliminates the need for arbitrary padding. For Chris's task, the maximum internal labor cost estimate is $587.25, and the minimum labor cost estimate is $312.75. The cash flow section shows different strategies for budget allocations based on the organization's operational practices.
EXTERNAVMATERIAL COSTS Each project team member needs to identify what he or she will need (material, facilities, outside contracting services, travel, and so forth) and the associated costs to create the interim deliverables. The team members must specify the cost estimates, their confidence in their cost estimates, and the timing of the costs. For material, they need to specify if it is rented or purchased; and if it will be purchased, how it will be allocated to the company once the project is completed. If a team member needs a specific capital asset that is going to be used on other projects, the team should determine if it can sell the capital asset to the company when finished with it, thereby reducing the overall budget requirements of the project. Figure 8.2 illustrates a template used to estimate the material and external costs for the project. The team members use their color-coded Post-its to fill in the template.
CASH FLOW Depending on the accessibility of the funds, the team members will use different figures for their cash-flow decisions. If they have immediate access to the funds specified in the spending limit and if their project budget is within the spending limit specified in the project agreement, then they can use minimum budget figures for labor cost estimates. The team uses the minimum budget figures
,-.
.-7.----
I,,
--::-
&&PAO.
-7--....
JEGT MANA
.-
f i w R 4- External cash flow for the e-cornmeme project
Systems mquimmcnts
ma 8. & e-Commerce i Project Budget: Internal Cost Summary ~ r o ~ e~eam"Mernber ct [~ost ] Max. Cast 1 h;ffn.cast Alice March
$5,200.00
$6,786.00
$3,614.00
April
$5,200.00
$6,786.00
$3,614.00
May
$5,200.00
$3,614.00
$6,786.00 I
I
Bruce March April
$3,600.00
$4,698.00
$2,502.00
$3,600.00
$4,698.00
$2,502.00
I
May
I
$2,502.00
1$3,600.00
1$4,698.00
March
1$900
1$1,174.50
1$625.50
April
1$900
1$1,174.50
1$625.50
Chris
Debra March April
$1,300
$1,696.50
$903.50
$1,300
$1,696.50
$903.50
May
$1,300
$1,696.50
$903.50
Ed March April
$12,000.00
$15,660.00
$8,340.00
$12.000.00
$1 5,660.00
$8,340.00
May
$12,000.00
$15,660.00
$8,340.00
Subtotal March
$23,000.00
$30,015.00
$15,985.00
April
$23,000.00
$30,015.00
$15,985.00
May
$23,000.00
$30,015.00
$15,985.00
Internal Cost Total
$69,000.00
$90,045.00
$47,955.00
when determining cash flow to coincide with the minimum hour usage needed to speed up the project. For the external costs, it is best if the team has the maximum amount allocated to accommodate external pricing changes. If funding is allocated once, to be used for the duration of the proj-
ma 8. IB e-Commerce Project Budget: External Cost Summary 1Cost 1 Max. Cost I in. &stx'"'
Icost ltem
MS Project 2000
$450.00
$495.00
$405.00
Graphics software
$400.00
$500.00
$300.00
Secure site hosting $750.00 Internet merchant ac- $250.00 count
$937.50
$562.50
$375.00
$125.00
Shopping cart
$4,210
1$5,262.50
1~3,157.50
External cost Total
1$6.060.00
1$7,570.00
1$4,550.00
Total Project Cost
] $75,060.00
$97,615.00
1$52,505.00
'
1
1
ect, it is best to use the maximum budget calculation for internal labor costs. This ensures that there is an adequate funding buffer in line with the time insurance bufferto handle tasks that may take longer than the minimum time specified. This is also true with funding issues within the company that are competitive for individual projects. To emphasize cash-flow needs, the team puts one-by-twoinch neon green Post-its on the deliverables schedule to indicate where the funding will be needed for the external material costs for each team member. Figure 8.4 illustrates the external cash flow needs on the deliverable~schedule for the e-commerce project example. Once the team has completed its input to the budget calculations for internal and external costs, the project leader adds up the internal and external costs and checks the total budget against the spending limit set in the project agreement. For the e-commerce project, the original spending limit set by the sponsor in the project agreement was $100,000. Table 8.1 summarizes the internal labor costs and the externallmaterial costs for the e-commerce project developed during the project launch event. It shows that the maximum cost estimate for the e-commerce project is $97,615. : . - : * ~ - 7 * - - v - ~ - ~ ? . F - - -
, ; * , : ..,.-- c%-%:-:P* --';:--": E.rgM - Budgeting: Money Change!a Everythin .
..
*~_.W.__
...~....,--,
This means that the team is within the spending limit for doing this project.
ALIGNING YOUR BUDGET AND YOUR SPENDING LIMIT The ideal project budget situation is presented in the e-commerce example, where the maximum budget estimate is less than the spending limit. However, many project budget estimates come in over the spending limit. If this is the case, the team needs to take measures to align the spending limit with the project's budget. Figure 8.5 illustrates the decisions the project team leader makes to get the project budget aligned with the spending limit. The project can start immediately if the project team's maximum budget estimate is less than the spending limit. However, in any other situation, the team leader, the team sponsor, and the team members have more work to do before they can proceed. The project sponsor has the first decision to consider. Can the spending limit be raised to cover the maximum budget estimate? If so, then the project can start right away. When using Cheetah APM, it is recommended that the project sponsor not try to see how much cost it can squeeze out of the project team's budget; the time needed to do this will slow down the pace of the project. If the project sponsor cannot raise the spending limit, then the team must reduce the associated costs for completing the project. If the alignment problem is with the maximum budget estimate, the team members can work on improving their confidence levels for completing the tasks to create their interim deliverables. Additionally, they should try to get firmer estimates for their external costs. This may reduce the maximum budget estimate. If the maximum budget estimate (or, even worse, minimum budget estimate!) is still more than the spending limit, then the project team needs to change the requirements of the final deliverable to 7-
--
..+<-.--
Ir
y,-,..,:
-
: -
-..
-&.-
..-,.,4. - - -*-
PROJECT MANAGEMEm
-
-:.*----
;m--.
.-
f i r 8.5Spending limit decisions
Does min. spending
m a
Cancel Project
--
L-,.
--
\ -
.-
-
- -...,- - .T= &@? - Budgeting: Money Changes Everythin1 &77
2
-.-
something within the realm of the spending limit. If the team cannot do this and the budget estimate is more than 20 percent higher than the spending limit provided, it should not start the project.
TIMING Budgeting can be done in less than an hour and a quarter: Internal labor costs - twenty minutes External labor estimates - thirty minutes Cash-flow analysis - twenty minutes
.z-=.-
II
----
a:-.&
--- --.7-
---
*,-+--
R A PROJECT MANAGEMEHT
-...
-r.---+*--7--7-
-5
--
Tracking the Project: Eunsuring a Fast Project Stays Fast ,
A
fter the team finishes pIanning the project together during the accelerated project launch event, the project leader enters the schedule and budget data into a project-tracking tool, such as MS Project 2000 or Primavera Sure Track.The originaI
project plan data is called the baseline. It is from this baseline that the project team members make assessments regarding the progress of the project and the effects of changes on project requirements, costs, and schedule. In Cheetah APM, the emphasis is on the team. If the team is aligned on its project priorities, then it will better understand and work toward aligning its actions for the benefit of the project. Despite the best project plans, situations can change as projects progress. Customers' needs change, tasks take longer than anticipated, unanticipated risks arise, suppliers change their prices, other projects demand team members' time and attention, and so on. With the common variations of issues that arise, team mem-
bers may need to make changes to their aspect of the project from a schedule, cost, or performance perspective. Having co-created the project agreement, schedules, and budgets, they have a deeper appreciation of the ramifications of their actions on the overall project and on their other team members. As discussed in chapter 4, it is common for people to be more inclined to do the right thing for their other team members and not just because it is the right thing to do. Therefore, a key to APM is making sure that the team members understand the ramifications of their actions on other team members. There are actions the team members can take that can specifically accelerate their projects; conversely, there are other actions that may inadvertently sabotage the overall intent of their project priorities. To help the team members know the right things to do to accelerate projects, this chapter covers: Project changes: A quick decision-making process for accepting changes to the project plan Project status reports and performance tracking Typical project decelerators and tips to overcome them Rules of the road to keep projects on the fast track
PROJECT CHANGES Change will occur in all projects; that's a universal truth. Some changes could significantly derail or delay the project; others will have negligible impact. Some changes may even improve the schedule, cost, and performance of the project. The change impact assessment matrix helps the project team to understand the effects of optional and mandatory changes on the project. Whenever a change to the project is proposed, the team member proposing the change needs to assess the impact of the change. For each change proposed or needed, the team determines the effect on schedule, cost, final deliverable acceptance criteria, and risk. Then, using the project priorities identified in the project ..... ... ,..+, .- ** 168 '
-.-"'----
:?r...
--
'
>"
- -.
,
,
PROJECT MA~IAG'EMEHT
.
.
..*+. *r=--e'-. .*.-
a*
---.- -=
-
Z&a 9 1Change Impact Matrix
agreement, the team specifies the priority as top priority, second priority, or low priority. The risk-tolerance level from the project agreement is used in the matrix shown in table 9.1. The risk-tolerance factor is a scale from 1 to 10, with 1 being the least tolerant of risk. The factor for this calculation is 10-risk tolerance. The effect rankings range from -5 to +5, with -5 representing the worst-case scenario, the +5 the best-case scenario, and 0 no effect. Ranking is done for the effects that any changes have on schedule, cost, final deliverable criteria, and risk. For larger projects, the project team sets up a formal change control plan. The process for evaluating changes can be used to do change control.
e-Commerce Project Example Two changes are proposed for the e-commerce project. Let's look at those proposed changes and the way the team assessed them.
Proposed Change #I We found a more applicable off-the-shelf database solution that will work better for our needs for the e-commerce website. From the project agreement, the priorities are quality, top; schedule, second; cost, last. The risk-tolerance level was 2. The effect readings were determined by the team and are specified in table 9.2. From the analysis in table 9.2, it appears that this change will be good for the project. It will decrease the schedule time, improve >.
*.----.. .-,.: - ~ + z ~ - . - ? < & ; ~ .: r F F f - --. P m - ~raiiingthe Project: ~ n s u t h ga Fait Project Stays Rsl
yT4,..,.,. t=!w 7-.--.
-.7??:=!?-.-..-.
,,
,
..
- .:
>--
,.,<.:,
:*
.*A.--.
"1
-
Wi 94 Change lmpact Matrix for Shopping Cart Database: Go Decision
m a 9.7Change Impact Matrix for Shopping Cart Database: No-Go Decision !'ror: ~osedChange +5 - 5 3 (high) t o 1 (low$ Total
Sr l lc
to
-5 -t ! l l I ~ Cort -3 -
PcrIormance
-3
Risk -5 -
Priority:
-
- 10
7
1
-3
3
-9
8
-40
Total
-62
the quality, and decrease the risk. The only area that will rise is cost, but not by very much, and the project is currently under budget. Based on this analysis, the proposed change is accepted.
Proposed Change #2 The information systems (IS) department is evaluating the possibility of setting up its own secure server to host the e-commerce website. In setting up the original project plan, the IS department decided that one of the initial constraints was that it would not set up the secure website-hosting server. This potential change is assessed in table 9.3. As table 9.3 reveals, this seems like a very bad idea. It slows down the schedule, increases costs, decreases quality, and substantially increases risk. The team should stick with its current plan of using an outside vendor for the secure hosting system. If the IS department wants to eventually get its own secure server to host
.-- ,_.-..__ .1'
.-a7
,--.. -.:, .-...-*..-.-"--" c #& PROJECT MANAGEMEK .
.
....d2-A=--.,,.
-. ..LT9,.
-;--.----
., .--.
'T -
the website, it can transfer the hosting of the e-commerce website after the secure server is set up and after it has demonstrated the capability that it can keep that server running twenty-four hours a day, seven days a week, and can handle the site's traffic.
PROJECT STATUS REPORTS AND PERFORMANCE TRACKING The project agreement specifies the frequency and content of the project status report session. At each of these sessions, the team reports on: The percentage complete of the interim deliverables How much time it has spent creating each interim deliverable How much money it has spent (this can cover the cost of the time spent and the external costs, if there were any) From this information, the team determines if it spent more (or less) time to do the work completed to date than it had originally estimated in the schedule and budget. The team looks at the following factors: The actual cost of the work performed (ACWP) A comparison to the budgeted cost of the work performed (BCWP); this is called earned value A comparison to the budgeted cost of the work scheduled to date (BCWS) With these three numbers, the team can determine the cost and schedule performance for the project in this way: The cost performance is determined by looking at the actual cost of the work performed vs. the budgeted cost of the work performed. The schedule performance is determined by looking at the budgeted cost of the work performed vs. the budgeted cost of the work scheduled.
---..4m - Tracking the Project: E ~ S U &a ~Fast Project Stays Fast 17 1 -%
,..-..,
<,-
-... -.-*..
,El-
L ? 2
:
Based on the cost and schedule performances, the team can make trade-offs by re-allocating labor and financial resources where needed. In chapter 8, the minimum labor time estimate was discussed, including placing the remainder of everyone's time estimate at the end of the project in a time buffer. If you use the minimum labor timelcost estimate for the performance calculations, it will tell you how much of the time buffer you might need to use. Also, in chapter 8 it was recommended that you use the maximum cost for determining the budget for the external cost estimate. If you use the maximum costs for external costs, you can determine the budgeted cost of work performed. To give an accurate picture of project performance, each team member needs to provide the project leader with a report on how much of each deliverable is complete (noting what percent complete), how many hours he or she has worked, and how much money has been spent. The following two scenarios illustrate the project performance measurements.
e-Commerce Project Performance Measurement Scenarios The first scenario takes place at the April 15 project status meeting. Chris the webmaster reports having spent five hours on the interim deliverable called secure site hosting. During these five hours, Chris has negotiated with the site-hosting company for $750. He estimates that the job is 80 percent complete since it is still necessary to get the contract approved. Table 9.4 shows Chris's project status report data. Row 1, Interim Deliverable. The team members create one table for each interim deliverable. Row 2, Minimum Time Scheduled. This is from the activity task schedule generated during the project launch session.
IECT MAHA
%&a 9 1Project Status Report Data: Scenario One
l a ~ oana r externa to Data (hours) ~tComptet e
Row 3, Cost Budgeted (labor and external). This is taken from the budget data that the team generated during the project launch session. It is the maximum external costs + the minimum number of hours x the labor rate - $937.50 + (6.95 hours x $45/hour). Row 4, Work Scheduled to Date. This is the work that the team anticipated it would complete by the date of this project status report. (In this scenario it was 3.25 hours.) Row 5, Percentage Complete. This shows how much of this interim deliverable is complete at this time. Row 6, Actual Time Spent on the Tasks for Creating the Interim Deliverable. This shows how much time the team has charged for working on this interim deliverable. It must track any internal accounting system data that the team members may have entered for this task. From this information, the project leader can calculate the actual cost of the work performed, the budgeted cost of the work performed, and the budgeted cost of the work scheduled, to determine the cost and schedule performance. This information can be broken down in this way:
_.
.n
-..
2
.... .--.
..
,.
--- .
-.-,-?-
.*,-
*.
~ekingthe Project:
IS&&
6
-7-*-
-..- - .-.
7
.-p>p-F --.
a Fast Project Stays Fasl
Actual Cost of the Work Performed (ACWP).The external costs ($750 negotiated for the secure site hosting) and the actual time spent on the tasks multiplied by the webmaster's labor rate ($45/hourx 5 hours). The ACWP for this example is $975. Budgeted Cost of the Work Performed (BCWP).The maximum external cost estimate ($937.50, the maximum cost estimate from table 8.1, ) and the percentage complete multiplied by the minimum time scheduled multiplied by the labor rate (80% x 6.95 hoursx $45/hour).The BCWP for this example is $1187.70. Budgeted Cost of the Work Scheduled (BCWS).The maximum external cost estimate ($937.50) and the work scheduled to date multiplied by the labor rate (3.25 hours x $45/hour). The BCWS for this example is $1083.75. These calculations are summarized in table 9.5. This information is then used to calculate the cost and schedule performance. Cost Performance. This is determined by calculating the ratio of the BCWP to the ACWP. This figure is called the cost performance index (CPI). The CPI for this interim deliverable is 1.22. An index greater than 1 shows that the actual costs of the work performed is less than the budgeted cost of the work performed. With the CPI, the team can estimate the project cost at completion by dividing the original cost estimate by the CPI. The estimated project cost at completion for this interim deliverable is ($1250.25)/1.22= $1024.80.
-
7Zhh 9 5 P m j e c t Performance Metrics: Scenario One Interim ~ e Min Time Schedul~
l
l
v
e
r
a
b
-
6.95
$1,250.25
-
Work Scheduled tio Date (hc Percent Complet~ Actual Time Spent on Tasks (hours) Actual C:ost (lab01 and extf !mall (AClWP)
$975.00
P----A rn Budgete!dCost of Work Per1I U I . I I I ~ U(nCWP) Budgeted Cost of Work Scheduled (BCWS)
$1083.75
-
-
3.24 80.00°! 5
$1 187.70
9 6 Prqject Performance Indices: Scenario One -.
'lnterimbelfverab-' Actual Cost (labor ano external) (AL;WPI Formed (El Work Schteduled (81
Secure site hosting $975.00
% 1 187.70 $1083.75
1.22 I
-
I
e Perforwlance l n d ~ ed Cost a1: Project ( - .
1.10 $1 024.80
n
Schedule Performance. This is determined by calculating the ratio of the BCWP by the BCWS. This figure is called the schedule performance index (SPI).The SPI for this interim deliverable is 1.10. An index greater than 1 shows that the time to do the work to date is less than the estimate in the original project plan. An index less than 1 indicates there are likely to be schedule delays. Table 9.6 shows the calculation of these ratios. The second scenario also occurs at the April 15 project status meeting when Chris the webmaster reports having spent five hours on the interim deliverable, yet it is only 40 percent complete. Because of the second proposed project change (discussed * . > d -
-. --A -
!~kingthe I
-
*-#+
,.*----
---
&ring a hstp r o m Stap Fast
--
m
7Zhb 9 7Project Status Report Data: Scenario Two 'interlrn uerive
Secure site hosting
Min Time Schc Cost Budgetea [latior ana excern Work Schedded to Datt3 (hours) Percent Comi Actual Time Spent on Tasks (hours)
I
6.95 $1250.25
3.25 40.OO'Yo
5
earlier in this chapter), Chris had to meet with the IS department when it wanted to explore setting up the secure server in house. The team decided this was a very bad idea for the adequate completion of the project, as illustrated in table 9.3. Because of this delay, Chris is still evaluating the site-hosting options. Table 9.7 shows this scenario. With this information, the team can calculate the ACWP, the BCW, and the BCWS to determine the cost and schedule perf ormance. ACW. This includes the budgeted maximum external costs ($937.50) since the webmaster still does not know exactly what the secure site hosting will cost. It also includes the actual time spent on the tasks multiplied by the webmaster's labor rate ($451hourx 5 hpurs). The ACWP for this example is $1162.50.
I
BCWP. This is the maximum external cost estimate ($937.50, the maximum cost estimate from table 8.1) plus the percentage complete multiplied by the minimum time scheduled multiplied by the labor rate (40% x 6.95 x $45/hour). The BCWP for this example is $,1062.60. BCWS. This is the maximum external cost estimate ($937.50) and the work scheduled to date multiplied by the
----.--.. PROJECT MANAGEMENT
ld+--T"'.-d.k =.-----7.---
1
.--
-c-4
Zh%98 Project Performance Metrics: Scenario Two Interim hllverable Min Time Schedulled (hours Cost Budgeted (labor and external) Work SCheduled to Date [hr Percent : , - . Actual 71mespent on r a s ~ s(hours) Actual Cast (labor and external) (AC Budgeted Cost o f Work Performed (0 Budgeted Cost of Work Scheduled ( B ~ w s l
Secure site hosting 6.95 $1,250.25 3.25
40.00%
5 $ 1 162.50 $1062.60
$1083.75
labor rate (3.25 hours x $45lhour). The BCWS for this example is $1083.75. These calculations are summarized in table 9.8. As in the first scenario, the cost performance is determined by calculating the ratio of the BCWP to the ACWP to obtain the CPI. The CPI for this interim deliverable is 0.91. Because this index is less than 1 (the actual costs of the work performed are more than the budgeted cost of the work performed), there may be a cost overrun. With the CPI, the team can estimate the project cost at completion by dividing the original cost estimate by the CPI. The estimated project cost at completion for this interim deliverable is $1250.251.91 = $1373.90. This is $123.65 greater than what was initially budgeted. However, Chris has not made the decision for secure site hosting yet. If Chris finds that the CPI is $123.65 less than the estimated maximum external budget of $937.50, this deliverable can still be produced within budget. With this information, Chris can more aggressively negotiate with the secure site-hosting provider. Recall that the schedule performance is determined by calculating the ratio of the BCWP to the BCWS to obtain the SPI. 1-.
.---.
- -.
-r?----
-----
--,
kcking the Project: En
ist Project Stays Fad
I
I
E&.%
9.9 Project Performance Indices: Scenario Two
Werlk d;iifveirrFIE " --
Secure site hosting
Actual Cost (labor and t Budg~tedCost of Work rar.~ur-rr~ed (BCWP) Budgeted Gas't o t Work:Schedulec Cost Perform;ante Inds:n (CPI) Schedule Performance Index (SPI Estimated Cost at Project Gornplr
-
S1162.50 91062.60
$1083.75 0.91 0.98
51373.90
The SPI for this interim deliverable is 0.98. Because this index is less than 1 (the time to do the work to date is slightly more than the estimate in the original project plan for the minimum task time), there may be a delay in producing the interim deliverable. However, the team is using the minimum time estimate and has a n insurance time buffer. Thus, the SPI in this case is not likely to be of significant impact. Table 9.9 shows the calculation of these ratios.
Project Status Report Summary To complete this report for the project, the project leader creates a spreadsheet with the formulas used in this chapter and the data provided by the team members. The formulas in the spreadsheet automatically calculate the project performance metrics and indices so the project team can make informed decisions about re-allocating resources and making modifications to the schedule.
PROJECT DECELERATORS To keep a project moving fast, the project team, team leader, and project sponsor all have to remove or prevent obstacles that may get in the way of the project. Here are the most common issues that can slow down a project: Project scope creep, or feature creep ..
. .
.-
JEGT MAN4
Project agreement changes Poor team dynamics Multitasking team members Over-scheduling people's time Inefficient business processes that the team must use to create its interim deliverables Chaotic work environments
Project Scope Creep, or Feature Creep This is the disease of "we can make it better." There comes a time in nearly every project when it is time to shoot the engineer and finish the project. To make decisions about suggested feature changes, you should use the change-impact matrix. Also, at a specified time in the project, freeze the design of the product or service, including the set of features. The earlier this is done in the project, the faster it will move. Make sure that you include future feature ideas as upgrade possibilities for later versions of the product or service.
Project Agreement Changes Let's face it, things happen. Customers change their minds, market forces change, new threats and opportunities arise that make the goals of the project obsolete, and new priorities surface to pull money and resources away from the project. In Cheetah APM, the project is directed by the project agreement; if information in the project agreement changes, the project changes, thereby necessitating a re-launch of the project. It is better to spend half a day re-launching the project based on the new project agreement than to create a final deliverable that no one wants or to attempt to complete a project with inadequate resources and lack of support from the project sponsor. An analogy is the difference between building a new house and remodeling a house - to remodel a house takes a lot more time.
----- .-___=___-----*..-
-._
._,
_
_
--
---6
cking the Project: Ensuring a Fa
-q.Z.,
_-...t.Cll7--
Stays Fast
Additionally, when you are creating the new project plan from the new project agreement, you may be able to use the interim deliverable~you have created to date for the new project, thereby shortening the project-cycle time for the new project.
Poor Team Dynamics An inability to work together toward a common goal comes from lack of commitment, lack of interaction skills, and a lack of interest in constructively resolving conflict. Chapter 4 shows constructive ways to build team dynamics so the team can work at peak performance. Additionally, many projects lose and gain people during the execution of the project. When this happens, it is important that the team spend a half hour together developing new team guidelines and meeting protocols. When any new people join the team, it becomes a new team. Redeveloping your guidelines and protocols is done for the same reason it is done initially - to facilitate working relationships, create a procedure to positively interact, and prevent destructive conflict.
Multitasking Team Members When team members have to work on multiple projects or multiple tasks within the same project, there is a tendency to multitask. People work quickly and efficiently when they work on one task to its completion and do not juggle multiple tasks. If people are working on multiple projects, it is best if they set aside blocks of time to focus on one task at a time.
Over-scheduling People's Time Sure, people are capable of doing the occasional marathon week to complete a project. If this becomes routine, however, they will find ways to get out of work responsibilities during the work day. We all need to take care of our basic living needs, such as den-
&&!t
PRO
tist appointments, home care, and grocery shopping. We also have a need for socialization, connection with family, and time to relax and unwind. If people are overscheduled because of project work, they will create ways to take care of their responsibilities while they are doing their project work (thereby multitasking and becoming less efficient). The next thing that will happen is they will get further behind, necessitating more over-scheduling. It is best to prevent this cycle from happening by having the team members create a schedule that they can commit to in a normal work week. If tasks get into a crunch, absolutely do not require people to work more than one extended work week at a time. This keeps the project moving along. If extended hours do become necessary, it is better if team members take turns during the crunch.
Inefficient Business Processes As discussed in chapter 5, it is the job of the project sponsor to knock down barriers so that the project team can work fast and efficiently. If the team gets stuck mucking through a bureaucratic maze to complete its interim deliverables, the project will slow down and the team will become frustrated with the wasted time and effort. Most business processes are not consciously created; they evolve. For that reason business processes often develop into an overly complex system with arcane rules and procedures to prevent the re-occurrence of old problems. For example, one company's internal procurement practices may require three or four signatures before a necessary item can be purchased. In companies that are organized by function, business processes may span across functional lines, with several players involved in part of the process but no one person responsible for the process in its entirety. Merely figuring out how to get things done in these types of organizations becomes a full-time job. It is the *
..sU--'i-
.-PC--.
.---" _ , - ~ % . & ~ ~ r m *..-..r--.,. ~ckingthe Project: Ensuring a Fast Project Stays Fasl A.G<-.?,-.
7..
T-
-7--7-*,
responsibility of the project sponsor to cut through the bureaucracy so that the team has the material and cash resources it needs to get the job done quickly.
Chaotic Work Environments How long does it take you to find the information you need (that you know is on your desk somewhere!) to get your job done? Clutter on your desk and on your computer slows down project work. It is also distracting and causes multitasking. To keep your work productive, it is a good idea to hold a " 5 S" event with the team, both at the beginning of the project and as part of the project status reports. A 5-S event is a technique adopted from the Japanese quality movement, and it can improve white-collar productivity. The initial 5-S event may take half a day for the team members to get their work spaces organized; but after that, it is a simple fifteen-minutes-a-day discipline to keep their work space organized. The technique is far more than simply cleaning one's desk -it is about setting up a productive work environment with visual tools so that people can get their work done efficiently. The 5-S approach stands for: Sort: Only keep items that you use on a daily basis in your work area. Everything else gets put away in its place. This includes sorting through electronic data and creating filing systems for quick retrieval for both paper and electronicbased information. Straighten: Can you imagine racing a car on a track littered with debris? A clean track is a fast track. Assign a designated place, such as a desktop organizer, for all moveable items. Everything is labeled in macro work areas, and there is logical work flow for shared office machines, such as copiers. ~
t
182
~
~
.
a
"
~ -&. --
~
&&& PROJECT MANAGEMENT
,
/e-zre"-----?=--.-*~ ~ -
~
-
-
Shine: Everything in the area looks like new and operates perfectly. Recycle bins and waste baskets are emptied nightly. Standardize: This includes visual controls of common areas, such as how to use the copier, and wall-planning calendars. Sustain: Set up a daily and weekly system to keep up with the improvements that you have made.
RULES OF THE ROAD TO ACCELERATE PROJECTS With the project schedule as your map and all of your barriers removed, your team is ready to quickly and efficiently work through the project. To make sure that you keep up with the hastening speed, heed the following rules: Adhere to good project management habits. If used consistently, the launch process outlined in this book will help you to develop good project management habits. Stick to the project agreement; agree to the team guidelines; have the team co-create the plan, schedules, and budgets; and provide the tracking data needed during the project status reports. Take care of problems when they are small. Focus on the system -not on the people-when dealing with problems. Eighty percent of all problems that occur are due to the organization's goals or structure rather than human error. When people are afraid of being blamed for an error, they tend to hide problems. This makes it difficult to deal with problems while they are still small and easy to correct. Post the dependency schedule. Post this schedule for your project, which you created during the project launch ses-.- ..-
--,-
<.-
..-
.a>.-
+
s
-
-
-----*a<--
A
s$ng a Fast Project Stays Fad
sion. Put it in a place where everyone on the project team can see it. Have the project team members develop their own schedule, which they should keep in their work area. It helps to be reminded of what you have to do next. By creating a visual road map, you can see what you have to do now and what tasks are up ahead. Set and prioritize goals daily and weekly, aligned with the end goal of the project. At the end of each day and the end of each week, review how well you did with reaching your goals. It is easier to make small midcourse corrections to your personal performance on a day-to-day basis. It also takes a daily discipline to work quickly and with focus. People can achieve whatever it is they put their mind to. A group of people, aligned and working toward the same end goal, can accomplish what might otherwise seem impossible. The key to accelerating projects is commitment. The techniques presented in this book for launching and tracking a project can get the job done and keep it moving quickly.
I
_
---+--lru-
**-L-~-.--
<----
x.
184
,......- -
+-
.I
a
PROJECT MANAGEMENT
'I , . ..--
Lessons Learned
A
ccelerating projects is a career-long pursuit of using what you have learned from previous projects to make new projects go faster. It is both an individual and a team responsibility to collect lessons learned information. It is a team and an orga-
nizational responsibility to capture and put to use the lessons other people have learned from doing projects. If all the individuals on the project team take a few minutes every week to record what they have learned that week and spend a few hours at the end of the project recording their lessons learned, they can use this information when launching their next project. In this way, they are benefiting from their experiences. Adults learn by reflecting on their experiences. In this chapter, you will learn an accelerated learning technique so that you can quickly take what you have learned from your current proj ect and apply it to your future projects.
i
I
I
Another part of lessons learned is documenting your experiences so that others can benefit from them. The project agreement created by the team is a good place to record the lessons learned for this project. If your company has a knowledge base where it collects lessons learned information, it is also valuable to record your project lessons there. If the lessons are significant, one or several members of the team should consider writing a paper to be shared internally with their company and, if appropriate, with others in the industry. Storytelling has been the way lessons learned have been shared throughout the ages. Sharing war stories about past projects is a common way of .disseminating lessons learned information.
COLLECTING LESSONS LEARNED DATA THROUGHOUT THE PROJECT It is easier to keep a running log of lessons learned as the project progresses rather than try to remember everything you have learned once the project is complete. Accelerating projects is about developing good project management habits. One of the habits that is helpful in making projects move quickly is to spend a few minutes each week evaluating what you learned during the week. It's a good idea to choose Friday to do this, when you can look back over the entire week when making your evaluation. These accelerated learning reflection questions are helpful with documenting lessons learned on a weekly basis: Three things I learned this week when working on my project were: , and When implementing on the project, I felt . (If you can attach your learning to feelings, you will better remember what you learned.) When I tried on the project, the following happened:
Next week, I am going to try ect based on what I learned this week.
on the proj-
Keep a running log of your weekly evaluations. Use these as your basis for your lessons learned session at the end of the project. The information recorded can be about what you learned and about what happened in your interactions with the project customers, external and internal. You can use this information to structure more formal lessons learned data collection activities at the end of the project.
COLLECTING LESSONS LEARNED DATA AT THE END OF THE PROJECT When the project is done, you and your team members should celebrate and, of course, you should evaluate what you learned in the process of completing the project. The place to start is with the initial project agreement. Your team should go through the project agreement and the project leader should record what you learned from doing the project for each section of the agreement. The next step is to review the lessons learned log that you have kept throughout the project and assess how your implementation of the Cheetah APM process worked. You can also solicit feedback from the customers about their expectations and experiences using the final deliverable. There are three other traditional ways project teams record lessons learned: Placing lessons learned information into a company-run knowledge base Writing a paper for people in their industry about what was learned Creating a story of the key lessons the team and their company learned from the project; war stories are an age-old custom of sharing lessons learned
; -++~-.;:<
.....-.. rn
--+tv
...:..
.., ':.....-., .-.,. .
..-, 8 e 7::.
~.:-&.
-.
.-.~IP. - lessons Learned
..,,
=-%.r.c.>d*r..c?-'-.-...F
,T-x-7.
I s9
Lessons Learned on the Project Agreement The original project agreement provides a good structure to capture lessons learned information. The example that follows is from the e-commerce project. All of the lessons learned information is noted in italics. To review all of the lessons learned from the e-commerce project, refer to the completed project agreement in the appendix.
fi-
I 0 I Project Agreement
Project Title: e-Commerce Project Date: June 9, 2002 Person Recording Lessons Learned: Alice Persons Creating Lessons Learned: Alice, Bruce, Chris, Debra, Ed Project Sponsor: Pat C. Eeo
1.0 PROJECT SCOPE 11 Project Objective The final deliverable will be a website that our customers can use to order our products and to submit request for quotes for specialized products and services. Lessons Learned: We should have included product support as part
of the website, because once customers started interacting with us via the Internet, they wanted more sewices for product support for using our products that went beyond simply asking for quotes and making orders.
1.2 Project Boundaries The project team starts with examining the existing website, including the existing order fulfillment system and financial systems, and ends with reviewing the customer surveys from the newly launched e-commerce website.
f i f ,It9 I Project Agreement (continued) Lessons Learned: We couldn't use much of the existing systems once we started down the e-commerce route. This involved far more business process redesign than we had initially anticipated.
1.3 Customer Definition A. Project Customers External Customers - The people who buy our products and services Internal Customers/Stakeholders - Sales and marketing staff, order-fulfillment staff Lessons Learned: The customers were also the people who were using our products and services- not just buyers.
B. Customer Needs External customers- Our customers are very busy during the day as they work to meet the needs of their customers. When they take time out of their business day to deal with their suppliers (and we are one of them), it reduces the time that they have to work with their customers. Internal Customers -Sales and Marketing: While we can direct customers to our website to look at our product descriptions, there is no way for them to order from the site itself. Order Fulfillment: Our order-fulfillment staff is overworked, taking repeat orders from customers who want to be able to place their orders through the website, and we have had a problem hiring enough people to answer the phone. We need a way for customers to order our products
I
I
.
4.--=-Tni.=.-
-..
,-
T - ~ - 2 ~ - . 1 : m m + . - ~ -
/
s
- Lessons Learned
w p m - '-%q
19 1
fifltuw 70 7 Project Agreement (continued)
.Customer Requirements"kcstHiva
(see 1 . 3 ~ )
Clistm--&
'
Nice t6have
Na'fiht'
'
1~ b t avalue l
Important
Reql
A way to order sup- 4 plies 24 hours a day, 7 days a week without having to interact with our customer service department
1
*
-
0
~3
0
21
,
An order capture sys- 3 tern that works with a credlt card or is tied into the corporate account billlng system
2
items in under 24 hours Reply to request for quotes m under 2 4 hours Delivery of specially ordered items in under 72 hours
15
4
0
1 21
0
3
2
17
and request quotes without having to interact directly with anyone from the company. We do need to be available to answer special requests and to process phone orders from customers who still want to do business that way. Lessons Learned: They needed help with using our products once they purchased them.
fiflm ?O.? Project Agreement (continued)
Customer Acceptance Criteria
uests answered in under
manual data entry from web orders to existing ac-
Accelerated Project Process Review After the project team has documented what it learned from each section of the original project agreement, it takes an overall look at their implementation of the Cheetah APM method. The following questions can help guide that review: What made the project move fast? What slowed the project down? What did the team members experience working on a project team with an APM focus? What did you learn? Based on what you learned, what are you going to do on your next project?
..-_..
..-...-.-
;i--:w=
*SFiiiii
-.... r
-i.-7,)
....--,,, -w - lessons Learned
...,",l-... ,,..<.,
.z>-sTn
1<
m-.:=:~+=-=,.
Y
1 93
What would you tell other people considering using a n APM method to launch and execute their projects?
Feedback from Customers The bottom line in getting customer feedback is to find out if receiving the final deliverable from your project motivates your customer to continue to do business with you. If it does, then this is an opportunity to find out what other ways you can continue to provide them with products or services in your realm of expertise. If your customer's experience somehow hurt your ability to continue to do business with them, it is imperative that you find out why and use the knowledge gained as a catalyst to fix the problems. If you want to get feedback from customers regarding their experiences using your product or service, you will get a better response if you offer them something in return for their feedback. Most people find filling out customer satisfaction forms very disagreeable unless there is a strong personal motivation to provide the information. It is best to solicit feedback during a one-on-one phone call or in a face-to-face meeting. It is also better to meet within the normal course of doing business rather than making it a discrete event where the person providing the feedback is put on the spot to provide his or her opinions. The overture can be as simple as a follow-up courtesy call to see how everything is going or during follow-up training in the use of the new product or service.
Feedback from Project Participants The best way to improve your project management performance is to have the people involved in the project give you feedback on your performance. We recommend a web-based assessment tool called Project Management Scorecard (www.pmscorecard.com) to solicit feedback from project sponsors, customers, and team mem-
bers on your performance as a project manager. You enter the email addresses of the people you are requesting to rate your performance, and they receive a short survey to fill out regarding your performance on a project. The website returns a one page report that displays their feedback and suggestions for where you can improve your project management skills.
Organizational Knowledge Bases As a result of the knowledge-management movement, many organizations today have enterprise-wide knowledge bases where employees can store and share their lessons learned. If this exists in your organization, follow the prescribed format and include the lessons the project team has learned from doing the project. If such a knowledge base does not exist, approach your organization's chief information officer, or comparable senior management, about creating one and using your lessons learned as a model.
Publishing a Case Study Many trade and professional organizations welcome case study illustrations about projects that people undertake in their industry. What your project team learned on your project will likely provide valuable insight to others who are making similar efforts. Furthermore, it has been shown that the most creative people are the ones who freely share their experiences through publishing papers to their peer groups. When you publish and present your papers, others will come forward and share their experiences with you, allowing you to learn from them as well.
Storytelling Storytelling is an age-old custom of sharing lessons learned. Trading war stories about experiences on past projects is also common. Creating a story about what team members experienced on the project creates closure, since working on an accelerated project is T.-.:y-
h-
.7 . + -,
*-=#&=?-*y*.
,
ST,.
,.
.,
-
*--.=-
4
-
.=
c-- r . r ~ ~ ~ ~ . - . w ~Y ~= ' r
7&& - Lessons Learnm
an intense experience for most people. It is best if each team member creates his or her own story about the project. The team member can choose to share or not share this story with the team. In the story, the team member can elaborate on the hero and the villain, the twists and turns, the drama, and the lessons the cast of characters walked away with that forever changed everyone's lives. Stories are a fast and fun way to summarize what people experienced in their pursuit of Cheetah APM.
Cheetah Accelerated Project Management is an attitude as much as it is a series of steps to get things done quickly. People can achieve whatever they put their minds to. Those of you brave enough to be out in front, remember that you can always tell the leaders by the arrows in their backs. With this approach, you just may be able to outrun the people shooting those arrows at you!
-.-~-~rr-z-FFq~-'ql
I 96
&&
'
-.,..
-4
.?-.t+ -s&F v"
PROJECT MIIIHAGEMENT
h
The Completed Project Agreement
PROJECT AGREEMENT Name of Project plan: e-Commerce Project Date: June 9, 2002 Person Recording Agreement: Alice Persons Creating Agreement: Alice, Bruce, Chris, Debra, Ed Project Sponsor: Pat C. Eeo Project manager Project sponsor Project team Project customer Project stakeholder
Project ,Agreement Change History
1.0 PROJECT SCOPE 1.1. Project Objective [What will the project team be creating (the final deliverable)?] The final deliverable will be a website that our customers can use to order our products and to submit requests for quotes for specialized products and services *Lessons Learned -We should have included product support as part of the website, because once customers started interacting with us via the Internet, they wanted more services for product support for using our products that went beyond simply asking for quotes and making orders.
1.2. Project Boundaries [Where do the team members start their job and when are they finished?] The project team starts with the existing website, including the existing order fulfillment system and financial systems, and ends with reviewing the customer surveys from the newly launched ecommerce website. *The Lessons Learned are added as a separate activity at the very end of the project.
-*.;--..
-
7
-
.<.-
.
@a4
PRO
:
*-..
--Tr-. .
.
....r ,
!G~u€~T
.
,.
.
r>--l
.
-..* .---- .-- .... .. ..
Lessons Learned - We couldn't use much of the existing systems once we started down the e-commerce route. This involved far more business process redesign then we had initially anticipated.
1.3. Customer Definition A. Project Customers [Who is going to use the final deliverable from our project?] External Custom'ers - The people who buy our products and services Internal Customers/Stakeholders - Sales and marketing staff, order fulfillment staff Lessons Learned - The customers were also the people who were using our products and services - not just buyers.
C. Customer Needs [What problems do our customers have that the final deliverable with help them solve?] External Customers - Our customers are very busy during the day meeting the needs of their customers. When they take time out of their business day to deal with their suppliers (and we are one of them), it reduces the time that they have to work with their customers. Internal Customers/Stakeholders- Sales and Marketing: While we can direct our customers to our website to look at our product descriptions, there is no way for them to order from the site itself. Order Fulfillment: Our order-fulfillment staff is overworked, taking repeat orders from customers who want to be able to place their orders through the website, and we ; * . ',
- --
-
+
Completed Project Ag
.--
have had a problem hiring enough people to answer the phone. We need a way for our customers to order our products and request quotes without having to interact directly with anyone from the company. We do need to be available to answer special requests and to process phone orders from customers who still want to do business that way. Lessons Learned - They needed help using our products once they purchased them.
C. Customer Requirements [What are the customers' specifications for the final deliverable? Importance ranking- each team member ranks each requirement (5- must have, 3 - nice to have, 1 - can live with or without).] Customer
dust Have
Nice t o Have Not That lrnportant
Total Value
0 73
Requirement
plies 24 hours a day, 7 days a week without having to interact with our customer service department An order capture sys- 3 tem that works with a credit card or is tied into the corporate account billing system Delivery of in-stock 2 items in under 24 hours Reply to request for 4 quotes in under 24 hours Delivery of specially O ordered items in under 72 hours
2
0
21
'1
2
15
0
1
21
p p p p
&& PRO
3
2
17
Lessons Learned - The quick turnaround delivery was less important than getting fast responses (under an hour) to inquiries from the website.
D. Customer Acceptance Criteria [How are we going to measure the customers' satisfaction with the final deliverable? Importance ranking - each team member ranks each criteria ( 5 - must have, 3 - nice to have, 1 - can live with or without).]
in existing corporate accounts billing system; no manual data entry from web orders to existing ac-
Lessons Learned -We had a number of problems with the merchant account processing our customers' credit cards. We had to institute a work around where our customer support people called the prospective customers and took their orders over the phone. This also enabled our sales staff to upsell the customers on our other products. What was a problem turned into a better solution that increased our sales. - -,
7-7.
5
...... --.?-.,-
F.;:-..'-'.l
-
'*..
40'~
.. .._,
,I,
-r.
le Completed Project Agnernenl
1.4. Business Case A. Market Impact [How will our project impact our competitive position?] If we make it easier for our customers to order our products through our website, they will be able to order more products from us. Right now, four out of five of our competitors have websites where their customers can order their products. These sites are difficult to navigate, and it takes several minutes to process the orders through a modem connection, which is what most of our customers use. Based on the design features of our e-commerce website, our customers will be able to order products with one click, and the order will take less than 30 seconds to process. Lessons Learned - We need to be prepared to offer more of our business services via the Internet -not just product ordering, but also product support.
B. Organizational Impact [What will the organization gain by pursuing this project?] Our company is in the very early stages of integrating the Internet into our operations. We need to develop an internal capability for using the Internet, not just in e-commerce applications, but in other areas of the business as well. This project enables a core group of people to become more knowledgeable using the Internet for our business. Lessons Learned - This threw us into the fire, but it was probably the best way to learn how to integrate the Internet into our operations.
C. Strategic Impact [From a long-term strategic perspective, how important is it that we are successful with this project? Give a ranking from 1 (minor importance) to 10 (major importance).] This project has a strategic impact rating of 6. We have a strong customer base that is just starting to get up to speed with the Internet. We don't want to get "Amazon-ed" - that is, have a lot of our market share taken away by an innovative upstart Internet company. However, we have noticed lately that most of these innovative dot.com companies are stumbling. So this is not as strategically significant as it would have been a year ago. Lessons Learned -We should have looked at all the applications of using the Internet in our business prior to starting on this one application, so that we could have done a more integrated rollout.
1.5 Project Priority Weighting [From your perspective, please assign a ranking of 1, 2, or 3 to each of the elements. A ranking of 1 is higher importance, 3 is lesser importance. Please rank each element using each number (1, 2, or 3) only once.]
A. Overall Weighting .
-
..
Business Performance
Project Performance
..
.---
'~earn P e r f o r ~IGE ~~d~
P r n l r c ~rr~anagcr
1
1
Project sponsur Project team member Projea stakeholder
I
2
3
2
1
3
2
1
3
,., - -.- .>.:-..
.......
7 . : -
.-.+
*>-.--
- .---
~ - -
-,,
....'-.:!' ,
. *,*"
----., .
..
w..,...--.?-
'..L$?
ed Project Agreemenl
b..
B. Business Performance L
- ^ -
-Market
Organizat'
-
Impact
Impact
Impact
Project manager Project sponsor Project team member Project customer Project stakeholder
2
1
3
'
""
'
Sirategic
1
3
2
3
1
2
1
2
3
2
3
1
Management
Management
agement
1
2
3
'
'
1
C. Project Performance
Project manager Project sponsor Project team member Project customer Project stakeholder
1
3
2
1
3
2
2
3
1
1
3
2
D. Team Performance ent
Dyridrrr~tis
Prolrcr IIlannpcr Projecr warn member
Lessons Learned - Based on my performance as rated by the team using Project Assurance Technologies PM Scorecard, I need to do a better job communicating and aligning project priorities with the team. On my next project, I will incorporate discussions on project priorities at team meetings to ensure that we are aligned and make changes as a team when required.
DJECT MAN
2.0 PROJECT COMMUNICATION
21. .Project Progress Reports [What type of project progress communication does the project team agree to?] Type of Progress Report
-
*Cantents aTReport Major accomplishments, decisions, actions items needed from other team members, potential problems
Weekly project progress report
who 'rie~ue&'e'~ -' of Report Repor* Weekly - Project team due every leader Friday
'-Feq%i=
Lessons Learned - This project moved so fast that it would have helped to have daily morning traffic meetings to see what was up with each team member.
..-----
-..--.
*CI--=-
@
.- , -p/*r-.*- -,.- --
he Completed Projecl
2.2 Project Milestone Reviews (this table spans pages 208 - 209) [What needs to be reviewed before the project can progress to the next step?] tone valuate whether the project sufficiently in order to get
are in alignment with cus-
Customer service train- Ensure customer service can Project team ing manual support web ordering Database integration
Ensure site works with finance systems
Go live
Ensure that the website and the Project team employees are ready to let the customers place online orders
Lessons learned
-
.-
i
- -A'.+...-
Project team
Project team Record what was learned from launching this project to build on your experiences for future projects
__1--f--
_ -'----~. .. ..
-- -.
PROJECT MAHAGEMEHT
,.
.-_.
7 y-.7:--
,>
-.-
-~pprovalt o Move -Tl)Se of~evi'ew'- "percent FOI-war Complete
-Bud3%
- '' '
'
'
-~.-
'
t
-
Project sponsor
March 2 (one day 1% after project launch session)
1 hour for each of the 4 team members + $495 external costs
Webmaster
March 9
5%
Bruce 47 hrs
Project leader
March 9
15%
Debra 19 hrs, Ed 50 hrs, Chris 4 hrs + $1438 external costs
Programmer
March 15
2 0 OO/
Chris 15 hrs, Ed 46 hrs +$5625 external costs
,,.#-&'-
.--
!--7
.._ .---- .*fl-----. .. .
he d;lmpleted Project Agreemen
-
-
.-z
Lessons Learned - It didn't pay for us to keep too many people in the loop. It's better if we have formal reviews less frequently. This way, we can get our work done with less scrutiny and nonvalue-added oversight from people not intimately involved in the day-to-day implementation struggles. These people had no experience with launching an e-commerce application.
3.0. RISK TOLERANCE 31 Risk-Tolerance Level [How much risk (uncertainty) can the project team and the project sponsor accept with being able to create the final deliverable? Rank the tolerance level from 1 (low) to 10 (high).Low risk tolerance means that the project team has a low tolerance for uncertainty and will need to have more time and money to create the final deliverable. High risk tolerance means the project team has a higher tolerance for uncertainty (and probably less uncertainty in their ability to create the final deliverable).] Rating - 2 Reason - This project has a high market impact, so we need, to get it done. However, we are not experienced in doing Internet projects in our operation, so we have a high level of uncertainty in what it is going to take to develop the e-commerce application. Lessons Learned - People external to the project had a n even lower risk tolerance than the project team or the project sponsor. They made life difficult at times for the members of the project team with their intense and unneeded scrutiny.
4.0 CONSTRAINTS
41 Organizational Priorities [Defined in terms of cost, schedule, and quality.] Quality - Has to work very easily for our customers and has to integrate seamlessly into our existing order capture systems. Schedule - Has to be done in three months Cost - Cannot exceed $100,000 Lessons Learned -We found out while doing this project that our customers wanted more product support, and we found out through this project that our product support area needed significant revamping even without offering product support via the website. The number-one area of quality extended beyond just using the website to order products - it extended to the level of after-market support we offer for our products.
4.2 Spending Constraints [What is the estimated budget (money) you'll have to do the project?]
Lessons Learned - We came in under budget for simply setting up the e-commerce website. However, when we included the product support component, we exceeded the budget by 50 percent- although that was recouped with increasing sales.
4.3 Staffing Constraints [What staff is required to do the project, how much time will they be needed or made available, and what do you know about the availability of people who might work on the project?] Staff Required - One programmer full time, one project leader half time, one webmaster 20 hours per month, one finance person 20 hours per month, one customer service person half time. The programmer can be an outside consultant if in-house programmer does not have the skills for this application.
I
I
Lessons Learned - We outsourced the programming to a company that specialized in e-commerce. We were forced to do this when our programmer, Ed, got injured snowboarding. Jason was assigned to our account from the off-the-shelf e-commerce vendor. We spent two-thirds less than if we had used Ed to do the programming. Availability -The person who needs to do the programming has a three-day vacation planned four weeks into the project. Lessons Learned - We didn't need the programmer.
I I
I
Other Issues -Because of the high-pressure nature of this project, the project sponsor has approved a scheduled workout session, where people on the project team can take forty-five minutes off per day to exercise for the duration of this project. This exercise program is done with the approval of their healthcare professionals, if necessary. Additionally, the project sponsor has said that the project team can work no more than six days per week and no more than sixty hours per week.
JECT MAN1
Lessons Learned - It was tough for the project team members to make time during their hectic days to exercise, but when they did, it helped relieve stress levels considerably. Also, it should be mandated that staff take every other weekend off and leave work no later than 7:00 p.m. -all work and no play really hurt some people's productivity.
4.4 Equipment Constraints [What lirnitations/restrictions may be placed on equipment you'll need to do the project?] The server hosting the internal LAN does not have the capacity to host the website for the e-commerce application. The project team needs to use an outside hosting service for the e-commerce website. Lessons Learned - The IT group wanted to get its own internal secure server to host the website midway through our project. This derailed negotiations with our external secure server service, but the change-request process we used helped us quickly decide against the IT-recommended change.
4.5 Deadlines [When does the project have to be complete?] Three months from project kickoff Lessons Learned -When we hired the e-commerce applications company, we could have done the job in less than a month. But it took us some time to find them when we were forced into that route with Ed's injury.
-
> I : ----
--.
.
...- - ---.-~ __<
---
The Completed Pmjecit Agreeme
-2
&
4.6 Organizational Constraints [What constraints does the organization have for doing this project and how will that impact that project?] Has to integrate with existing business systems for accounting Impact - Programming tasks will be greater to create a custom patch to the existing business system Cannot charge customer's credit card or customer's internal account until after the goods are shipped Impact - If the website is integrated into the accounting system, an order placed on the website provides the same information to the accounting system and drives the same actions as one taken on the phone
!
Have to use a secure website-hosting service Impact - Cannot use the internal server anyway; reliable web-hosting services are widely available Have to use existing merchant account Impact -May not be Internet enabled; may have to get an Internet-enabled merchant account Have to maintain look of the existing website - Impact - May limit design and take longer.
I
Lessons Learned -Having to use the existing finance systems and merchant account really slowed us down. It would have been far easier to create these systems from scratch than to have to kludge our website system to that legacy system.
~~:-~A=.-.----,~=7"
3
,+-....-. ->.
r'-'-"-:,..;.
..
,,,,--+---.
&& PROJECT MANAGEMENT
-d-c.;*,~-
.,c"<.T7G3v.-
-t.-
5.0 TEAM RESPONSIBILITIES ' ~ e a mPosition 'Responsibility ~a%e@i/~alo~$Cb'df~B~" Half time Project leader Responsible for systems integration and coord~nationof all Alice,Pink the activities to meet the golive deadline '
''
Customer Service
Ensures that customers can use the system, and ensures that nrucer(ellow customer service people know how to talk customers through using the online ordering; ensure that order-processing system can meet the ordering delivery criteria
Half time
Wehmaster
Ensures that all website components work for new e-cusC,,, is,Purple tomer applications Ensures that e-commerce solution works with existing acDcbra,Green counting system
Quarter time
Ensures that programming works for order-capture on the Ed,Oranpe web and is integrated into accounting and order-processing systems
Full time
Finance
Programmer
-
I
I
Quarter time
-
Lessons Learned - We outsourced the programming, and now even Debra agrees that it would have been easier to use the merchant account and order-capture system from the e-commerce application provider.
1
!
1
,:
..-
,
,
'*
;it;
2;,,,= F,
..
*?+"
1 I::
::,
.
'
::
<, ,>
,
-
. . - ..,
--=-
, .
;j
mw-'
;;;,
,,, ,,,,,,, ,,,,,,, I,:':; ,,
;,; :,
-
,:
1
'.?-4
,L<;*:-;:::.:;:-, . ,.
..,.
:--.
*re &*. -.
::.nYlr2111*
,
,><
f!>
>/y-&
;-
(
.-.. .
C
8
-
#f4.&,if
9":-r
*dL
.-..>a; -. .-..':-:;_i&.*~
, ,
,
-
. ..... 'r: ..: - -*j7d * -
*3- . 7
,,,,>, . , , , , ,,,,
,,
,, ,,,,,, ,,
,I
,,:.s,:'"',: ,-.. ',_ ,, '
j.
:..::,:
I ,I
'
,,,,
,.:t.
,; ,
. ,-., ,,, ; I
>
-
>'
I
:
,,.
I
Information presented in tables and figures is indicated by t and f:
A Acceptance, in team dynamic, 7 8 Acceptance criteria, customer, 13J 33-35, 34t, 35t, 4 9 , 96-97, 98J 1OOJ 102, 108 Accountability, single-point, 133 Activity tasks schedule, 142, 143J 144, 145J 146J 147J 148-149, 150J 151 Actual Cost of the Work Performed (ACWP), 174, 176 Actual costs, 173-17 8 ACWP (Actual Cost of the Work Performed) formula, 174, 176 Adaptability, 12 Affinity diagramming, 96, 102-105, 103J 105J 106J 107J 108
Agenda for meetings, 83, 84J 85f for project launch, 17-18, 1% 19f Agreement, project, 25-64 areas of discovery in, 26-27 boundaries and, 30 budget in, 153 changes to, 179-180 communication i, 26 constraints and, 26, 47-56 customer proposal in, 33 identity and, 2 8 importance of, 25 lessons learned documentation in, 188 milestone reviews and, 42- 45, 44t objective in, 28-29
I
priorities in, 3940 risk in, 26 scope in, 26,27-28 spending limits in, 50 staffing constraints and, 50-53 team responsibilities in, 26 template for, 25,57,58f-64f timing for creating of, 57-58 APM (Accelerated project management) advantages of, 3-4 attitudes for, 14f components of, 5f conflict resolution and, 21-22 cynicism and, 13 definition of, 3 development of, 3 lessons learned in, 187-196 rules for, 183-184 scheduling advantages of, 54 Assessment, of project. See Tracking Attitude, 13,14J 68,196 Attribution, of team member contributions,77 Availability, 12
Bottom-up planning, 96, 102-105, 106J 107J 108. See also Planning Boundaries, 30, 190-19 1 Brainstorming, in affinity diagramming, 102-104,103f Breaks, 16-17. See also Food; Vacation Briefing materials, 15-16 Budget, 153-164 cash flow and, 158,159J 160-162 labor costs in, 154 methods for, 153 performance assessment and, 171-178 processes and, 108 safety factor in, 157-158 spending limits in, 50,162, 163J 164 TBD (to-be-determined),50 timing of, 164 Budgeted Cost of the Work Performed (BCWP),174,176 Budgeted Cost of the Work Scheduled (BCWS), 174, 176-177 Business case, 27,36-38,60f
B BCWP (Budgeted Cost of the Work Performed) formula, 174,176 BCWS (Budgeted Cost of the Work Scheduled), 174, 176-177 Behavior at meetings, 82-83 perception and intent in, 88t
.rG'e,:;=.-
218
y?---e
d%&&
---
-.y7---
.- '.-
PROJECT MANAI
C Cancellation of project, constraints and, 4849 Case study, publishing of, 195 Cash flow, 19J 158, 159J 160-162 Categorization, in affinity diagramming, 104,105f Changes, 168-171, 169t,170t
.?z3
~.. -*---
-"-.
_..=-
..
.
--
Chaos, in work environment, 182-183
Cleanliness, of work area, 182-183
Commitment, 7 0 , 72-74 Communication in brainstorming sessions, 102-103 at meetings, 8 1-83
of milestone reviews, 4 2 4 5 , 44t
non-value-added, 4 0 of progress, 41-42 in project agreement, 26 rules for group, 78-80 teamwork and, 12 types of, 4 0 4 1 Competition, market impact and, 36-37
Completion, lessons learned at, 189-190
Complexity milestones and, 4 3 with teams, 67-68 Computer-based planning, 15 1 Confidence levels, in time estimates, 144, 145J 146J 147J 148
Confidentiality in risk identification, 122 in team contribution, 77 Conflict anticipation of, 2 1-22 constructive vs. destructive, 85-89, 87f
expectations and, 69, 83, 85 lowthigh model of, 85, 86f observer role in, 87-88
in planning, 1 12-1 13, 1 14J ll5f
priorities and, 39 resolution of, 83, 85-90 in schedules, 112-1 13 sources of, 69 teamwork and, 75-76 Constraints cancellation based on, 4 8 4 9 categories of, 47 equipment, 53, 63f organizational, 54-5 5, 63f in project agreement, 26, 47-5 6
spending, 50, 63f staffing, 50-53, 63f time, 53-54 Contingency plans, 128, 13 1 Contributions, of team members, 77-78
Cost performance index (CPI), 174, 177
Costs actual, calculation of, 173-178 constraints and, 47-48 customer requirements and, 33 estimates of, 19f external, 156J 1 57J 158, 160-161, 161t
internal, 160t, 161 labor, 154, 155J 156-158 material, 156J 157J 158 performance assessment and, 171-178
Countermeasures, risk, 123J 128, 130J 131, 132J 133, 134f
CPI (Cost Performance Index), 174, 177
., .. lnde
Creep, 179 Criticism, in team dynamic, 7 9 customer acceptance criteria of, 33-35, 34t, 35t, 60f definition, 27, 30-3 1, 19 1 external vs. internal, 3 1, 32, 191 feedback from, 194 lessons learned and, 19 1-1 92 needs of, 32-33, 59J 191-192, 192f in project agreement template, 59f-60f requirements, 33, 59f Cynicism, 13
D Decelerators, project, 178-1 83 Decision making, rules for, 76-77 Deliverables in affinity diagramming, 104-105 customer identity and, 3 1 dependency lines and, 140, 142 high-level, 97, 98J 99J 104-105, 105, 106J 107J 108 identification of, 97, 98f; 99J l0OJ l 0 l J 102 interim, 100f; 101f; 102, 104-105, 108-109, 140, 144 market impact of, 36-37 milestones to, 42-45, 44t needs of customer and, 32-33
-.
>r.-L-..
220
---.-I;=
L%w$&
..=_ ;-x?-=---:-
..-
-C_.
.-.a,
objective and, 28-29 organizational constraints and, 54-55 in planning phase, 95, 96-97 schedule of, 140, 141J 142 types of, 95 Dependency lines, 140, 142 Disaster recovery, 3
E Efficiency, lack of, 181-182 Employees. See Labor costs; Team Environment chaotic, 182-183 cynical, 13 relaxed, 8 Equipment constraints, 53, 63f Exercise, 52 Expectations of commitment, 7 4 conflict and, 69, 83, 85 External costs, 156J 157J 158, 160-161. 161t
F Facilitation, 11-22. See also Leader agenda and, 17-1 8, 1 8J 19f project agreement and, 26-27 project launch room and, 17 selection of team and, 12-1 3, 12t time for, 13-14 Feedback from customers, 194 in team, 194-195 team member to team member, 7 9
.:--...-, -..-K
PROJECT MANAGEMENT
-*;---..
:.-=-.*..
7:<7--..
supplies for, 18, 20 Leader. See also Facilitation in brainstorming sessions,
Flexibility, 8 Food, 16-17, 7 4
G
103-104 budget and, 1 5 3
GFI (gut-feel-index) approach, 124 Guidelines, for launch, 16
I Identity of customer, 30-3 1 definition of, 2 8 of deliverable, 97 scope and, 27 Impact of changes, 168-171, 169t, 170t
market, 36-37, 38 strategic, 38 Information, assembly of, for planning, 94-96 Intentions, vs. perceptions, in behavior, 8 8 Internal costs, 160t, 161 ,
J Judgmentalism, 88
K Kennedy, John E, 29 L Labor costs, 154, 155f: 156-1 58 Launch, project agenda for, 17-18, 18f: 19f agreement template and, 57 information gathering in, 9 4 preparation time for, 13-14
computer planning tools and, 15 1
conflict resolution by, 2 1-22 feedback collection by, 194-195
milestone reviews and, 1 17 in preparations, 15 responsibilities of, 18f: 19f in risk assessment phase, 13 1, 133
role of, 4 , 13 rule set-up and, 7 6 sponsor as, 5 4 in voting, 77 Log, of lessons learned, 188-189 Lowlhigh model of conflict, 85, 86f
M Management, accelerated project. See APM Market impact, 36-37, 38 Material costs, 156J 157J 158 Meetings, guidelines for, 8 1-83 Milestones, 4 2 4 5 , 4 4 t number of, 138 in planning phase, 1 1 3, 1 17, 118f
scheduling of reviews, 138, 139f
Motivation commitment as, 72- 74 self-interest as, 70-72
lndt
Multitasking, as decelerator, 180
approaches to, 96-97 bottom-up, 96, 102 brainstorming in, 102-1 0 4 computer-based tools for, 15 1 conflict in, 1 12-1 13, 1 14J
N Neatness, in work area, 182
0
ll5f
Objective. See also Deliverable changes in, 29 concise, 29 definition of, 28-29 lessons learned phase and, 190 in project agreement template, 58f strategic impact and, 38 Objectivity, in conflict resolution, 89 Organization commitment and, 7 3 constraints of, 54-55, 63f by function, 18 1-182 inefficiency and, 181-182 priorities in, 49 of work area, 182 Organizational benefits, 37 Overworking, of team members,
flow of, 93 information assembly in, 94-96
milestones and, 43, 1 13, 1 17, 1l 8 f
outside factors and, 112 process identification in, 108-109, 1lOJ 111J 112
steps for, 95-96 top-down, 96, 102 tree diagram for, 1 13, 1 16f vs. process, 20 Politics, and team dynamic, 80 Preparation importance of, 20 materials for, 1 5-1 6 responsibilities of facilitator in, 15
time, 13-14 vs. process, 20 Pressure, conflict and, 85, 86f Preventative measures, 128, 13 1 Priorities categories of, 39-40 changes and, 168-171, 169t,
180-181
P Participation, importance of, 5 Performance tracking, 17 1-1 7 8 , 173t, 175t 176t, 177t, 178t
Personality, risk tolerance and, 45 Personal problems, and team dynamic, 80 Planning, 93-1 19 affinity diagramming in,
170t
importance of, 184 of organization, 4 9 scope and, 27-28 Probability, risk and, 124, 125J
102-105, 103J 105J 106J 107J 108
~,, - . - - .o. -
222
126, 126t, 127-128
..
.
m4-.4--.- - - - * -
PRO,
-17.1
Problem solving, communication and, 7 8 Process definition of, 2 1 inefficient, 181-182 in planning phase, 108-1 09, l l 0 f ; l l l f ; 112 review of, after completion, 193-194 vs. plan, 20 Progress, 41-42, 4 2 4 5 , 44t. See also Tracking Project management, accelerated (APM) advantages of, 3-4 attitudes for, 14f components of, 5f conflict resolution and, 2 1-22 cynicism and, 13 definition of, 3 development of, 3 rules for, 183-184 scheduling advantages of, 54 Project Management Scorecard web tool, 194-195 Psychology of commitment, 7 3 of group dynamic, 7 5 Punctuality, 16
R Refreshments, 16-17 Religious beliefs, and team dynamic, 80 Reports, progress, 4 1 4 2 Risk, 121-135 calculation of, 123-1 24, 126-128
countermeasures, 123J 128, 130f; 131, 132J 133, 134f high tolerance for, 46 identification of, 122-123, 125f impact of, 126, 127t low tolerance for, 45- 46 probability, 124, 12 5J 126, 126t, 127-128 in project agreement, 26 in project agreement template, 62f-63f quantification of, 129f stability and, 4 6 strategic impact and, 38 tolerance, 128, 1 3 1 uncertainty and, 4 5 Room, project launch, 17 Rules, 75-80
S Satisfaction, customer, 33-35, 34t, 35t Schedule Performance Index (SPI), 175, 177-178 Schedules, 137-1 5 1. See also Timing of activity tasks, 142, 143f; 144, 145f; 146f; 147f; 148-149, 150J 151 advantages in APM, 54 components of, 7-8 confidence levels in, 144, 145f; 146f; 147f; 148 conflicts in, 1 12-1 13 for deliverables, 140, 141f; 142 dependency lines in, 140, 142 estimation in, 144
of milestone reviews, 138, 139f
off-time in, 5 1 over-scheduling, 180-18 1 processes and, 108 in project agenda, 19f time calculation and, 148-149, 149t, 150J 151
time constraints and, 53-54 timing for, 15 1 Scope in agreement, 27-28 elements of, 27-28 time allotted to creation of, 57 Self-confidence, 12 Self-interest, 69-72 Shyness, of team members, 77 Site, for project launch, 17 Socialization, commitment and, 7 4 Spending limits, 50, 63J 162, 163J 164
SPI (Schedule Performance Index), 175, 177-178 Sponsor, project attitude of, 14f budget and, 154 constraint definition and, 47 in formal projects, 12 identity and, 28 leadership of, 54 role of, 4 spending limit and, 162 staffing limits and, 51 Staffing constraints, 50-53, 63f Status reports, 171-178, 173t, 175t 176t, 177t, 178t
#& PRO,
Storytelling, and communication of lessons learned, 195-1 96 Strategic impact, 38, 41, 60f Subjective terms, in acceptance criteria, 34-35 Subprojects, 43 Supplies, 18, 20, 53 Surprises, 167-168
T Teamlteamwork, 67-90 agenda for, 17-18, 18J 19f attitude of, 14f brainstorming by, 102-104 changes in, 180 characteristics of, desirable, 12t commitment of, 72-74 communication within, 12, 40-41, 78-80
conflict within, 2 1-22, 75-76, 83, 85-90, 86J 87f
constraints of members, 5 1 contributions within, 77-78 creep phenomenon within, 179
decision making by, 76-77 dynamics, 68-69,75, 180 exercise for, importance of, 52 feedback from, 194-1 95 feedback within, 7 9 labor cost calculation by, 156-1 57
leadership of, 13-1 5 makeup of, 4 meetings of, 81-83 multitasking within, 180 obstacles in, 68 overworking of, 180-18 1
participation within, 77- 78 perception vs. intent within, 88t progress reports and, 41- 42 in project agreement, responsibilities of, 26 ramifications of actions within, 168 responsibilities of, 185 195 56-57
responsibility for, 20 of risk assessment, 133, 135 of rule development, 9 0 of scheduling, 15 1 Tolerance, of risk, 128, 13 1 Tools, 18, 20 Top-down planning, 96, 102. See also Planning Tracking, 167-187 changes and, 168-171, 169t,
risk identification by, 122-123, 125f roles in, 4 , 56 rules for, 75-80 selection of, 12-1 3, 12t self-interest and, 69-72 shyness within, 7 7 size of, 56
staffing constraints and, 50-53 vacations for, 5 1 Time insurance, 148 Timing. See also Schedules of budgeting, 164 calculation of, 148-149, 149t, 150J 151
constraints on, 53-54 of meetings, 81-82, 8 3 of planning, 1 19 for project agreement creation, 57-58
170t
decelerators and, 178-18 3 status reports and, 17 1-17 8 , 173t, 175t 176t, 177t, 178t tools for, 167 Tree diagram, 1 13, 1 16f
U Uncertainty, risk and, 4 5
V Vacation, 5 1. See also Breaks Volunteering, commitment and, 7 4 Voting on risk impact, 127, 127t 126 on risk probability, 124, 126 rules for, 76-77
Cheetah Project Management Online Course The Fastest W
ach Your Goals
You've read the book, now take the course! Do you want to know how to implement Cheetah Project Management to launch, direct, and manage project teams? Learn how to use accelerated learning principles to accelerate your projects. Apply what you're learning to your work environment and build your career in real-time. You'll learn the same techniques that have allowed Cheetah Learning to grow our business exponentially over the past two years. Parricipants also learn how to use Cheetah Project Management to schedule, budget, and manage resources.
Course Detail Credit Cost Duration
5/20 hcii~r~ See webs.ire for cnrr
-
LO ImurC (?mu ~ 1 1 1131~~ 1
cisht weeks to access the online CI jntent and intera n with vnur instructor) Course h a t i o n - Online Course Material .!il proviided online Accreditation PMI R. 6.I!. LACE'
-
Registration and Information: www.cheetahpm.com or (800) 246-9106
Cheetah PM Master's Lertlhcate Yrogram L
Leader in Project Management
fire you achiwing your putentiall Become a Cheetah. llemonstrate you a n succcrsfdy lead e n t Master's Certificate. projects. Earn the Cheetah Projecr
Cheetah's PM Master's Certificate vrvldcs a common bme of knowledge, skills and tools &&ti4 for suFcesd&rof%&bL T& pr;;grq&& 0 8%9N pro#on>s who want to cornpeten+& p r o j e a*to.~m"tMe "'their career success. A+ 4 " " &gg* -xf<* -a *
.
8
#
k&
The ZOO hour, 7 c o ~ ~ l i n e ~ ~ acb d~ ku - m deals thei@re Pr$ect M ok pym* it oes $1 beyond the Body of Knowledge & Y h n i z e d by &j is h g n e d f p r m a n a s basic knowledge foundations o M u k+ i n g , Operation# S 4 - d*C' E m e e r e . in all fields and professions inc jb
>
>*WY
*C
-
"
Course Details Cost
.
-
. ..
-
-
:c website t ricing tnonrhs to
Duration
L1
Course Location - C Course Material
ion -
-
will bc nccaea: . i ofwhich ars ~cludedin 1the price of le course isrruucinns provided Urhen you w
14
P MI' R.E.P.
Registration and Information: www.pmmasterscerGficate.com or (800)246-9106
-.
"i
%& ble ofgiving them The Cheetah PM Master's Certificate informs employers that-you a competitive edge with managing a project from start to finish using proven F & f ! @ Managet ment methodologies, techniques and tools.
Michelle LaBrosse
t/
sing current methods of accelerated learning, project management, and negotiations, Michelle LaBrosse has grown her company, Cheetah Learning, into the profitable mar-
ket leader in project management training in just four years. Michelle has a B.S. in aerospace engineering from Syracuse University and an M.S. in mechanical engineering from University of Dayton. She is a graduate of Harvard Business School's Owner President Management Program for entrepreneurs of fast-growing companies. In addition to publishing articles o n accelerated learning, project management, and business development, LaBrosse speaks to audiences in the U.S. and abroad on these topics. Michelle LaBrosse is the co-author of Cheetah Negotiations and is profiled in Rich Dad's Success Stories.
U L A F PRESS