In many organizations, the person leading a project doesn’t have the job title project manager. That’s OK. Everyone manages projects in their daily work, whether they are working alone or leading a team. For the moment, these distinctions are not important. My intent is to capture what makes projects successful, and how the people who lead successful projects do it. These strategies don’t require specific hierarchies, job titles, or methods. So, if you work on a project and have at least some responsibility for its outcome, what follows will apply to you. And should your business card happen to say project manager on it, all the better.
This book is useful in three ways: as a collection of individual topic-focused essays, as a single extended narrative, and as a reference for common situations. Each chapter takes on a different high-level task, provides a basic framework, and offers tactics for successfully completing the task. However, in this opening chapter, I need to take a different approach: there are three broader topics that will make the rest of the book easier to follow, and I will present them now.
The first is a short history of projects and why we should learn from what others have done. The second is some background on the different flavors of project management, including some notes from my experience working at Microsoft. And the third is a look at the underlying challenges involved in project management and how they can be overcome. Although these points will be useful later on, they are not required to understand the following chapters. So, if you find the approach in this first chapter too wide for your liking, feel free to move on to Chapter 2 and the core of this book.
Project management, as an idea, goes back a very long way. If you think about all of the things that have been built in the history of civilization, we have thousands of years of project experience to learn from. A dotted line can be drawn from the software developers of today back through time to the builders of the Egyptian pyramids or the architects of the Roman aqueducts. For their respective eras, project managers have played similar roles, applying technology to the relevant problems of the times. Yet today, when most people try to improve how their web and software development projects are managed, it’s rare that they pay attention to lessons learned from the past. The timeline we use as the scope for useful knowledge is much closer to present day than it should be.
The history of engineering projects reveals that most projects have strong similarities. They have requirements, designs, and constraints. They depend on communication, decision making, and combinations of creative and logical thought. Projects usually involve a schedule, a budget, and a customer. Most importantly, the central task of projects is to combine the works of different people into a singular, coherent whole that will be useful to people or customers. Whether a project is built out of HTML, C++, or cement and steel, there’s an undeniable core set of concepts that most projects share.
Curious about better ways to lead web and software development efforts, I’ve taken a serious interest in that core. I studied other fields to see how they solved the central challenges to their projects. I wondered how projects like the Hubble Space Telescope and the Boeing 777 were designed and constructed. Could I reuse anything from their complex specifications and planning processes? Or when the Chrysler Building was built in New York City and the Parthenon in Athens, did the project leaders plan and estimate their construction in the same way my programmers did? What were the interesting differences, and what can be gained by examining those differences?
How about newspaper editors, who organize and plan for daily production of information? They were doing multimedia (pictures and words) long before the first dreams of web publishing. What about feature film production? The Apollo 13 launch? By examining these questions, I was able to look at how I went about leading project teams in a new way.
However, these inquiries didn’t always provide obvious answers. I can’t promise that you’ll ship sooner or plan better specifically because the advice in this book was influenced by these sources. But I do know that when I returned to the software world after looking elsewhere, my own processes and tools looked different to me. I found ways to change them that I hadn’t considered before. On the whole, I realized that many of the useful approaches and comparisons I found were never mentioned during my computer science studies in college. They were never discussed at tech-sector conferences or written about in trade magazines.
The key lessons from my inquiries into the past are the following three points:
Project management and software development are not sacred arts. Any modern engineering work is one new entry in the long history of making things. The technologies and skills may change, but many of the core challenges that make engineering difficult remain. All things, whether programming languages or development methodologies, are unique in some ways but derivative in others. But if we want to reuse as much knowledge as we can from the past, we need to make sure we’re open to examining both aspects—the unique and the derivative—in comparing with what has come before.
The simpler your view of what you do, the more power and focus you will have in doing it. If we keep a simple view of our work, we can find useful comparisons to other ways to make things that exist all around us. There will be more examples and lessons from history and modern industries that can be pulled from, compared with, and contrasted against. This is similar to the concept defined by the Japanese word shoshin —which means beginner’s mind,[1] or open mind—an essential part of many martial arts disciplines. Staying curious and open is what makes growth possible, and it requires practice to maintain that mindset. To keep learning, we have to avoid the temptation to slide into narrow, safe views of what we do.
Simple doesn’t mean easy. The best athletes, writers, programmers, and managers tend to be the ones who always see what they do as simple in nature but simultaneously difficult. Remember that simple is not the same thing as easy. For example, it’s a simple thing to run a marathon. You start running and don’t stop until you’ve reached 26.2 miles. What could be simpler? The fact that it’s difficult doesn’t negate its simplicity. Leadership and management are also difficult, but their nature—getting things done in a specific way toward a specific goal—is simple.
I’ll allude to these concepts in many chapters. So, if I make references that are out of the stereotypical bounds of software development, I hope you’ll understand why. And when I suggest that decision making or scheduling are simple management functions, I’ll assume you’ll know that this in no way suggests these things are easy to do.
“Human beings, who are almost unique [among animals] in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”
—Douglas Adams
One simple question that arises in studying the history of projects is this: why would anyone willingly suffer through mistakes and disappointments if they could be avoided? If the history of both ancient and modern engineering is public, and we get paid for doing smart things regardless of where the inspiration came from, why do so few organizations reward people for harvesting lessons from the past? As projects are completed or are canceled (and many development projects end this way [2]) every day, little is done to learn from what happened. It seems that managers in most organizations rarely reward people for seeking out this kind of knowledge. Perhaps it’s fear of what they’ll find (and the fear of being held accountable for it). Or maybe it’s just a lack of interest on anyone’s part to review painful or frustrating experiences when time could be spent moving on to the next new thing instead.
In Henry Petroski’s book To Engineer Is Human: The Role of Failure in Successful Design (Vintage Books, 1992), he explains how many breakthroughs in engineering took place as a result of failure. In part, this happens because failures force us to pay attention. They demand us to re-examine assumptions we’d forgotten were there (it’s hard to pretend everything’s OK when the prototype has burst into flames). As Karl Popper[3] suggested, there are only two kinds of theories: those that are wrong and those that are incomplete. Without failure, we forget, in arrogance, that our understanding of things is never as complete as we think it is.
The trick then is to learn as much as possible from other people’s failures. We should use their experiences to leverage against the future. While the superficial details of failure might differ dramatically from project to project, the root causes or team actions that led to them might be entirely transferable (and avoidable). Even on our own projects, we need to avoid the habit of running away and hiding from failures. Instead, we should see them as opportunities to learn something. What factors contributed to it happening? Which ones might be easy to minimize or eliminate? According to Petroski, real knowledge from real failure is the most powerful source of progress we have, provided we have the courage to carefully examine what happened.
Perhaps this is why The Boeing Company, one of the largest airplane design and engineering firms in the world, keeps a black book of lessons it has learned from design and engineering failures.[4] Boeing has kept this document since the company was formed, and it uses it to help modern designers learn from past attempts. Any organization that manages to do this not only increases its chances for successful projects, but also helps create an environment that can discuss and confront failure openly, instead of denying and hiding from it. It seems that software developers need to keep black books of their own.
One problem with history is that it’s not always relatable. It can be hard to apply lessons across decades and sustain empathy for things that seem so different from how work is done today. One alternative is to make comparisons with interesting kinds of modern projects. While this doesn’t have the gravitas of engineering history, it does allow for first-person experiences and observations. Often, seeing things firsthand is the only way to give people enough information to make connections among diverse ideas.
As an example, I know a web developer who believes that his work is unlike anything else in the history of the universe. He feels that because web development requires him to make complex engineering decisions—designing and coordinating as he goes, verifying changes in a matter of hours or even minutes, and then publishing it all to the world—his project and task management is unlike anything ever seen before. He is proud to rattle off CSS, XHTML, Flash, Ajax, and other technologies he has mastered, claiming that they would have baffled the greatest minds 50 years ago. I’m sure that in your experience, you’ve met people like him. Or perhaps you have worked in situations where it seemed improbable that anyone else in the universe ever managed anything as complex as what you were doing.
I suggested to this developer friend that he wander into the back of his favorite lunch establishment on a busy day. For a variety of reasons, it’s interesting to step foot into kitchens (see Anthony Bourdain’s excellent book, Kitchen Confidential, Ecco, 2001), but my specific point was about productivity. The first time anyone sees the quick task management and coordination that occur in a busy professional kitchen, he’s likely to reconsider how difficult his own job is. Cooks are often juggling frying pans with different orders at different states of completion, and scrambling between multiple sets of burners in opposite corners of the kitchen, while waiters run in and out, delivering news of new adjustments and problems from customers.
All of this happens in small, cramped rooms, well over 90 degrees, with bright fluorescent lights glaring above. And despite how many orders go out every few seconds, new ones come in just as fast. Sometimes orders get sent back, or, much like software projects, require custom and last-minute modifications (table 1 is lactose intolerant; table 2 needs the sauce on the side, etc.). Large, busy kitchens are amazing to watch. As chaotic as they may seem at first, great kitchens run with a level of intensity and precision that blows most development teams away.
Working chefs and line cooks are culinary project managers, or as Bourdain refers to them, air traffic controllers (another profession for the introspective to consider). Even though kitchen staff works on a scale smaller and less celebrated than a manager of a software development team, there’s no comparison for daily intensity. If you doubt me, next time you’re at that busy lunch place, ask your server if you can peek inside the kitchen. He might not let you, but if he does, you will not be disappointed. (Some trendier restaurants and bars have open kitchens. If you find one, sit as close to the kitchen as you can. Then follow one person for a few minutes. Watch how orders are placed, tracked, constructed, and delivered. If you go on a busy day, you’ll think differently about how software bugs are opened, tracked, and fixed.)
Another interesting field lesson in project management comes from hospital emergency rooms. I’ve watched on the Discovery Channel and PBS how small teams of expert doctors, nurses, and specialists work together as a project team to treat the diverse and sometimes bizarre medical situations that come through the hospital doors. It’s not surprising that this is the profession that invented the process of triage, a term commonly used on software projects to prioritize issues and defects (discussed in Chapter 15).
The medical environment, especially trauma situations, offers a fascinating comparison for team-based work, high-stress decision making, and project outcomes that affect many people every day (see Figure 1-1 for a rough comparison of this and other work environments). As Atul Gawande wrote in his excellent book, Complications: A Surgeon’s Notes on an Imperfect Science (Picador USA, 2003):
We look for medicine to be an orderly field of knowledge and procedure. But it is not. It is an imperfect science, an enterprise of constantly changing knowledge, uncertain information, fallible individuals, and at the same time lives on the line. There is science in what we do, yes, but also habit, intuition, and sometimes plain old guessing. The gap between what we know and we aim for persists. And this gap complicates everything we do.
Figure 1-1. In the abstract, many disciplines have similar processes. They all dedicate time to planning, executing, and refining. (However, you should never go to a kitchen for medical treatment or eat in an emergency room.)
This point, and many others in Gawande’s enlightening book, holds true for software development. Fred Brooks, in the classic book on software engineering, The Mythical Man-Month (Addison-Wesley Professional, 1995), makes similar comparisons between teams of surgeons and teams of programmers. Even though lives are rarely at stake when working on web sites or databases, there are many valid similarities in the challenges these different teams of people must face.
Project management can be a profession, a job, a role, or an activity. Some companies have project managers whose job is to oversee entire 200-person projects. Others use the title for line-level junior managers, each responsible for a small area of a large project. Depending on how an organization is structured, what its culture is, and what the goals of the project are, project management can be an informal role (“it’s done by whomever, whenever necessary”) or highly defined (“Vincent, Claude, and Raphael are full-time project managers”).
In this book, I’ll primarily use the phrase project manager, or PM, to refer to whoever is involved in project leadership and management activity. By project management activity I mean leading the team in figuring out what the project is (planning, scheduling, and requirements gathering), shepherding the project through design and development work (communication, decision making, and mid-game strategy), and driving the project through to completion (leadership, crisis management, and end-game strategy).
If this sort of work is structured less formally in your world, just translate project manager or PM to mean “person doing project management tasks, even though it’s not her primary job” or “person thinking about the project at large.” I’ve encountered many different ways for these activities to be distributed across teams, and the advice in this book is largely indifferent to them. This book is less about job titles and formalizations, and more about how to get things done and make things happen. But to keep my writing as simple as possible, I’ll rely on the phrase project manager, or PM.
Sometimes the absence of a dedicated project manager works fine. Programmers and their bosses maintain schedules and engineering plans (if any), and a business analyst or marketing person does the planning or requirements work. Anything else that might qualify as project management simply gets distributed across the team. Perhaps people on the team have been hired for their interest beyond writing code. They might not mind early planning, user interface design, or business strategy. There can be significant optimizations in working this way. As long as everyone is willing to pay the tax of responsibility for keeping things together, and distributing the burden that a dedicated project manager would carry for the team, there’s one less employee that the team needs. Efficiency and simplicity are good things.
But other times, the absence of a project manager creates dysfunction. Without a person whose primary job is to shepherd the overall effort, individual biases and interests can derail the directions of the team. Strong adversarial factions may develop around engineering and business roles, slowing progress and frustrating everyone involved. Consider that in hospital emergency rooms, one doctor takes the lead in deciding the course of action for a patient. This expedites many decisions and gives clarity to the roles that everyone on the trauma team is expected to play. Without that kind of clear authority for project management-type issues, development teams can run into trouble. If there is no clear owner for leading bug triage, or no one is dedicated to tracking the schedule and flagging problems, those tasks might lag dangerously behind individual, programming-centric activities.
While I think many of the best programmers understand enough about project management to do it themselves, they also recognize the unique value of a good, dedicated person playing the role of manager.
Microsoft had a problem in the late 1980s regarding how to coordinate engineering efforts with the marketing and business side of each division (some might say this is still a problem for Microsoft and many other companies). A wise man named Jabe Blumenthal realized that there could be a special job where an individual would be involved with these two functions, playing a role of both leadership and coordination. He’d be involved in the project from day one of planning, all the way through the last day of testing. It had to be someone who was at least technical enough to work with and earn the respect of programmers, but also someone who had talents and interests for broader participation in how products were made.
For this role to work, he’d have to enjoy spending his days performing tasks as varied as writing specifications, reviewing marketing plans, generating project schedules, leading teams, doing strategic planning, running bug/defect triage, cultivating team morale, and doing anything else that needed to be done that no one else was doing (well). This new role at Microsoft was called program manager. Not everyone on the team would report directly to him, but the program manager would be granted significant authority to lead and drive the project. (In management theory, this is roughly the idea of a matrix organization,[5] where there are two lines of reporting structure for individuals: one based on function and the other based on project. So, an individual programmer or tester might have two reporting relationships—a primary one for her functional role and a secondary, but strong, one for the project she works on.)
Jabe played this role on a product called Multiplan (later to become Microsoft Excel), and it worked. The engineering and development process improved along with the quality of coordination with the business team, and throughout the hallways at Microsoft there was much rejoicing. After many memos and meetings, most teams within the company slowly adopted the role. Say what you will, good or bad, about the resulting products, but the idea makes sense. By defining a role for a line-level generalist who was not a gofer or a lackey, but a leader and a driver, the dynamics of how development teams worked at Microsoft changed forever. This role of program manager was what I did through most of my career at Microsoft, and I worked on product teams that included Internet Explorer, MSN, and Windows. Eventually, I even managed teams of people who played this role.
To this day, I don’t know of many companies that have gone as far in redefining and formalizing a specialized form of project management. It was rare in my many interactions with other web and software development firms to encounter someone who played a similar kind of role (either they were engineers or business types, or on rare occasions, designers). Many companies use team structures for organizing work, but few define roles that cross over engineering and business hierarchies deliberately. Today, there are more than 5,000 program managers at Microsoft (out of more than 80,000 total employees), and although the power of the idea has been diluted and abused, the core spirit of it can be found in many teams within the company.
But regardless of what it said on my business card, or what Microsoft lore you choose to believe or ignore, my daily functions as a program manager were project management functions. In the simplest terms, this meant that I was responsible for making the project—and whoever was contributing to it—as successful as possible. All of the chapters in this book reflect the core tasks involved in doing this, from early planning (Chapter 3 and Chapter 4), to spec writing (Chapter 7), to decision making (Chapter 8), to implementation management and release (Chapter 14 and Chapter 15).
Beneath these skills, certain attitudes and personality traits come into play. Without awareness of them, anyone leading or managing a project is at a serious disadvantage.
It is hard to find good project managers because they need to maintain a balance of attitudes. In his essay “Pursuing the Perfect Project Manager,”[6] Tom Peters calls these conflicting attitudes paradoxes or dilemmas. This name is appropriate because different situations require different behavior. This means that a project manager needs not only to be aware of these traits, but also to develop instincts for which ones are appropriate at which times. This contributes to the idea of project management as an art: it requires intuition, judgment, and experience to use these forces effectively. The following list of traits is roughly derived from Peters’ essay:
Ego/no-ego. Because of how much responsibility project managers have, they often derive great personal satisfaction from their work. It’s understandable that they’d have a high emotional investment in what they’re doing, and for many, this emotional connection is what enables them to maintain the intensity needed to be effective. But at the same time, project managers must avoid placing their own interests ahead of the project. They must be willing to delegate important or fun tasks and share rewards with the entire team. As much as ego can be a fuel, a good project manager has to recognize when his ego is getting in the way.
Autocrat/delegator. In some situations, the most important things are a clear line of authority and a quick response time. A project manager has to be confident and willful enough to take control and force certain actions onto a team. However, the general goal should be to avoid the need for these extreme situations. A well-managed project should create an environment where work can be delegated and collaborated on effectively.
Tolerate ambiguity/pursue perfection. The early phases of any project are highly open and fluid experiences where the unknown heavily outweighs the known. As we’ll discuss in Chapter 5 and Chapter 6, controlled ambiguity is essential for good ideas to surface, and a project manager must respect it, if not manage it. But at other moments, particularly in the later phases of a project, discipline and precision are paramount. It requires wisdom to discern when the quest for perfection is worthwhile, versus when a mediocre or quick-and-dirty solution is sufficient. (See the section "Finding and weighing options" in Chapter 8.)
Oral/written. Despite how email centric most software development organizations are, oral skills are critically important to project management. There will always be meetings, negotiations, hallway discussions, and brainstorming sessions, and the project manager must be effective at both understanding and communicating ideas face to face. The larger the organization or the project is, the more important written skills become. Despite her personal preferences, a project manager needs to recognize when written or oral communication will be more effective.
Acknowledge complexity/champion simplicity. Many people fall victim to complexity. When they face a complex organizational or engineering challenge, they get lost in the details and forget the big picture. Others stay in denial about complexity and make bad decisions because they don’t fully understand the subtleties of what’s involved. The balancing act here is to recognize which view of the project is most useful for the problem or decision at hand, and to comfortably switch between them or keep them both in mind at the same time (without your head exploding). Project managers must be persuasive in getting the team to strive for simplicity in the work they do, without minimizing the complexities involved in writing good, reliable code.
Impatient/patient. Most of the time, the project manager is the person pushing for action, forcing others to keep work lean and focused. But in some situations, impatience works against the project. Some political, cross-organizational, or bureaucratic activities are unavoidable time sinks: someone has to be in the room, or be on the conference call, and they have to be patient. So, knowing when to force an issue, and when to back off and let things happen, is a sense project managers need to develop.
Courage/fear. One of the great misnomers of American culture is that the brave are people who feel no fear. This is a lie. The brave are those who feel fear but choose to take action anyway. A project manager must have a healthy respect for all the things that can go wrong and see them as entirely possible. But a project manager needs to match this respect with the courage necessary to take on big challenges.
Believer/skeptic. There is nothing more powerful for team morale than a respected leader who believes in what she is doing. It’s important for a project manager to have confidence in the work being done and see true value in the goals that will be achieved. At the same time, there is a need for skepticism (not cynicism) about how things are going and the ways in which they are being done. Someone has to probe and question, exposing assumptions and bringing difficult issues to light. The balancing act is to somehow vigorously ask questions and challenge the assumptions of others without shaking the team’s belief in what they are doing.
As Peters points out in his essay, it’s very rare to find people capable of all of these skills, much less with the capacity to balance them properly. Many of the mistakes that any PM will make involve miscalculations in balancing one or more of these conflicting forces. However, anyone can get better at improving his own ability to keep these forces balanced. So, while I won’t focus on this list of paradoxes heavily again (although it comes up a few times later on), it is a worthy reference. Looking at this list of conflicting but necessary forces can help you step back, reconsider what you’re doing and why, and make smarter decisions.
One fear of those new to project management is that success requires change. New projects are created with the intent to change the state of the world by modifying, building, or destroying something. Maintaining the status quo—unless that’s the explicit goal, for some strange reason—is not a successful outcome. The world is changing all the time and if a project is not as good today as it was last year, it means that it’s fallen behind because the goals were misguided or the execution of the project failed in some way.
It’s hard to ignore the underlying pressure this implies for project managers, but it comes with the territory. Don’t just sit there—make it better. There is always a new way to think, a new topic to learn and apply, or a new process that makes work more fun or more effective. Perhaps this is a responsibility more akin to leadership than to management, but the distinction between the two is subtle. No matter how much you try to separate them, managing well requires leadership skills, and leading well requires management skills. Anyone involved in project management will be responsible for some of both, no matter what his job description says.
But getting back to the issue of pressure, I’ve seen many managers who shy away from leadership moments (e.g., any moment where the team/project needs someone to take decisive action) and retreat to tracking the efforts of others instead of facilitating or even participating in them. If all someone does is keep score and watch from the sidelines, he might be better suited for the accounting department. When someone in a leadership role consistently responds to pressure by getting out of the fray, he’s not leading—he’s hiding. Ineffective or pressure-adverse PMs tend to fade into the periphery of the project, where they add little value.
Some PMs in this situation resort to quantifying things that don’t need to be quantified. Unsure of what else to do, or afraid to do what most needs to be done, they occupy their time with secondary things. And as the gap between the PM and the project grows, the amount of unnecessary attention paid to charts, tables, checklists, and reports increases. It’s possible that at some point the PMs begin to believe that the data and the process are the project. They focus on the less-important things that are easy to work with (spreadsheets or reports), rather than the important things that are challenging to work with (the programming effort or the schedule). They may develop the belief that if they just follow a certain procedure to perfection and check the right things off the checklist, the project is guaranteed to succeed (or, more cynically, any failure that might happen won’t technically be their fault).
To minimize the possibility of confusion, good project managers resist defining strict boundaries around kinds of work they are willing or not willing to do. They avoid bright yellow lines between project management tasks and the project itself. Adherence to checklists implies that there is a definitive process that guarantees a particular outcome, which is never the case. In reality, there are always just three things: a goal, a pile of work, and a bunch of people. Well-defined roles (see Chapter 9) might help those people to organize around the work, but the formation of roles is not the goal. A checklist might help those people do the work in a way that meets the goal, but the checklist is not the goal either. Confusing processes with the goals is one of the great sins of management. I should know: I’ve committed it myself.
Years ago, working on the Internet Explorer 4.0 project, I was the PM for several large areas of the user interface. I felt significant pressure: it was the largest assignment I’d ever had. In response, I developed the belief that if I could write everything down into checklists, I’d never fail. While things do need to be tracked carefully on a project, I’d taken it too far. I’d built an elaborate spreadsheet to show multiple data views, and the large whiteboards in my office were covered with tables and lists (and extra whiteboards were on the way).
My boss let me run with it because things were going well. That is, until he saw me spending more time with my checklists and processes than I did with my team—a big red flag (warning sign). He came into my office one day, and seeing the comically large matrix of checklists and tables I’d written on every flat surface in my office, sat me down and closed the door. He said, “Scott, this stuff is nice, but your project is your team. Manage the team, not the checklists. If the checklists help you manage the team, great. But the way you’re going, soon you’ll be using your team to help you manage your checklists.”
So, instead of focusing on processes and methods, project managers should be focused on their teams. Simple planning or tracking systems should certainly be used, but they must match the complexity of the project and the culture of the team. More precisely, planning and tracking should support the team in reaching project goals—not inhibit them. I’m confident that as long as the PM is paying attention and has earned the team’s trust, any missing tasks, processes, reports, checklists, or other needed project management machinery will become clear before the problems they might solve become serious.
As we’ll discuss in Chapter 10, just because a book or an executive says to do something, or because a technique was employed last month or last year, doesn’t mean it applies today. Every team and project is different, and there are often good reasons to question old judgments. The reason to be conservative with methods and processes is that the unnecessary ones tend to snowball, dragging teams down into the tar pit of difficult projects, as described in Fred Brooks’ The Mythical Man-Month. When processes are required to manage processes, it’s hard to know where the actual work is being done. It’s often the team leader or project manager who has the greatest ability to steer the team clear of bureaucracy, or more cynically, to send the team full throttle into endless circles of procedures and committee-driven thinking.
All managers—from Fortune 500 executives to coaches of sports teams—are vulnerable to over-involving themselves. They know that they are potential overhead, and compulsive involvement is one convenient (though negative) way to try and compensate for it. This partially explains the endless supply of micromanagers; the easiest move for a weak manager is to abuse her power over her subordinates (and in extreme cases, simultaneously blame the subordinates for being incompetent enough to need so much attention). The insecurities managers have stem from the fact that, in industrial revolution terms, managers are not in the line of production. They don’t make things with their hands, and they are not the same kind of asset as those who do.
Managers are not hired to contribute a linear amount of work like a worker or programmer is expected to do. Instead, leaders and managers are hired to amplify the value of everyone around them. The methods for adding this kind of value are different from working on the line. But because many managers are former programmers and were promoted into management from the line, odds are good that they have more confidence and skills at writing code than they do leading and managing people who are writing code.
Like a coach for a baseball team, the presence of a manager is supposed to contribute something different in nature from adding another individual contributor. Sometimes this is done by settling arguments or shielding the team from politics. Other times, it’s providing good, high-level plans or finding clever workarounds for unexpected situations. Because these contributions are harder to measure, many PMs struggle with the ambiguity of their role. As managers, they are easy targets for blame and have few places to hide. It takes a combination of conviction, confidence, and awareness to be effective and happy as a leader of a team.
The best way to find the points of leverage is to make use of the difference in psychology gained from being off the line. A PM will, in the course of his duties, naturally spend more time working with different people on the team than others do, thereby gaining more sources of information and a wider perspective of the project. The PM will understand the business view of the project as well as the technical view, and he’ll help the team translate between them when necessary. That wider perspective makes it possible to deliver critical nuggets of information to the right people at the right time. Though this power can have broad effects, what follows is a simple story that helps illustrate this point in a comprehensive way.
As a habit, I’ve always walked the halls and dropped in on programmers who had their doors open. I’d usually just make small talk, try to get them to laugh about something, and ask them to show me what they were working on. If they offered, I’d watch a demo of whatever they’d show me. Doing this every few days, even for a few minutes, often gave me a good idea of the real status of the project (in Chapter 9, we’ll discuss this practice of management by walking around).
For example, one morning during the IE 5.0 project, I dropped by Fred’s office. He was arguing with Steve, another programmer, about how they were going to get the new List View control to work properly—an unforeseen compatibility issue had been discovered that morning. Neither one of them wanted to do the work. And from what I could hear, it would take a half-day or more to fix. I poked my nose in and confirmed what they were talking about. They nodded their heads, as if to say, “Yeah, why should you care?” I then told them to go talk to Bill down the hall. They again asked why, thinking this was a very specific architectural issue that I couldn’t easily understand. I smiled and said, “Because I just left his office, and he has the new tree control working perfectly on his machine. He came across the problem last night and fixed it as part of another work item.”
Now, of course, in this little story I didn’t save the world or avert a major disaster. If I hadn’t made this connection for them, only a few hours or a half-day would have been wasted (although, as we’ll discuss later in Chapter 8, schedules generally slip a little at a time). But that’s not the point. Good project managers make it their business to know all kinds of useful things about the state of the team—and the state of the world—and then apply that knowledge to help people get stuff done. It’s all of the small bits of timely information transfer, like the one in this story, that make mediocre teams good and good teams great. No project- or bug-tracking system completely replaces the need for people to talk to each other about what’s going on because social networks are always stronger (and sometimes faster) than technological ones. The big challenges like project vision, feature lists, and schedules always come down to lots of little challenges that are positively influenced by how easily good knowledge and information flow through a team. Project managers play a critical role in making that flow active and healthy.
But whether it’s little or big things, the actions and decisions managers make should have clear benefits for the entire team. It might take a week or a month to become visible, but a good project manager will create a positive impact on the quality of the work produced, and often the quality of life experienced by everyone involved. People will feel differently about their work, will say openly that they have a better understanding of what they’re doing and why, and feel better about what’s coming next than they did before. This kind of change only happens one meeting, decision, or discussion at a time, but over the course of a project, that vibe and energy can shift and improve dramatically.
As a result, good managers and leaders often earn a special kind of respect from the programmers, testers, designers, marketers, and documentation people who come into contact with them. The PM should be able to perform feats of thinking, strategy, and leadership that positively impact the team in ways few others can. Often this involves finding shortcuts and clever optimizations in the daily workflow, or giving a boost of enthusiasm or encouragement in the right way and at the right time. They don’t have to be superhuman, or even particularly bright, to do this (as I’ve no doubt discovered). They just have to understand the advantage of their perspective and choose to make use of it.
There is one simple incontrovertible fact: project managers or leaders spend more time with each person on the team than anyone else. They are in more meetings, drop by more offices, and talk to more individual contributors than any other person. They may make or influence more decisions than anyone else in the organization. If the project manager is happy, sad, motivated, or depressed, some of that is going to rub off on everyone she encounters. What PMs bring to the project, good or bad, will be contagious for the rest of the team.
So, if the project manager is focused on, committed to, excited about, and capable of succeeding, the odds increase that everyone else will behave the same way. Managers of any kind are in similar positions of potential power, and there are few leverage points of as much value in most working environments. This means that if it is at all possible to cultivate the attitudes and ideas I’ve described so far, there is no greater place to make those investments than in leaders and managers. This isn’t to say that a project manager has to be a charismatic hero figure who, with barely a shrug, can lead armies of programmers into battle (see the section "The hero complex" in Chapter 11). Instead, he just needs to be genuinely interested in helping his teammates’ reports and be successful at it more often than not.
In the end, the core idea I believe in is that as long as no one gets hurt (except perhaps competitors), and you involved people in the right way, nothing else matters but the fact that good stuff is made. It doesn’t matter how many ideas came from you or someone else, as long as the outcome is positive. Project management is about using any means necessary to increase the probability and speed of positive outcomes. A useful daily mantra I’ve used is “Make good stuff happen.” People would see me in the hallway or working with a programmer at a whiteboard and ask, “Hey Scott, what’cha doing?” And I’d smile and say, “Making good stuff happen.” It became a dominant part of how I approached each and every day, and when I managed others, this attitude extended out and across the team through them. As this book moves on to topic-focused chapters, I hope you’ll feel this attitude, and the core ideas of this opening chapter, come through.
Each chapter in this book will end with a short summary of key points to help you review later:
Project management is everywhere, and it’s been around for a long time.
If you keep a beginner’s mind, you’ll have more opportunities to learn.
Project management can be a job, a role, or an activity (the advice in this book applies well no matter how you define it).
Program management is Microsoft’s strongly defined project management role. It is derived from the idea of a matrix organization.
Leadership and management require an understanding of, and intuition for, several common paradoxes. These include ego/no-ego, autocracy/delegation, and courage/fear.
Watch out for pretension and over-involvement in your management activity. The process should support the team, not the other way around.
If you are a dedicated manager, look for ways to capitalize on your unique perspective of the team and project.
Pick your favorite friend who works in or studies a field other than yours. How does he manage his projects? Is there a special job for the project leader, or is the work of project management distributed across different people?
If being a good PM requires a balancing act of attitudes, how can a PM make sure she is not going too far in one direction or another? How can a PM enlist the help of people she works with to keep her in balance?
Make up a reason and throw a party. (You survived Chapter 1, isn’t that reason enough?) After you’ve recovered from your hangover, and bailed your friends out of jail, consider the following: how is a party different from a project? Compare the challenges and rewards of being a party organizer to being a project manager on a work-related project. What’s different and what’s the same?
Think of a project you worked on that failed. What did you learn and how did you learn it? List the mistakes you made and what you can do differently next time to prevent them from happening again. The process of writing about it will force you to think more carefully and gain more insight from the experience.
Can you think of a kind of work that doesn’t involve project management? If so, how do those in that field organize and plan how the work gets done? What limitations does a lack of organization create? What opportunities does it create?
Can you create leadership moments, or are they events that happen for reasons out of your control? If you wanted to increase the number of possibilities to demonstrate leadership, what could you do?
Imagine a team where people are rewarded exclusively for how well they follow processes and rules, instead of for reaching goals. What would happen to the quality of work? What would the role of project manager be like? What does this say about the potential dangers project managers can create?
Middle managers, or people who manage managers, are particularly prone to over-involving themselves, and creating unnecessary processes, because they are in the middle of the organization. How can a smart middle manager avoid the temptation to micromanage and create too many rules?
[1] Beginner’s mind is an introductory concept of Zen Buddhism. The canonical story is that of the empty cup: if you hold on tightly to what your cup is filled with, your cup will never have room for new knowledge. See Shunryu Suzuki’s Zen Mind, Beginner’s Mind (Weatherhill, 1972).
[2] The CHAOS Report (The Standish Group) is a commonly referenced paper on budget, schedule, and general failures of software projects. See http://standishgroup.com/sample_research/.
[3] Karl Popper was a prominent philosopher of science in the 20th century. See http://en.wikipedia.org/wiki/Karl_Popper.
[4] From James R. Chiles, Inviting Disaster: Lessons from the Edge of Technology (HarperBusiness, 2002).
[5] A good summary of matrix and other organization types can be found in Steven A. Silbiger’s The Ten-Day MBA (William Morrow and Company, 1993), pp. 139–145. But almost any book on management theory covers this topic.
Get Making Things Happen now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
