Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Book Excerpt: The Art of Project Management 138

Posted by Hemos from the whatever-you-make-of-it dept.
I've been reading a new book from O'Reilly which, despite my intense aversion to books of this type, outshines its class. Scott Berkun, has written The Art of Project Management. While my own review of it is tardy and still forthcoming, he & the fine folks at ORA have sent us an excerpt. Below is Chapter 13 - well worth reading, and getting the book.
The Art of Project Management
author Scott Berkun
pages
publisher O'Reilly
rating
reviewer Excerpt
ISBN 0596007868
summary

The Art of Project Management

Chapter 13: How to make things happen

*

One myth of project management is that certain people have an innate ability to do it well, and others do not. Whenever this myth came up in conversation with other project managers, I always asked for an explanation of that ability—how to recognize it, categorize it, and, if possible, develop it in others. After discussion and debate, the only thing we usually identified—after considering many of the other topics and skills covered elsewhere in this book—is the ability to make things happen. Some people are able to apply their skills and talents in whatever combination necessary to move projects forward, and others cannot, even if they have the same or superior individual skills. The ability to make things happen is a combination of knowing how to be a catalyst or driver in a variety of different situations, and having the courage to do so.

This ability to drive is so important to some that it's used as a litmus test in hiring project managers. Even if PMs can't precisely define what the ability is without making at least some references to other skills, they do feel that they can sense or measure it in others. For example, an interviewer needs to ask herself the following question about the candidate: "If things were not going well on some important part of the project, would I feel confident sending this person into that room, into that discussion or debate, and believe he'd help find a way to make it better, whatever the problem was?" If after a round of interviews the answer is no, the candidate is sent home.(1) The belief is that if he isn't agile or flexible enough to adapt his skills and knowledge to the situations at hand, and find ways to drive things forward, then he won't survive, much less thrive, on a typical project. This chapter is about that ability and the skills and tactics involved.

Priorities make things happen

A large percentage of my time as a PM was spent making ordered lists. An ordered list is just a column of things, put in order of importance. I'm convinced that despite all of the knowledge and skills I was expected to have and use, in total, all I really did was make ordered lists. I collected things that had to be done—requirements, features, bugs, whatever—and put them in an order of importance to the project. I spent hours and days refining and revising these lists, integrating new ideas and information, debating and discussing them with others, always making sure they were rock solid. Then, once we had that list in place, I'd drive and lead the team as hard as possible to follow things in the defined order. Sometimes, these lists involved how my own time should be spent on a given day; other times, the lists involved what entire teams of people would do over weeks or months. But the process and the effect were the same.

I invested so much time in these lists because I knew that having clear priorities was the backbone of progress. Making things happen is dependent on having a clear sense of which things are more important than others and applying that sense to every single interaction that takes place on the team. These priorities have to be reflected in every email you send, question you ask, and meeting you hold. Every programmer and tester should invest energy in the things that will most likely bring about success. Someone has to be dedicated to both figuring out what those things are and driving the team to deliver on them.

What slows progress and wastes the most time on projects is confusion about what the goals are or which things should come before which other things. Many miscommunications and missteps happen because person A assumed one priority (make it faster), and person B assumed another (make it more stable). This is true for programmers, testers, marketers, and entire teams of people. If these conflicts can be avoided, more time can be spent actually progressing toward the project goals.

This isn't to say those debates about priorities shouldn't happen—they should. But they should happen early as part of whatever planning process you're using. If the same arguments keep resurfacing during development, it means people were not effectively convinced of the decision, or they have forgotten the logic and need to be reminded of why those decisions were made. Entertain debates, but start by asking if anything has changed since the plans were made to justify reconsidering the priorities. If nothing has changed (competitor behavior, new group mission, more/less resources, new major problems), stick to the decision.

If there is an ordered list posted up on the wall clarifying for everyone which things have been agreed to be more important than which other things, these arguments end quickly or never even start. Ordered lists provide everyone with a shared framework of logic to inherit their decisions from. If the goals are clear and understood, there is less need for interpretation and fewer chances for wasted effort.

So, if ever things on the team were not going well and people were having trouble focusing on the important things, I knew it was my fault: either I hadn't ordered things properly, hadn't effectively communicated those priorities, or had failed to execute and deliver on the order that we had. In such a case, working with prioritization and ordered lists meant everything.

Common ordered lists

By always working with a set order of priorities, adjustments and changes are easy to make. If, by some miracle, more time or resources are found in the schedule, it's clear what the next most important item is to work on. By the same token, if the schedule needs to be cut, everyone knows what the next least important item is and can stop working on it. This is incredibly important because it guarantees that no matter what happens, you will have done the most important work possible and can make quick adjustments without much effort or negative morale. Also, any prioritization mistakes you make will be relative: if work item 10 turns out to have been more important than work item 9, big deal. Because the whole list was in order, you won't have made a horrible mistake. And besides, by having such clear priorities and keeping the team focused on them, you may very well have bought the time needed to get work item 10 done after all.

For most projects, the three most important and most formal ordered lists are used to prioritize project goals, features, and work items (see Figure 13-1). The project goals are typically part of the vision document (see Chapter 4) or are derived from it. The lists of features and work items are the output of the design process (see Chapters 5, 6, and 7). Because each of these lists inherits priorities from the preceding list, by stepping up a level to reach a point of clarity and then reapplying those priorities back down to the level in question, any disputes can begin to be resolved. Although this may not always resolve debates, it will make sure that every decision was made in the context of what's truly important.

*
Figure 13-1. The three most important ordered lists, shown in order.

Other important things that might need ordered lists include bugs, customer suggestions, employee bonuses, and team budgets. They can all be managed in a similar way: put things in the order most likely to make the project or organization successful. No matter how complex the tools you use are (say, for bug tracking), never forget that all you're doing is ordering things. If the tools or processes you use don't help you put things in order and carry out that order, find a different tool or process. Bug triage, for example, where people get in a room and decide when a bug should be fixed (if at all), is really just a group process for making an ordered list of bugs. The bugs might be classified by group rather than on an individual bug-by-bug basis, but the purpose and effect are the same.

If you do use the three most common ordered lists, make sure that they always map to each other. Every engineering work item should map to a feature, and every feature should map to a goal. If a new work item is added, it must be matched against features and goals. This is a forcing function to prevent random features. If a VP or programmer wants to slip something extra in, she should be forced to justify it against what the project is trying to achieve: "That's a great feature, boss, but which goal will it help us satisfy? Either we should adjust the goals and deal with the consequences, or we shouldn't be investing energy here." If you teach the team that it's a rule to keep these three levels of decision making in sync, you will focus the team and prevent them from wasting time.

Priority 1 versus everything else

Typically, these ordered lists have one important line dividing them into two pieces. The top part is priority 1: things we must do and cannot possibly succeed without. The second part is everything else. Priorities 2 and 3 exist but are understood to be entirely different kinds of things from priority 1. It is very difficult to promote priority 2 items into priority 1.

This priority 1 line must be taken very seriously. You should fight hard to make that list as small and tight as possible (this applies to any goal lists in the vision document as well). An item in the priority 1 list means "We will die without this." It does not mean things that are nice to have or that we really want to have: it gives the tightest, leanest way to meet the project goals. For example, if we were building an automobile, the only priority 1 things would be the engine, tires, transmission, brakes, steering wheel, and pedals. Priority 2 items would be the doors, windshield, air conditioning, and radio because you can get around without those things. The core functionality of the automobile exists without them; you could ship it and still call it a car.

Putting this line in place was always very difficult; there was lots of arguing and debating about which things customers could live without or which things were more important than others. This was fine. We wanted all of the debating and arguing to take place early, but then move on. As painful as it would be, when we were finished, we'd have a list that had survived the opinions and perspectives of the team. We could then go forward and execute, having refutations and supporting arguments for the list we'd made. Having sharpened it through debate and argument, we were ready for 90% of the common questions or challenges people might have later on (i.e., why we were building brakes but not air conditioning) and could quickly dispatch them: we'd heard the arguments before, and we knew why they didn't hold up.

The challenge of prioritization is always more emotional/psychological than intellectual, despite what people say. Just like dieting to lose weight or budgeting to save money, eliminating things you want (but don't need) requires being disciplined, committed, and focused on the important goals. Saying "stability is important" is one thing, but stack ranking it against other important things is entirely different. Many managers chicken out of this process. They hedge, delay, and deny the tough choices, and the result is that they set their projects up to fail. No tough choices means no progress. In the abstract, the word important means nothing. So, ordered lists and the declaration of a high priority 1 bar forces leaders and the entire team to make tough decisions and think clearly.

Clarity is how you make things happen on projects. Everyone shows up to work each day with a strong sense of what he is doing, why he's doing it, and how it relates to what the others are doing. When the team asks questions about why one thing is more important than another, there are clear and logical reasons for it. Even when things change and priorities are adjusted, it's all within the same fundamental system of ordered lists and priority designations.

Priorities are power

Have you ever been in a tough argument that you thought would never end? Perhaps half the engineers felt strongly for A, and the other half felt strongly for B. But then the smart team leader walks in, asks some questions, divides the discussion in a new way, and quickly gets everyone to agree. It's happened to me many times. When I was younger, I chalked this up to brilliance: somehow that manager or lead programmer was just smarter than the rest of the people in the room, and saw things that we didn't. But as I paid more attention, and on occasion even asked them afterward how they did it, I realized it was about having rock-solid priorities. They had an ordered list in their heads and were able to get other people to frame the discussion around it. Good priorities are power. They eliminate secondary variables from the discussion, making it possible to focus and resolve issues.

If you have priorities in place, you can always ask questions in any discussion that reframe the argument around a more useful primary consideration. This refreshes everyone's sense of what success is, visibly dividing the universe into two piles: things that are important and things that are nice, but not important. Here are some sample questions:

  • What problem are we trying to solve?

  • If there are multiple problems, which one is most important?

  • How does this problem relate to or impact our goals?

  • What is the simplest way to fix this that will allow us to meet our goals?

  • If nothing else, you will reset the conversation to focus on the project goals, which everyone can agree with. If a debate has gone on for hours, finding common ground is your best opportunity to moving the discussion toward a positive conclusion.

Be a prioritization machine

Whenever I talked with programmers or testers and heard about their issues or challenges, I realized that my primary value was in helping them focus. My aim was to eliminate secondary or tertiary things from their plates and to help them see a clear order of work. There are 1,000 ways to implement a particular web page design or database system to spec, but only a handful of them will really nail the objectives. Knowing this, I encouraged programmers to seek me out if they ever faced a decision where they were not sure which investment of time to make next.

But instead of micromanaging them ("Do this. No do that. No, do it this way. Are you done yet? How about now?"), I just made them understand that I was there to help them prioritize when they needed it. Because they didn't have the project-wide perspective I did, my value was in helping them to see, even if just for a moment, how what they were doing fit into the entire project. When they'd spent all day debugging a module or running unit tests, they were often relieved to get some higher-level clarity, reassurance, and confidence in what they were doing. It often took only a 30-second conversation to make sure we were all still on the same page.

Whenever new information came to the project, it was my job to interpret it (alone or through discussion with others), and form it into a prioritized list of things we had to care about and things we didn't. Often, I'd have to revise a previous list, adjusting it to respond to the new information. A VP might change her mind. A usability study might find new issues. A competitor might make an unexpected change. Those prioritizations were living, breathing things, and any changes to our direction or goals were reflected directly and immediately in them.

Because I maintained the priorities, I enabled the team to stay focused on the important things and actually make progress on them. Sometimes, I could reuse priorities defined by my superiors (vision documents, group mission statements); other times, I had to invent my own from scratch in response to ambiguity or unforeseen situations. But more than anything else, I was a prioritization machine. If there is ever a statue made in honor of good project managers, I suspect the inscription would say "Bring me your randomized, your righteously confused, your sarcastic and bitter masses of programmers yearning for clarity."

Things happen when you say no

One side effect of having priorities is how often you have to say no. It's one of the smallest words in the English language, yet many people have trouble saying it. The problem is that if you can't say no, you can't have priorities. The universe is a large place, but your priority 1 list should be very small. Therefore, most of what people in the world (or on your team) might think are great ideas will end up not matching the goals of the project. It doesn't mean their ideas are bad; it just means their ideas won't contribute to this particular project. So, a fundamental law of the PM universe is this: if you can't say no, you can't manage a project.(2)

Saying no starts at the top of an organization. The most senior people on a project will determine whether people can actually say no to requests. No matter what the priorities say, if the lead developer or manager continually says yes to things that don't jive with the priorities, others will follow. Programmers will work on pet features. PMs will add (hidden) requirements. Even if these individual choices are good, because the team is no longer following the same rules, nor working toward the same priorities, conflicts will occur. Sometimes, it will be disagreements between programmers, but more often, the result will be disjointed final designs. Stability, performance, and usability will all suffer. Without the focus of priorities, it's hard to get a team to coordinate on making the same thing. The best leaders and team managers know that they have to lead the way in saying no to things that are out of scope, setting the bar for the entire team.

When you do say no, and make it stick, the project gains momentum. Eliminating tasks from people's plates gives them more energy and motivation to focus and work hard on what they need to do. The number of meetings and random discussions will drop and efficiency will climb. Momentum will build around saying no: others will start doing it in their own spheres of influence. In fact, I've asked team members to do this. I'd say, "If you ever feel you're being asked to do something that doesn't jive with our priorities, say no. Or tell them that I said no, and they need to talk to me. And don't waste your time arguing with them if they complain—point them my way." I didn't want them wasting their time debating priorities with people because it was my expertise, not theirs. Even if they never faced these situations, I succeeded in expressing how serious the priorities were and how willing I was to work to defend them.

Master the many ways to say no

Sometimes, you will need to say no in direct response to a feature request. Other times, you'll need to interject yourself into a conversation or meeting, identify the conflict with priorities you've overheard, and effectively say no to whatever was being discussed. To prepare yourself for this, you need to know all of the different flavors that the word no comes in:

  • No, this doesn't fit our priorities. If it is early in the project, you should make the argument for why the current priorities are good, but hear people out on why other priorities might make more sense. They might have good ideas or need clarity on the goals. But do force the discussion to be relative to the project priorities, and not the abstract value of a feature or bug fix request. If it is late in the project, you can tell them they missed the boat. Even if the priorities suck, they're not going to change on the basis of one feature idea. The later you are, the more severe the strategy failure needs to be to justify goal adjustments.

  • No, only if we have time. If you keep your priorities lean, there will always be many very good ideas that didn't make the cut. Express this as a relative decision: the idea in question might be good, but not good enough relative to the other work and the project priorities. If the item is on the priority 2 list, convey that it's possible it will be done, but that no one should bet the farm assuming it will happen.

  • No, only if you make <insert impossible thing here> happen. Sometimes, you can redirect a request back onto the person who made it. If your VP asks you to add support for a new feature, tell him you can do it only if he cuts one of his other current priority 1 requests. This shifts the point of contention away from you, and toward a tangible, though probably unattainable, situation. This can also be done for political or approval issues: "If you can convince Sally that this is a good idea, I'll consider it." However, this can backfire. (What if he does convince Sally? Or worse, realizes you're sending him on a wild goose chase?)

  • No. Next release. Assuming you are working on a web site or software project that will have more updates, offer to reconsider the request for the next release. This should probably happen anyway for all priority 2 items. This is often called postponement or punting.

  • No. Never. Ever. Really. Some requests are so fundamentally out of line with the long-term goals that the hammer has to come down. Cut the cord now and save yourself the time of answering the same request again later. Sometimes it's worth the effort to explain why (so that they'll be more informed next time). Example: "No, Fred. The web site search engine will never support the Esperanto language. Never. Ever."

Keeping it real

Some teams have a better sense of reality than others. You can find many stories of project teams that shipped their product months or years late, or came in millions of dollars over budget (see Robert Glass' Software Runaways, Prentice Hall, 1997). Little by little, teams believe in tiny lies or misrepresentations of the truth about what's going on, and slide into dangerous and unproductive places. As a rule, the further a team gets from reality, the harder it is to make good things happen. Team leaders must play the role of keeping their team honest (in the sense that the team can lose touch with reality, not that they deliberately lie), reminding people when they are making up answers, ignoring problematic situations, or focusing on the wrong priorities.

I remember a meeting I was in years ago with a small product team. They were building something that they wanted my team to use, and the presentation focused on the new features and technologies their product would have. Sitting near the back of the room, I felt increasingly uncomfortable with the presentation. None of the tough issues was being addressed or even mentioned. Then I realized the real problem: by not addressing the important issues, they were wasting everyone's time.

I looked around the room and realized part of the problem: I was the only lead from my organization in attendance. Normally, I'd have expected another PM or lead programmer to ask tough questions already. But with the faces in the room, I didn't know if anyone else was comfortable making waves when necessary. A thousand questions came to mind, and I quickly raised my hand, unleashing a series of simple questions, one after another. "What is your schedule? When can you get working code to us? Who are your other customers, and how will you prioritize their requests against ours? Why is it in our interest to make ourselves dependent on you and your team?" Their jaws dropped. They were entirely unprepared.

It was clear they had not considered these questions before. Worse, they did not expect to have to answer them for potential clients. I politely explained that they were not ready for this meeting. I apologized if my expectations were not made clear when the meeting was arranged (I thought they were). I told them that without those answers, this meeting was a waste of everyone's time, including theirs. I suggested we postpone the rest of the meeting until they had answers for these simple questions. They sheepishly agreed, and the meeting ended.

In PM parlance, what I did in this story was call bullshit. This is in reference to the card game Bullshit, where you win if you get rid of all the cards in your hand. In each turn of the game, a player states which cards he's playing as he places them face down into a pile. He is not obligated to tell the truth. So, if at any time another player thinks the first player is lying, she can "call bullshit" and force the first player to show his cards. If the accuser is right, the first player takes all of the cards in the pile (a major setback). However, if the accuser is wrong, she takes the pile.

Calling bullshit makes things happen. If people expect you will ask them tough questions, and not hesitate to push them hard until you get answers, they will prepare for them before they meet with you. They will not waste your or your team's time. Remember that all kinds of deception, including self-deception, work against projects. The sooner the truth comes to light, the sooner you can do something about it. Because most people avoid conflict and prefer to pretend things are OK (even when there is evidence they are not), someone has to push to get the truth out. The more you can keep the truth out in the open, the more your team can stay low to the ground, moving at high speed.

The challenge with questioning others is that it can run against the culture of an individual or organization. Some cultures see questioning as an insult or a lack of trust. They may see attempts to keep things honest as personal attacks, instead of as genuine inquiries into the truth. You may need to approach these situations more formally than I did in the story. Make a list of questions you expect people to answer, and provide it to them before meetings. Or, create a list of questions that anyone in the organization is free to ask anyone at any time (including VPs and PMs), and post it on the wall in a conference room. If you make it public knowledge from day one that bullshit will be called at any time, you can make it part of the culture without insulting anyone. However, leaders still have the burden of actually calling bullshit from time to time, demonstrating for the team that cutting quickly to the truth can be done.

Know the critical path

In project management terminology, the critical path is the shortest sequence of work that can complete the project. In critical path analysis, a diagram or flowchart is made of all work items, showing which items are dependent on which others. If done properly, this diagram shows where the bottlenecks will be. For example, if features A, B, and C can't be completed until D is done, then D is on the critical path for that part of the project. This is important because if D is delayed or done poorly, it will seriously impact the completion of work items A, B, and C. It's important then for a project manager to be able to plan and prioritize the critical path. Sometimes, a relatively unimportant component on its own can be the critical dependency that prevents true priority 1 work from being completed. Without doing critical path analysis, you might never recognize this until it is too late.(3)

From a higher-level perspective, there is a critical path to all situations. They don't need to be diagrammed or measured to the same level of detail, but the thought processes in assessing many PM situations are similar: look at the problem as a series of links, and see where the bottlenecks or critical points are. Which decisions or actions are dependent on which other decisions or actions? Then consider if enough attention is being paid to them, or if the real issue isn't the one currently being discussed. You dramatically accelerate a team by putting its attention directly on the elements, factors, and decisions that are central to progress.

Always have a sense for the critical path of:

  • The project's engineering work (as described briefly earlier)

  • The project's high-level decision-making process (who is slowing the team down?)

  • The team's processes for building code or triaging bugs (are there needless forms, meetings, or approvals?)

  • The production process of propping content to the Web or intranet

  • Any meeting, situation, or process that impacts project goals

Making things happen effectively requires a strong sense of critical paths. Anytime you walk into a room, read an email, or get involved in a decision, you must think through what the critical paths are. Is this really the core issue? Will this discussion or line of thinking resolve it? Focus your energy (or the room's energy) on addressing those considerations first and evaluating what needs to be done to ensure those critical paths are made shorter, or resourced sufficiently, to prevent delays. If you can nail the critical path, less-critical issues will more easily fall into place.

For some organizations, the fastest way to improve the (non-engineering) critical path is to distribute authority across the team. Instead of requiring consensus, let individuals make decisions and use their own judgment as to when consensus is needed. Do the same thing for approvals, documentation, forms, or other possible bureaucratic overhead (see Chapter 10). Often the best way of improving critical paths in organizations is to remove processes and shift authority down and across a team, instead of creating new processes or hierarchies.

Be relentless

"The world responds to action, and not much else."

—Scott Adams

Many smart people can recognize when there is a problem, but few are willing to expend the energy necessary to find a solution, and then summon the courage to do it. There are always easier ways: give up, accept a partial solution, procrastinate until it goes away (fingers crossed), or blame others. The harder way is to take the problem head-on and resist giving in to conclusions that don't allow for satisfaction of the goals. Successful project managers simply do not give up easily. If something is important to the project, they will act aggressively—using any means necessary—to find an answer or solve the problem. This might mean reorganizing a dysfunctional team, getting a difficult room of people to agree on goals, finding answers to questions, or settling disagreements between people.

Sometimes, this means asking people to do things they don't like doing, or raising questions they don't want to answer. Without someone forcing those things to happen, the easier way out will tend to be chosen for you. Many projects consist of people with specialized roles who are unlikely to take responsibility for things that are beyond their limited scope (or that fall between the cracks of their role and someone else's). Perhaps more problematic is that most of us avoid conflict. It's often the PM who has to question people, challenge assumptions, and seek the truth, regardless of how uncomfortable it might make others (although the goal is to do this in a way that makes them as comfortable as possible). PMs have to be willing to do these things when necessary.

Many times situations that initially seem untenable or intractable crumble underneath the psychological effort of a tenacious project manager. A classic story about this attitude is the Apollo 13 mission. In his book Failure Is Not an Option (Berkeley Publishing, 2001), Gene Kranz describes the effort that went into fixing the life-support system on the damaged spacecraft. It was one of the hardest engineering challenges the team faced, and there were grave doubts among those with the most expertise that even a partial solution was possible. Kranz took the position that not only would they find a way, they would do so in the limited time allotted. He refused to accept any easy way out, and he pushed his team to explore alternatives, resolving their disputes and focusing their energy. All three versions of the story, the film Apollo 13, Kranz's book, and Lost Moon (Pocket, 1995) by Jim Lovell (the mission captain) and Jeffrey Kluger, provide fascinating accounts of one of the greatest project management and problem-solving stories in history.

Effective PMs simply consider more alternatives before giving up than other people do. They question the assumptions that were left unchallenged by others, because they came from either a VP people were afraid of or a source of superior expertise that no one felt the need to challenge. The question "How do you know what you know?" is the simplest way to clarify what is assumed and what is real, yet many people are afraid, or forget, to ask it. Being relentless means believing that 99% of the time there is a solution to the problem (including, in some cases, changing the definition of the problem), and that if it can't be found with the information at hand, then deeper and more probing questions need to be asked, no matter who has to be challenged. The success of the project has to come first.

In my years in the Windows division at Microsoft, I worked for Hillel Cooperman, perhaps the most passionate and dedicated manager I've ever had. I remember once coming into his office with a dilemma. My team was stuck on a complicated problem involving both engineering and political issues. We needed another organization to do important work for us, which they were unwilling to do. I had brainstormed with everyone involved, I had solicited opinions from other senior people, but I was still stuck. There didn't seem to be a reasonable solution, yet this was something critical to the project, and I knew giving in would be unacceptable. After explaining my situation, the conversation went something like this: "What haven't you tried yet?" I made the mistake of answering, "I've tried everything." He just laughed at me. "Everything? How could you possibly have tried everything? If you've tried everything, you'd have found a choice you feel comfortable with, which apparently you haven't yet." We found this funny because we both knew exactly where the conversation was going.

He then asked if I wanted some suggestions. Of course I said yes. We riffed for a few minutes, back and forth, and came up with a new list of things to consider. "Who haven't you called on the phone? Email isn't good for this kind of thing. And of all the people on the other side—those who disagree with you—who is most receptive to you? How hard have you sold them on what you want? Should I get involved and work from above you? Would that help? What about our VP? How hard have you pushed engineering to find a workaround? A little? A lot? As hard as possible? Did you offer to buy them drinks? Dinner? Did you talk to them one-on-one, or in a group? Keep going, keep going, keep going. You will find a way. I trust you, and I know you will solve this. Keep going."

He did two things for me: he reminded me that not only did I have alternatives, but also that it was still my authority to make the decision. As tired as I was, I left his office convinced there were more paths to explore and that it was my job to do so. My ownership of the issue, which he'd reconfirmed, helped motivate me to be relentless. The solution was lurking inside one of them, and I just had to find it. Like the dozens of other issues I was managing at the same time, I eventually found a solution (there was an engineering workaround), but only because I hunted for it: it was not going to come and find me.

Among other lessons, I learned from Hillel that diligence wins battles. If you make it clear that you are dead serious and will fight to the end about a particular issue, you force more possibilities to arise. People will question their assumptions if you hold on to yours long enough. You push people to consider things they haven't considered, and often that's where the answer lies. Even in disagreements or negotiations, if you know you're right, and keep pushing hard, people will often give in. Sometimes, they'll give in just to get you to leave them alone. Being pushy, provided you're not offensive, can be an effective technique all on its own.

Being relentless is fundamental to making things happen. There are so many different ways for projects to slide into failure that unless there is at least one emotional force behind the project—pushing it forward, seeking out alternatives, believing there is always a way out of every problem and trap—the project is unlikely to succeed. Good PMs are that force. They are compelled to keep moving forward, always on the lookout for something that can be improved in a faster or smarter way. They seek out chaos and convert it into clarity. As skeptical as project managers need to be, they are simultaneously optimistic that all problems can be solved if enough intensity and focus are applied. For reasons they themselves cannot fully explain, PMs continually hold a torch up against ambiguity and doubt, and refuse to quit until every possible alternative has been explored. They believe that good thinking wins, and that it takes work to find good thoughts.

Be savvy

But being relentless doesn't mean you have to knock on every door, chase people down the hallway, or stay at work until you pass out at your desk. Sheer quantity of effort can be noble and good, but always look for ways to work smart rather than just hard. Be relentless in spirit, but clever and savvy in action. Just because you refuse to give up doesn't mean you have to suffer through mindless, stupid, or frustrating activities (although sometimes they're unavoidable). Look for smart ways around a problem or faster ways to resolve them. Make effective use of the people around you instead of assuming you have to do everything yourself. But most importantly, be perceptive of what's going on around you, with individuals and with teams.

A fundamental mistake many PMs make is to forget to assess who they are working with and adjust their approach accordingly. Navy Seals and Army rangers are trained to carry out missions on many different kinds of terrain: deserts, swamps, jungles, tundra. Without this training, their effectiveness would be limited: they'd struggle to survive on unfamiliar terrain because their skills wouldn't work (imagine a solider in green and olive camouflage, trying to hide on a snow-covered field). The first lesson they learn is how to evaluate their environment and consider what tactics and strategies from their skill set will work for where they are. The same is true for PMs. Instead of geographic environments, PMs must pay attention to the different social, political, and organizational environments they are in, and use the right approaches for where they are.

Being savvy and environment-aware is most important in the following situations:

  • Motivating and inspiring people

  • Organizing teams and planning for action

  • Settling arguments or breaking deadlocks

  • Negotiating with other organizations or cultures

  • Making arguments for resources

  • Persuading anyone of anything

  • Managing reports (personnel)

Here's the savvy PM's rough guide to evaluating an environment. These questions apply to an individual you might be working with or to the larger team or group:

  • What communication styles are being used? Direct or indirect? Are people openly communicative, or are they reserved? Are there commonly accepted ways to make certain kinds of points? Are people generally effective in using email? Meetings? Are decisions made openly or behind closed doors? Match your approaches to the ones that will be effective with whomever you're talking to.

  • How broad or narrow is the group's sense of humor? What topics are forbidden to laugh at or question? How are delicate/difficult/contentious subjects or decisions handled by others?

  • Are arguments won based on data? Logical argument through debate? Adherence to the project goals? Who yells the loudest? Who has the brownest nose? Consider making arguments that use the style, format, or tone most palatable to your audience, whether it's a lone tester down the hall or a room full of executives.

  • Who is effective at doing <insert thing you are trying to do here>, and what can I emulate or learn from them? Pay attention to what works. Who are the stars? Who gets the most respect? How are they thriving? Who is failing here? Why are they failing?

  • In terms of actual behavior, what values are most important to this person or group? Intelligence? Courage? Speed? Clarity? Patience? Obedience? What behaviors are least valued or are deplored? Programmers and managers might have very different values. Know what the other guy values before you try to convince him of something.

  • What is the organizational culture? Every university, corporation, or team has a different set of values built into the culture. If you don't think your organization has one, you've been there too long and can't see it anymore (or maybe you never saw it at all). Some organizations value loyalty and respect above intelligence and individuality. Others focus on work ethic and commitment.

Depending on the answers to these questions, a PM should make adjustments to how she does her work. Every time you enter another person's office, or another meeting, there should always be some adjustments made. Like a Marine, assess the environment and then judge the best route to get to the project goals. Avoid taking the hard road if there is a smarter way to get where you need to go.

Guerilla tactics

Being savvy means you are looking for, and willing to take, the smarter route. The following list contains tactics that I've used successfully or have been successfully used on me. While your mileage may vary with them, I'm sure this list will get you thinking of other savvy ways to accomplish what needs to be done to meet your goals. Some of these have risks, which I'll note, and must be applied carefully. Even if you choose never to use these yourself, by being aware of them, you will be savvier about what's going on around you.

  • Go to the source. Don't dillydally with people's secondhand interpretations of what someone said, and don't depend on written reports or emails for complex information. Find the actual person and talk to him directly. You can't get new questions answered by reading reports or emails, and often people will tell you important things that were inappropriate for written communication. Going to the source is always more reliable and valuable than the alternatives, and it's worth the effort required. For example, if two programmers are arguing about what a third programmer said, get that third programmer in the room or on the phone. Always cut to the chase and push others to do the same.

  • Switch communication modes. If communication isn't working, switch the mode. Instead of email, call them on the phone. Instead of a phone call, drop by their office. Everyone is more comfortable in some mediums than others. (Generally, face to face, in front of a whiteboard, trumps everything. Get people in a room with a whiteboard if the email thread on some issue gets out of control.) Don't let the limitations of a particular technology stop you. Sometimes, switching modes gets you a different response, even if your request is the same, because people are more receptive to one mode over another. For anything consequential, it's worth the money and time to get on a plane, or drive to their office, if it improves the communication dynamic between you and an important co-worker.

  • Get people alone. When you talk to someone privately, her disposition toward you is different than when you talk to her in a large group. In a meeting, important people have to craft what they say to be appropriate for all of the ears in the room. Sometimes, you'll hear radically different things depending on who is in earshot. If you want a frank and honest opinion, or an in-depth intense conversation, you need to get people alone. Also, consider people of influence: if Jim trusts Beth's opinion, and you want to convince Jim, if you can convince Beth first, bring her along. Don't ambush anyone, but don't shy away from lining things up to make progress happen.

  • Hunt people down. If something is urgent and you are not getting the response time you need, carve out time on your schedule to stake out the person's office or cubicle. I've done this many times. If he wasn't answering my phone calls or emails, he'd soon come back from a meeting and find me sitting by his door. He'd usually be caught so off guard that I'd have a negotiating advantage. Don't be afraid to go after people if you need something from them. Find them in the coffee room. Look for them in the café at lunchtime. Ask their secretary what meetings they are in and wait outside. Be polite, but hunt and get what you need. (However, please do not cross over into their personal lives. If you hunt information well, you shouldn't ever even need to cross this particular line.)

  • Hide. If you are behind on work and need blocks of time to get caught up, become invisible. On occasion, I've staked out a conference room (in a neighboring building) and told only the people who really might need me where I was. I caught up on email, specs, employee evaluations, or anything important that wasn't getting done, without being interrupted. For smaller orgs, working from home or a coffee shop can have the same effect (wireless makes this easy these days). I always encouraged my reports to do this whenever they felt it necessary. Uninterrupted time can be hard for PMs to find, so if you can't find it, you have to make it.

  • Get advice. Don't fly solo without a map unless you have to. In a given situation, consider who involved thinks most highly of you, or who may have useful advice for how you can get what you need. Make use of any expertise or experience you have access to through others. Pull them aside and ask them for it. This can be about a person, a decision, a plan, anything. "Hey Bob, I'd like your advice on this budget. Do you have a few minutes?" Or, "Jane, I'm trying to work with Sam on this issue. Any advice on the best way to convince him to cut this feature?" For many people, simply asking their advice will score you credibility points: it's an act of respect to ask for someone's opinion.

  • Call in favors, beg, and bribe. Make use of the credibility or generosity you've developed a reputation for. If you need an engineer to do extra work for you, either because you missed something or a late requirement came in, ask her to do you a favor. Go outside the boundaries of the strict working relationship, and ask. Offer to buy her dinner ($20 is often well worth whatever the favor is), or tell her that you owe her one (and do hold yourself to this). The worst thing that can happen is that she'll say no. The more favors you've done for others, the more chips you'll have to bank on. Also, consider working three-way trades (e.g., in the game Settlers of Cattan) if you know of something she wants that you can get from someone else. It's not unethical to offer people things that will convince them to help with work that needs to be done.

  • Play people off each other. This doesn't have to be evil—if you're very careful. If Sam gives you a work estimate of 10 days, which you think is bogus, go and ask Bob. If Bob says something less than 10 days, go back to Sam, with Bob. A conversation will immediately ensue about what the work estimate really should be. If you do this once, no engineer will ever give you bogus estimates again (you've called bullshit). However, depending on Sam's personality, this may cost you relationship points with him, so do it as tactfully as possible, and only when necessary. Good lead programmers should be calling estimate bluffs on their own, but if they don't, it's up to you.

  • Buy people coffee and tasty things. This sounds stupid, but I've found that people I've argued with for days on end are somehow more receptive over a nice cup of coffee at a local coffee shop. Change the dynamic of the relationship: no matter how much you like or don't like the person, make the invitation and invest the 20 seconds of effort it requires. Even if he says "No, why can't we talk here?", you've lost nothing. Moving the conversation to a different location, perhaps one less formal, can help him open up to alternatives he wouldn't consider before. Think biologically: humans are in better moods after they've eaten a fine meal or when they are in more pleasant surroundings. I've seen PMs who keep doughnuts or cookies (as well as rum and scotch) in their office. Is that an act of goodwill? Yes...but there are psychological benefits to making sure the people you are working with are well fed and associate you with good things.

Summary

  • Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.

  • The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal.

  • There is a bright yellow line between priority 1 work and everything else.

  • Things happen when you say no. If you can't say no, you effectively have no priorities.

  • The PM has to keep the team honest and keep them close to reality.

  • Knowing the critical path in engineering and team processes enables efficiency.

  • You must be both relentless and savvy to make things happen.
This discussion has been archived. No new comments can be posted.

Book Excerpt: The Art of Project Management More

Book Excerpt: The Art of Project Management

Comments Filter:
  • I give this book an 8/10, meaning you can't live without a copy!
    • | I give this book an 8/10, meaning you can't live without a copy!

      Apparently, a 10/10 would mean "If you don't already have this book, you have died."
  • "outshines it's class"

    I stopped reading right there.

    This really isn't meant as a flame, but IMO that's not the sort of thing that just typos its way into something like a book review. I'm really not trying to be a grammar nazi, but does this bother anyone else? I mean, it's a BOOK REVIEW.

  • Spoilers: (Score:5, Funny)

    by Anonymous Coward on Tuesday November 15, 2005 @03:18PM (#14036962)
    Spoilers:

    The main character gets married at the end. The project is completed under budget and before the deadline. The employers and employees go home satisfied with a job well done.
    • Ohhhhh...so it's complete fiction, is it? Fantasy is probably the correct genre. Even assuming that the employees are programmers, it couldn't be considered Science Fiction since it has to be at plausible.

  • Helping out (Score:5, Funny)

    by spuke4000 ( 587845 ) on Tuesday November 15, 2005 @03:18PM (#14036963)
    Since Slashdot seems to now be posting long articles in the summary section I thought I'd help out by summarizing. I fired up MS-Word and used autosummarize to chop this sucker down a bit. Here's the result:
    Priorities are power

    No, only if we have time. (What if he does convince Sally? The project's engineering work (as described briefly earlier)

    Adherence to the project goals? If communication isn't working, switch the mode. Get people alone. Hunt people down. The three most basic ordered lists are: project goals (vision), list of features, and list of work items. If you can't say no, you effectively have no priorities.
    I hope that clears things up.

    • Re:Helping out (Score:1, Funny)

      by Anonymous Coward
      Since Slashdot seems to now be posting long articles in the summary section I thought I'd help out by summarizing. I fired up MS-Word and used autosummarize to chop this sucker down a bit.

      Your summary post was too long for me to read, so I ran it through MS Word's auto-summarize at 15% and then used Babelfish to translate it into German. Here's what came out:

      Haftfähigkeit zu den Projektzielen? Wenn Kommunikation nicht arbeitet, schalten Sie den Modus. Jagen Sie Leute unten..

      Hope this helps

      • Re:Helping out (Score:3, Funny)

        by Anonymous Coward
        Funny how the German ends with "Hunt people down." Seems so...German.
    • At least I actually read what you said. After about one sentance of the original I just started scrolling and couldn't stop.

      I've never blocked any section on Slashdot before but I am eager to find a way to block any future display of this new "Book Excerpt" section. Perhaps the symbol could be a skeleton about halfway through "War and Peace".

    • Re:Helping out (Score:3, Funny)

      by yagu ( 721525 ) *

      From your post: Here's the result: (from the Microsoft summary...)

      and, here was the "result":

      Priorities are power

      No, only if we have time. (What if he does convince Sally? The project's engineering work (as described briefly earlier)

      Adherence to the project goals? If communication isn't working, switch the mode. Get people alone. Hunt people down. The three most basic ordered lists are: project goals (vision), list of features, and list of work items. If you can't say no, you effectively have no p

  • Chapter 14: How to not make anything happen (Score:5, Funny)

    by rookworm ( 822550 ) <horace7945@@@yahoo...ca> on Tuesday November 15, 2005 @03:20PM (#14036989)
    Lie on a bench and feel yourself!

  • Am I Seeing Things... (Score:3, Funny)

    by __aaclcg7560 ( 824291 ) on Tuesday November 15, 2005 @03:22PM (#14037003)
    Is there a reason for why there's a picture of some person laying with hands near the crotch area? (It doesn't appear to be a weird /. advertisement.) I guess project management is more "hands on" from the last time that I was in a project management role.

  • Not so easy in practice (Score:1, Interesting)

    by Anonymous Coward
    This is a nice ideal view on how to make things happen. I live in an environment of a group with 12 people, and 70 projects. Problem of each project manager is not only to make things happen within their project, but also to convince the rest of the organisation that their project needs its fair share of the company's resources.... If that part isn't managed properly, the project priorities may be in order, but no manpower is available to work on them....
    • If that part isn't managed properly, the project priorities may be in order, but no manpower is available to work on them.

      The bean counters at one company I worked for insisted that the QA group justify each and every single hour on a per project basis and came up with an elaborate spreadsheet that nobody knew how to use. Upper management threaten to assign only minimal resources if the spreadsheet wasn't used every day. They got upset when I successfully completed my projects with minimal resources with

  • What I learned: Keep Rum and Scotch in your Office (Score:5, Funny)

    by digitaldc ( 879047 ) on Tuesday November 15, 2005 @03:26PM (#14037026)
    They are wonderful social lubricants and can inspire, elate and motivate like no human speech, determination or saaviness can. :)

  • Save some money and buy it here! (Score:1, Informative)

    by Anonymous Coward
    Save yourself some money by buying the book here: The Art of Project Management [amazon.com]. And if you use the "secret" A9.com discount [amazon.com], you can save an extra 1.57%!

  • The PMI has the authoritative book (Score:5, Informative)

    by winkydink ( 650484 ) * <sv.dude@gmail.com> on Tuesday November 15, 2005 @03:30PM (#14037053) Homepage Journal
    PMI = Project Management Institute

    The Project Management Body of Knowledge is where you should start if you are serious about PM. You can buy it online from Amazon, et al.

    • Re:The PMI has the authoritative book (Score:5, Insightful)

      by zulux ( 112259 ) on Tuesday November 15, 2005 @03:49PM (#14037215) Homepage Journal
      The Project Management Body of Knowledge is where you should start if you are serious about PM. You can buy it online from Amazon, et al.

      That's good idea - there's a lot to learn from the PMBOK.

      The PMBOK is geared to the construction field, so there's a lot of stuff there that us IT people don't need.

      For example:
      In construction you are usually *very* cost oriented while in IT you hardly ever do cost management.

      Another: A a big problem in IT is that you can fake progress and not be any further to the goal - in construction, laying down 50 feet of curb is hard to fake.

      • In construction you are usually *very* cost oriented while in IT you hardly ever do cost management

        Hahahah oh that's good. Tell me another one.

        True, in some areas of IT, you can get away with murder on costs. But only on internal projects.

      • The PMBOK is geared to the construction field, so there's a lot of stuff there that us IT people don't need.

        Excellent point. People who draw construction analogies seem to miss that in software development we spend most of our time on what people who make buildings think of as design. The proper software development analogy for construction isn't coding; it's what happens after we type "make".
      • In construction you are usually *very* cost oriented while in IT you hardly ever do cost management.

        Huh? Ever done a multi-million dollar enterprise software implementation? Some IT departments have dedicated finance people.
        • Huh? Ever done a multi-million dollar enterprise software implementation? Some IT departments have dedicated finance people.

          Yes - but it's nothing compared to construction. I've seen schedule's of values in construction that will make you head swim - with line items from gravel import for a one lot to office supplies for the month of May. Construction typically has a 4% margin - so that's why they go nuts.
          • Oh, I know. I've built out 150k sf in Manhattan. Most of them also use Primavera for that reason (ok, and a few others). It makes makes MS Project look like using spreadsheets for PM by comparison. It's also harder than all get-out to learn to use well.
    • While agree that the PMBOK is an excellent starting point (I teach PM using it), its only a book of guiding principles... its not an actual PM process or methodology. While I don't think the book that was featured in the original article is necessarily a true methodology either - its one step closer to the actual "what-to-do" steps vs. a high-level set of guiding principles, inputs and outputs to processes.
    • Personally I prefer PRINCE II to the PMBOK. It is more IT orientated and actually is clear methodology of how to manage a project.

      The real shame is that it is quite often misused, misquoted or blatantly disregarded by people who claim that they are following it strictly but in actual fact are just churning out paper.

  • All Joking Aside... (Score:5, Interesting)

    by NovaScorpio ( 127710 ) on Tuesday November 15, 2005 @03:31PM (#14037064)
    All joking aside, Scott Berkun visited CMU a little while ago on his book tour and made a really great presentation. I've read the first few chapters of this book and it seems to be a great accumulation of his knowledge, which I would say is significantly more than the average PM considering where he has worked, and what he has worked on.

  • What site am I reading? (Score:5, Funny)

    by Sj0 ( 472011 ) on Tuesday November 15, 2005 @03:32PM (#14037068) Journal
    When did this cease to be "News for Nerds: Stuff that matters" and when did it become "News for MBAs: Shit that nobody cares about"?

    • Re:What site am I reading? (Score:5, Insightful)

      by RedX ( 71326 ) <redx AT wideopenwest DOT com> on Tuesday November 15, 2005 @03:55PM (#14037275)
      When did this cease to be "News for Nerds: Stuff that matters" and when did it become "News for MBAs: Shit that nobody cares about"?

      Exactly, because who in IT actually works on or manages projects anyways? Believe it or not, there are "nerds" who do things in IT besides write code.

      • Ahem...I happen to be one of those nerds who does things in IT besides writing code. I'm also a newly-minted PMP. Also, by coincidence, I've been reading Berkun's book this morning. I'd say that it is probably one of the best IT-related PM books that I've read (and I've read quite a few).

        P.S. I also have my MBA so either of the GP's sites would appeal to me.
        • Ahem...I happen to be one of those nerds who does things in IT besides writing code. I'm also a newly-minted PMP. Also, by coincidence, I've been reading Berkun's book this morning. I'd say that it is probably one of the best IT-related PM books that I've read (and I've read quite a few).

          I think we need to have a discussion on the true meaning of "nerd". If you ask me, once you get into management, you no longer qualify.

        • When you become a PMP, do you get a lime green suit, matching hat, and a cane, or do you have to buy all that stuff?
      • Yup, if you work the same stuff, day in, day out, then these are not the droids you are searching for. If, on the other hand, the thing you're working on has defined outputs/goals, and has a defined beginning and end, then hey, it's a project. And MBAs try not to touch those things with a bargepole.

    • Re:What site am I reading? (Score:5, Insightful)

      by stienman ( 51024 ) <adavis@@@ubasics...com> on Tuesday November 15, 2005 @03:55PM (#14037280) Homepage Journal
      When did this cease to be "News for Nerds: Stuff that matters" and when did it become "News for MBAs: ..."

      Did you not get the memo?

      Ah.

      Let me summarize:

      The US is outsourcing everything that can be done more cheaply elsewhere. At this point everyone that is a leaf node in their organization (ie, you don't manage anyone) is at risk of being outsourced.

      If you are not working on your project management and leadership skills, you might not have a job in a decade or two.

      -Adam
    • I recommend that all developers and technical-types cultivate a solid understanding of the principles and practices of Project Management.

      Why? Because if you demonstrate that you CAN'T manage your own projects, then the Company WILL assign some clueless business school graduate to micromanage you, and your job will suck. Don't let it happen to you.
    • I would think that the more intellectual "nerds", who do not focus only on stereotypical nerd stuff would be interested in anything that has an intellectual component to it. Britney Spears is exempt, but "News for MBAs" is not. Betterment of ones' self can take many paths.

      Anyways, that was pretty funny but I think it bears pointing out that not all nerds are the same.
    • You're right, project management is for suits. Nobody here wants to talk about that crap. Let's have another Slashdot thread about Reiser4 and the Linux kernel, which SCM solution Linus wants to try next, the latest OSS project to fork its code base, or some juicy public acrimony between Free Software figureheads. God knows its better than talking about project management.

      Martin
  • TFA is, well, not a FA. The 'book review' is, well, not a book review. And the summary... well, you get the point, right?

    I've got another summary (interpretation) of the excerpt:

    Must prioritize. Must act according to priorities. Slashdot is not a priority. STFU & GBTW.
    --Hemos

    Funny, I never knew my boss's Slashdot alter ego was Hemos.

  • Good for those with not much experience (Score:5, Informative)

    by Sigh Phi ( 324315 ) on Tuesday November 15, 2005 @03:38PM (#14037114)

    I'm not far into this book (Chapter 4), but so far I find it very illuminating. I don't have a lot of project management experience; I'm used to working alone or an small teams, and I don't have an engineering background (lit grad turned programmer). I've got a lot of goals and big ideas for several projects, and this is really giving me a handle on how to approach them, what kind of information to present to people, how to ask good questions, prepare documents.

    Just got through the "vision" chapter, so now I'm going over all my active and pending projects and trying to hammer out good vision statements. Next up: "Where Ideas Come From." Berkun's writing is lucid and engaging; a very easy read.

  • What it takes (Score:2, Insightful)

    by lonb ( 716586 ) *
    If you want to know what it takes to succeed read "Think and Grow Rich [amazon.com]" by Napoleon Hill. The bottomline is that it takes drive, persistence, and organization. All of these traits can be acquired by the willing.
  • Yeah, that's the title of my next book. You be sure to get a copy.

  • Hm. (Score:5, Funny)

    by nathan s ( 719490 ) on Tuesday November 15, 2005 @03:44PM (#14037166) Homepage
    "While my own review of it is tardy and still forthcoming..."

    Seems like the reviewer failed to RTFA, considering that it's Chapter 13: How to make things happen! :-D

  • An Excellent Book (Score:3, Interesting)

    by umeshunni ( 37684 ) <`umeshunni' `at' `hotmail.com'> on Tuesday November 15, 2005 @03:48PM (#14037201) Homepage Journal
    I just picked this book up from my local library a couple of days back and found it absolutely essential for my job as a Project/Program Manager. It covers the basics which I should arguably have known before I started this job and has tons of tips and tricks which I feel would make my day-to-day productivity higher.
    Sigh: I wish it has a chapter on how to stay away from slashdot :-)
    • Say no. When you are about to type slashdot, stop yourself.

      Remap your keyboard to replace the letter 'c' with the letter 'b'.
      Oh, no, that wont work. Try replacing 's' with 'b'. Then you
      will get blabhdot.com. Doesnt exist, so you cant accidently
      link to it from there.

      Replace your PC with an old S/36 minicomputer. ( you can sell
      any heaters you have, you wont need them anymore ).

      If your hand offends thee, cut it off. No browsing that way.

      Not quite a chapter, but I will work on it.
  • Lots of related concepts around agility, management, teamwork, prioritization, queues, lean, adult learning, coaching, testing etc. all can be found on the blog Agile Advice - How and Why to Work Agile - The Middle Way to Excellence [agileadvice.com]. If you like this chapter, I think you will enjoy a good portion of the entries on that site. I run the blog and I am the primary contributor, but there are a few other regular contributors as well and I have recently opened up a Guest account for anyone to contribute articles
  • Here it is on Amazon.com [amazon.com] for $39.95
    And here on Bookpool [bookpool.com] for $32.95

  • Rule 1: beware scope creep (Score:5, Insightful)

    by Pope ( 17780 ) on Tuesday November 15, 2005 @03:59PM (#14037322)
    If there's anything I've learned at my current company, going from contractor to full-time, it's the dread of Scope Creep.

    No, that's not the MBA jackass who's trying to outsource everything so his stock can go up, it's making sure that what's in the project is clearly defined and all changes to it are also defined, accepeted, and properly sized for the extra effort.

    This usually happens when someone else's pet project doesn't have funding and gets glommed onto another approved one.
    • This is related to the scope creep rule.

      The longer your project is in the pipeline, the more likely it is that it will fail. Over time, the problem that your project is supposed to solve will mutate or become irrelevant itself and/or other "problems" will suddenly "need" to be "solved" by your project.
  • TAOPM is on the Personal MBA book list.
    http://www.personalmba.com/ [personalmba.com]
    http://www.amazon.com/exec/obidos/tg/guides/guide- display/-/2T49HSJQJBYI1/ [amazon.com]
    The author meets with people there to discuss concepts in the book. I highly recommend the Personal MBA to anyone looking to further their business management knowledge. I'm working on mine right now.
  • I thought the article/excerpt/review was pretty good and very timely. I especially liked the several ways to sa "No" section. Very good read.
  • As the head of sales of one of the largest PM training companies in the world, I was interested in this book. Upon reading this chapter however, all I can say is ... what crap! The author has no concept of what project management really is, or how it works. Unfortuantaly, he appears to be yet another person assigned to the job of project manager that did not bother to see if he could actually learn anything about the discipline of project management while in his job, and taught himself everything he knows,

    • Re:The author knows not of what he speaks (Score:3, Insightful)

      by Anonymous Coward
      Hope you elaborate and justify your objection against the book content in a more specific manner. The background of yours that you disclosed, and the manner in which you post your objections, do not lend you much credibility, particularly, I suspect, here on this website.
    • Mod Parent up, not only because I dislike the very notion of slashvertisements, but because the parent is right.

    • Calling BULLSHIT (Score:2, Insightful)

      by Anonymous Coward
      I see. He has no credibility because he didn't take your class.

      Sorry, but when faced with trusting an ex-Microsoft PM over the "head of sales of one of the largest PM training companies" I'm going to have to side with the PM. At least he's actually done what he discusses and in my experiences tech salesmen are nuclear-powered bullshit factories.
    • You know, there is life outside of the PMBOK.

      I'll grant that what he calls "Critical Path Analysis" is just another way of Activity Sequencing, or restating his whole point for the chapter- focus on what's important... which is just a restatement of Covey, which is a derivative of Carnegie... etc. That doesn't mean it's a bad read. The focus on the soft skills of a manager is important (and germane considering the /. audience).

      There are lots of people who think it's perfectly fine to conduct life via emai
    • As the head of sales of one of the largest PM training companies in the world, I was interested in this book. Upon reading this chapter however, all I can say is ... what crap! The author has no concept of what project management really is, or how it works.

      Describe some of the large software projects you have managed, and then maybe we'll take your word on it.

      Sometimes experience trumps expertise. Sometimes practice outshines theory. Scott's book is written for practitioners. I'll wager that you are not the
    • As the head of sales of one of the largest PM training companies in the world, I was interested in this book. Upon reading this chapter however, all I can say is ... what crap!

      So let me get this straight.

      Your job isn't to get things done, or to run projects yourself. Instead, your job is to convince people that they can't get their shit together on their own, and so they need lots and lots of help from your company. Which, apparently doesn't actually do anything either, instead making a living telling peopl

    • Re:The author knows not of what he speaks (Score:5, Insightful)

      by MagikSlinger ( 259969 ) on Tuesday November 15, 2005 @08:26PM (#14039867) Homepage Journal

      I would normally stay away from flamebait like this, but I'm sorry, I can't...

      As the head of sales of one of the largest PM training companies in the world,

      Mod -1 right there

      I was interested in this book. Upon reading this chapter however, all I can say is ... what crap! The author has no concept of what project management really is, or how it works. Unfortuantaly, he appears to be yet another person assigned to the job of project manager that did not bother to see if he could actually learn anything about the discipline of project management while in his job, and taught himself everything he knows, and now considers himself an expert.

      Anecdotal experience: The best project managers I ever worked with never learned anything from PMI. The worst ones I worked with had PMI certifications. Seriously. As you can tell, I'm a tad jaded about PMI.

      He learned a few PM buzzwords and he does not even use them correctly. Critical path has 2 definitions, neither of which jive with his. His idea of managing a critical path has more in common with a rugby scrum than a well thought out process. Had the author been smart, he would have ventured outside his own little world of software development and gotten real training in project management from a vendor that is in line with the Project Management Institutes "Project Management Body of Knowledge".

      To me, Critical path is a PERT thing. Nothing more, nothing less. It's now become something that's been grafted into all project management methodologies, and most of those methodologies have no way of properly tracking it and adjusting it. I know the definition: the longest duration path through a task dependency chart. The corollary: the critical path is the shortest time the project can be completed. Somehow the two get confused and become "2 definitions", but it isn't: it's just the one.

      And in practice, you critical path is not what shows up on your chart. It's the path with that unexpected bogey man: the vendor who ships your server 3 months late; the "simple middleware layer" that becomes a nightmare due to mismanagement; the composite liquid hydrogen tank that scuttles your multi-billion dollar project [wikipedia.org]. I've seen PMIs dash their projects against the rock because they swear the PMI PMBOK tells them their critical path is still ABCD and refuse to face the fact their critical path has chanegd. PMI and PMBOK give software managers a false sense of control & understanding. That's why us geeks are willing to listen to this guy.

      With over 1000 books available on project management, this one should fall into the "dont waste your money" category. Anyone that wants an easy to read primer on what project management REALLY is would be much better served by reading a book such as "The Fast Forward MBA in Project Management" by Eric Verzuh and published by Wiley.

      I've skimmed most of those books. I gave up reading them. The PMBOK from PMI is mostly a joke. It doesn't deal with the problems Software projects have. It looks great for construction or even organizational planning type activities, but there's precious little in there useful to software. My company spent the money to get 2 PMIs and set up a PMO using PMI "best practices". The 2 PMIs got turfed in the last re-org and the PMO is being re-evaluated. It wasn't worth the money because it didn't help up with the day to day help I needed. Now, I've taken a PMI certified course and even was a member of the PMI for a year, but I found the material it provided _useless_ to me in software. Some neat articles about bridge construction though and I did learn one neat thing about monte carlo simulation of project risk, but that's it.

      So please, spare us your sanctomonious slashvertisement for PMI. Most of us with trench experience with PMIs would rather take the guy who learned it on the job than a PMI any day.

  • I believe the word he's looking for is "jibe."

  • On the subject of saying 'no' (Score:2, Insightful)

    by Anonymous Coward
    I agree with this list of mastering saying 'No'. However, I would suggest say 'Yes, but' This is the same thing as 'no', but buys you alot more for your money. ' Yes, but I will need 12 more resources' or 'Yes, but only if we have time'.

    - It sounds possitive
    - Execs will not automatically recoil because you used the N word with them
    - It keeps the relationship in good standing and often turns around the request on the other person.

    Just my 2 cents.

  • I **LOVE** this book!!!! (Score:2, Interesting)

    by dbk25 ( 565275 )
    I was lucky enough to find Scott Berkun's book a few weeks ago (we have a great technical book store in the neighborhood), and I only wish I could have read it years ago. I like Scott's writing style - informative and friendly, and devoid of the self-hype that some other management books wallow in. He also provides the benefit of his experience, without the notion that he has the one golden formula.

    I'm finding it a truly useful survey course book - a solid introduction to many areas, with the understandin

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close