sizin için seçtiklerim: amazon highlights: The Project Manifesto / Rob Newbold, Bill Lynch / 2014

The Project Manifesto: Transforming Your Life and Work with Critical Chain Values by Rob Newbold, Bill Lynch

Last annotated on November 6, 2014

http://www.prochain.com/projectmanifesto

We have developed mechanisms to help us manage our limited time:

#1: Try to make everyone happy.

#2: Prioritize by urgency, pushing the least urgent things over the horizon and into the future.
#3: Become more efficient.
The end result is the same: less time, less satisfaction, more difficult choices.

we have pinpointed the cause of the problem to four common cultural values.

1. Everyone values responsiveness, even though we can’t respond to everything.

      2.      Everyone values getting things started, even when there’s no time to finish them.
      3.     Everyone values achieving deadlines, even though the competing deadlines bog us down.
      4.    Everyone values meeting personal goals, even when they come at the expense of other goals we care about.

I started in. “What is the objective of this project?” As every experienced project manager knows, if you don’t know where you’re going, it can take an awfully long time to get there.

I continued with the next item. “The project charter also has a place to capture assumptions or necessary conditions we think may be important in getting this project done. Our next job was to identify risks.

No one argued when I put “we don’t know what we don’t know”

We need to value speed.

You can’t fully understand how bad multitasking is until you’ve tried not multitasking.

We need to run a relay race.” I paused to think for a moment. “Do one thing at a time, as quickly as possible; then hand it off. And for a project, handoffs aren’t just tasks, but any use of your time—or misuse of your time—that might slow down the race.

we need to value priorities,

If you value everything, you value nothing.”

The Agile Manifesto was the result of a meeting between a bunch of agile management gurus in 2001. It’s hard to get experts to agree on anything, especially on what’s important and what’s not. Their brilliant innovation in agreeing on values was, instead of saying ‘X is important,’ saying ‘X is more important than Y.’

We value priorities over responsiveness.

if responsiveness is put in terms of priorities. That is, you need to prioritize the things you need to respond to. Then it’s all just a matter of priorities.”

Standard #1: Work to your priorities.

Standard #2: Agree on global priorities.

Standard #3: Work tasks from start to finish, as quickly as possible; then hand off the work.

Standard #4: Create credible project schedules.

“Approval. Everyone wants to know that they’re doing well.” I think agreeing on the right values, shared values, is going to be really important in working together better.

“One of the biggest causes of project failure is inadequate planning. When people plan poorly, they do the wrong stuff in the wrong order and the wrong way. I suspect that may be a problem Aurora has already suffered from. We’ll finish this project as quickly as we can, but you’ve got to let me do my job.”

Schedules are often created and then never really used.

Roger’s Scheduling Process

· Start with a project charter.

· Create a high-level map of the needed work.

· Build your project schedule by starting at the end of the project and working earlier in time.

· Keep the schedule current.

Roger’s Scheduling Rules

· Maximize credibility—for everyone.

· Create and maintain the schedule with the whole team.

· Have as few endpoints as possible.

· Make sure all task names, except possibly a few key milestones, have verbs and objects.

· Understand “done” for every task.

Starting with the endpoint, “Ready to launch the mePod,” I entered the task names, added durations, and validated the connections between tasks. Following my rules, especially working backwards from the project end, took some time. People weren’t used to thinking in a disciplined way.

The detail may help people manage their individual tasks, but it doesn’t help manage the overall project. I pointed out that if adding detail doesn’t help in achieving the relay race, it probably doesn’t need to be in the schedule. too much detail reduces your flexibility in making decisions based on current information. In the end, we started attaching notes and checklists to the tasks to manage the detail. That made the schedule itself simpler, with the detail still available to the people who wanted it.

Even something as simple as coming up with task names started with a few bumps, because I insisted on verbs; otherwise, there’s no way of knowing what the real work is.

I’d much rather clarify what’s going on with “Write initial manufacturing specs”

We did have several debates about task connections and durations, but finally we got a complete set of tasks and the linkages between them—a so-called “project network”—that made sense to everyone.

The resource picture remained to be seen. I explained that when task names are set up with verbs and objects, the resource names become the “subject” and each task becomes a kind of sentence.

I almost never recommend using the names of individual people as the resources, because it makes the schedule very inflexible. Usually there are several people who can do the work. But our team was so small that many things could be done by only one person. In order to make sure the schedule was credible, I thought we needed individual names.

If there’s one thing I hate more than a know-it-all, it’s a patronizing know-it-all.

It seems obvious, because if you keep starting things without finishing them, you’re more and more likely to multitask, and everything will take longer.

“The critical path is the longest path through the project. It determines the completion date—except when you have resource limitations. Usually the critical path doesn’t account for limited resources, but this software does. It calculates the ‘critical chain,’ which is the longest path taking into account scarce resources.” I showed them that the first step was to revisit the links and durations, making sure they were right.

Standard #5: Each day, determine your top-priority task.

Regular meetings are a good way to monitor the schedules and risks. Making them into daily standups can also be a good way to build teamwork.

Standard #6: Report honest status (days remaining) to the best of your ability.

“What kind of needs, Roger?” “One is obviously survival—food, drink, shelter, protection, things like that. Another is reproduction, so that we can survive as a species.”

“You don’t want to be too early, because nobody wants to admit that there was extra time in their estimates. Next time you wouldn’t get as much.” “And if I have other things to do, some of those things will seem more urgent than the work we’re talking about.” “And if you’re late, next time you want more safety time.” if things don’t have to happen at the same time, you don’t need dates.”

Paradigm: Relay Race

1. We value priorities over responsiveness.

2. We value finishing over starting.

3. We value speed over deadlines.

it took only a couple of hours to take the safety time out of the durations. We decided to call them “focus durations.” It sounds like negotiation, but it was actually peeling off the residue of years of negotiations. “The critical chain is the set of tasks that, according to the project schedule, keeps the project from being completed earlier. The critical chain takes into account resource limitations.” “The tasks in a project network should not have safety time included in their durations. Instead, the safety time is taken out of the tasks and aggregated into a project buffer, which is put at the end of the project. That buffer protects the completion of the project from variation along the critical chain.”

“If tasks on the critical chain go slowly, they consume buffer. If they go quickly, they add buffer. You can use buffer consumption and recovery to test the likely effects of planned actions.” for example, to check the impact of adding an extra person to a project, you could add him to the schedule and see how buffer consumption would change?” “Some references mention relay race concepts. Critical chain schedules are supposed to be helpful in running the relay race. However, the evidence suggests that the relay race is often not used with critical chain scheduling.”

“Critical chain tasks are susceptible to delays from non-critical tasks. If those non-critical tasks are too late, they may push out the critical chain and delay the project. Therefore, there is another concept, the feeding buffer, which protects the critical chain itself. Feeding buffers are tasks, representing safety time, that are put at points where non-critical-chain tasks feed the critical chain. Just as a project buffer is used to protect the project endpoint from variation on the critical chain tasks, feeding buffers are used to protect the critical chain itself from variation in non-critical-chain tasks.”

I decided to use the newer approach that didn’t include the feeding buffers.

we can represent project status with a graph that shows how buffer is consumed as the project is being completed. It’s called a fever chart, and it helps us see how we’re doing compared with our commitment date.” “Each dot represents a status point. The dots move from left to right as the project is completed and from bottom to top if buffer is consumed. As long as the dots don’t go above 100 percent buffer used when the project work is completed, we’re still within our buffer window, and we still make our commitment date.”

mean?” “If a status point goes up into the red area, we’re in significant danger of missing our commitment date. We’ve consumed buffer too rapidly and we’ll need to take action quickly to recover it. The middle yellow area means we’re in some danger but don’t need to panic.” propose we use this to see how we’re doing. I’ll also give it to the Leadership Team. That should make our meetings go quickly.”

I explained that if we completed critical chain tasks more quickly than expected, if we beat our focus durations for those key tasks, our scheduled endpoint would move earlier and we would recover buffer. The simplest method, and apparently pretty common, is to just take half of the duration of the critical chain. a realistic range of when the project is likely to be completed. Within that range, we can’t really be precise, so all we need is something that’s good enough.

We should always run the relay race. The values don’t mean we don’t value the deadline, just that we value speed more. We want to finish as early as possible before the deadline, but we’re never okay with being late. The fever chart colors just tell us how we’re doing with the deadline.”

It seems as if I keep learning the same lesson: any time I think I have all the answers, I’m probably not asking the right questions. I think we should flip the fever chart, so the vertical axis shows buffer remaining instead of buffer consumed. We should also blend the colors together so the regions are fuzzier. “It just clarifies what we want. Think of the vertical axis as a gas gauge, and the horizontal axis as the distance left to go. We’d like to end the trip using as little gas as possible. If we use up all the gas before we get to the destination, we’ll have to refill, kind of like rescheduling. We’d miss our commitments and that would be bad. But the more gas we have left at the end, the better we’ve done.”

we’re working to keep our schedule credible for everyone, and at the same time save safety time for the buffer, we can actually celebrate improvements and still keep safety time out of the basic schedule.” We have to be careful that people don’t think adding safety time will make them look better. It’ll help if we emphasize speed over deadlines and make sure everyone is on the same page with the schedule. I think the speed chart will help, too.”

“We’ve put aggressive focus durations into the schedule. Just based on that, I’d say there’s a better than even chance that we’ll consume at least some buffer. Given all the uncertainty in the project, we may consume a lot. If we try to hold people to their aggressive times, two things are possible. Maybe they’ll make the times. Or maybe it’ll become clear that they’re going to be late, and they’ll stop worrying about it. Then anything could happen. Either way, on time or late, we will have destroyed the relay race. And without that, you can forget about getting this project done as quickly as possible.”

I was pretty sure he had never actually measured the quality and quantity of the work his people did when motivated externally, by stress applied by management, compared with when they were motivated internally, by personal satisfaction. “I think people perform better when they think they have the freedom to do what’s right. Challenge them to be as early as possible, motivate them, maybe even set aggressive targets, but allow them to be late if necessary. We should give them the freedom to do things right. If you just motivate people by dates, the dates tend to dominate. Then people probably won’t be motivated towards speed, or quality, or creativity.”

The critical chain changed as work on particular tasks went faster or slower than we had expected and as our understanding of the needed work grew. That meant we had to continue talking about which tasks were critical or almost critical and how we might get them done more quickly.

Standard #7: Look for ways to improve focus. When working on key tasks, minimize meetings; turn off email, instant messaging, and phones; find quiet places to work.

We eventually settled on a simple four-color classification process: dark red, red, yellow, green. Dark red was for critical non-project work that just couldn’t wait. To be dark red, it had to be urgent and very important. Red was for key project tasks (tasks on or near the critical chain); yellow was for non-key project tasks; and green was for everything else. Everyone also set aside an hour twice each day for email and staying in touch, so that we wouldn’t feel as strong a need to interrupt our work by checking email all the time.

made a chart that would fit on a small card. He added the times we set aside for email as “planned interruptions” and created the acronym PICK ME: Planned Interruptions, Critical non-project work, Key project tasks, More flexible project tasks, and Everything else.

Standard #8: Don’t switch to lower-priority tasks; avoid asking and avoid agreeing.

Personal Manifesto: to value what I love over what I need.

Standard #9: Work as a team to share and recover buffer time.

We found that often, people who aren’t working the key tasks can help those who are.

formal Update Checklist: Make sure everyone is present. Make sure all updates are entered into the schedule. Discuss any needed changes to the schedule. Review project issues and risks. Discuss what’s key (on or near the critical chain). Talk about how we can help each other recover buffer. Determine whether anything is blocked and, if so, fix it. Share better ways of running the relay race.

I concluded that a lot of the variation in how long things take is self-inflicted. We create uncertainty by being responsive, starting too many things, and creating innumerable deadlines. With better management and better focus, we could complete tasks and projects far faster and more predictably.

“I guess nobody has really looked at projects from a holistic perspective before. As long as the work moved along and some things eventually finished, as long as the budgets weren’t too far off, nobody had a strong incentive to dig down and work out the details. It takes a lot of communicating.”

Even with the values and work standards, it’ll be a challenge to get everyone to change the way they work. Plus we’ll need to develop some standard project management processes, or else we’ll never be able to get everyone on the same page. We’ll have to build internal expertise and internal experts. We may even want to go to a certification program, like Six Sigma uses.”

We’re going to need to set priorities for the different projects so that you can manage the conflicts for resources. If people’s incentives are wrong, if they’re not aligned with the behaviors you want, it’s going to be pretty tough to get people to change.”

“It’s the same as rolling out a new product to the market. You need a message and you need a way to get it out. If people just think, ‘Hey, they’re changing everything,’ they may come to some conclusions you don’t like. If you give people enough information that they understand what you’re doing and see the value, if you set the right expectations, there’s a good chance they’ll cooperate. It’s basic marketing.”

“Everything you’re doing—the Senior Leadership Team, the communication plan, the schedules—everything is targeted towards getting people to own the relay race. If it’s theirs, they’ll accept it. If it’s not, they won’t. It’s as simple as that. Your job,” he pointed at me, “is to get everyone to take ownership.”

We may also need to talk about measurements.” “You mean as in performance reviews and bonuses?”

Standard #10: When in doubt, communicate. Both ways.

The more you communicate, the more trust you can build, the better your relationships and the more you can help each other. In product development, people don’t do that well, and a lot of initiatives fail. This is a critical piece of what you’re doing.” “I’ve been practicing focusing.”

Standard #2: Agree on global priorities, taking into account relative value.

Standard #4: Create credible project schedules that include the work of all functions.

were lucky that we had started with values. If we had tried to implement the new software system without fully understanding the values it was supposed to support, we would have gotten into trouble. People would have used the system to support business as usual: responsiveness and deadlines. Knowing our values and knowing what we wanted to accomplish made a huge difference.

used the software to show individuals and managers their tasks and priorities, even when they worked on multiple projects. The clear priorities gave people confidence that they were working on the right things. That made them more comfortable focusing on one thing at a time, which improved both speed and quality.

Paradigm: Relay Race

1. We value priorities over responsiveness.

2. We value finishing over starting.

3. We value speed over deadlines.

4. We value shared goals over individual goals.

“You can pay them to everyone based on how the company is doing. Could be based on salary level or seniority. We may be able to give stock options through FD’s options program. And there’s no reason some people shouldn’t get spot bonuses or extra stock options for extraordinary performance.

“Basing bonuses on the results of a survey would be a bad idea. But it will be really important to give people feedback about how they’re doing and how they could improve. I expect these values are going to represent a big change for most people, so we’ll all need data on how it’s going.”

“Buffers are shared safety time, instead of individual safety time. Credible schedules are shared information, rather than hoarded information.” “That could be the most important piece of all: the idea that people need to communicate honestly and share information.” valuing shared goals over individual goals, into our communication plan. We decided to create a public list of team successes in recovering buffer: here’s what people did, here’s how they did it, here’s what they achieved. That way we could recognize extraordinary efforts towards project acceleration, sharing ideas while giving credit for them, without creating any conflicts.

“If your people have a conflict they don’t know how to resolve, if they think hitting their goals might make something worse for the company, they should come to you. If you don’t know how to resolve it, you should go to your manager. And you should always know who’s screwing around, whether they’re hitting their goals or not.”

Even if everyone agreed that the relay race made sense, and by this time most people did, every individual had to be able to answer two questions: Am I doing what I should be doing? Are we doing what we should be doing?

The second question wasn’t so hard. We answered it for project managers, using our Update Checklist. It told everyone how well project teams were doing in running the relay race. We also worked with HR to help managers assess their people on important capabilities. We put together a non-threatening survey that helped us gauge how well people were running the relay race. Questions asked whether people were following priorities, starting things that could be finished, working quickly without being diverted by deadlines, and working towards shared goals.

The first question was much harder. We had tried to address it with the fifth work standard: “Each day, determine your top-priority task.” The problem is, people have a tendency to do what they’ve always done and rationalize it later. That makes it hard to answer the first question honestly. Meanwhile, routine habits were heavily ingrained; people needed a lot of reminding. It was like they really wanted to race around the track, but they still felt a need to keep stopping to talk to people in the stands.

Functional managers still wanted to look at intermediate milestones, because assessing how people were really performing wasn’t easy. We had to keep finding ways to get people to think about the values, because otherwise they would manage work the way they always had: with multitasking and deadlines.

we decided that the important thing for us was the question, “Am I doing what I should be doing?”—not the answer. People needed to think about the question for themselves, frequently. This realization led us to start a program to expand our fifth work standard with an automated reminder system. We said people had to use the system for at least three weeks and then could opt out. seeing the pilot results, we decided to open the system to the whole company. data helps in running the relay race, put it in; if not, leave it out.

Once a schedule was in execution, teams didn’t usually need daily standups. We did require that they have at least weekly meetings to review the schedule and maintain the Update Checklist. We were frustrated that the changes weren’t happening more quickly, despite all our work. But our successes encouraged us to keep going.

We decided that pipeline management needed to be an urgent topic of our second Senior Leadership Team meeting. We wanted to look at all our projects as a single pipeline through which the work flowed, from ideas to products. We needed to agree on mechanisms for starting projects, assigning resources to them, and committing to “need” dates, in order to get products through the pipeline and onto the market as quickly as possible.

We had a great start: with our critical chain schedules, we were able to analyze resource loads, at least for a few key resources. It was credible data, in use by project teams, rather than made-up numbers reflecting arbitrary guesses. We could use the resource load information to reallocate people to where they were most needed and to make sure that people didn’t start too many new projects.

I learned that when the communication starts to seem like too much, it’s probably just about enough.

By the fall, pipeline management was up and running and an integral part of Malloy’s process for managing its portfolio of projects. Projects had to be prioritized, and they weren’t allowed to start until the Management Portfolio Team and the software said it was okay. Need dates were starting to make sense. Deadline measurements were gone. We had cemented the Project Manifesto values into the organization.

The Project Manifesto Values

The Project Manifesto values describe conflicts that people frequently feel when doing project work. The values give a direction for resolving the conflicts: We value A over B. B is important, but it should be put in the context of A.

Paradigm: Relay Race

We value priorities over responsiveness. We value finishing over starting. We value speed over deadlines. We value shared goals over individual goals.

Work Standards

The work standards are concrete, actionable ways of expressing the Project Manifesto. They provide a shared way of looking at the values.