| |
Book_ArtOfPM
Page history last edited by Honesty 2 yrs ago
 
Book Details
The Art of Project Management
æ¤å½±ç‰‡ç›¸é—œæ–‡ç« ：#46 - Why software sucks (And what to do about it)
Microsoft Lesson's Learned in Project Management with Scott Berkun
Art of Project Mgt for Startups with Scott Berkun - Segment 2
Top
Preface
- This book doesn't ascribe to any grand theory or presumptively innovative philosophy. Instead, I've placed my bet on practicality and diversity.
- Projects result in good things when the right combination of people, skills, attitudes, and tactics is applied, regardless of their origin or pedigree.
- The structure of this book is: focus on the core challenges and situations, and provide advice on how to handle them well.
Top
Chapter 1 A brief history of project management (and why you should care)
1.1 Using history
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.
The key lessons from my inquiries into the past are the following 3 points:
- Project management and software development are not sacred arts.
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. 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 can periodically maintain a simple view of our work, we can find useful comparisons to other ways to make things that exist all around us. This is similar to the concept defined by the Japanese word shoshin, which means beginner's mind, 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. 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.
1.1.1 Learning from failure
| 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 |
- 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. As Karl Popper 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.
1.2 Web development, kitchens, and emergency rooms
In the abstract, many disciplines have similar processes. They all dedicate time to planning, executing, and refining.
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.
1.3 The role of project management
- 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). - 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.
1.4 Program and project management at Microsoft
- Microsoft had a problem in the late 1980s regarding how to coordinate engineering efforts with the marketing and business side of each division.
A wise man 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. - Project management functions meant that the PM 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 (Chapters 3 and 4), to spec writing (Chapter 7), to decision making (Chapter 8), to implementation management and release (Chapters 14 and 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.
1.5 The balancing act of project management
It is hard to find good project managers because they need to maintain a balance of attitudes.
Tom Peters, in his essay "Pursuing the Perfect Project Manager,"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.
It's understandable that they'd have a high emotional investment in what they're doing, and this 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 accolades and 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. 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. - 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 his 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. PM must be persuasive in getting the team to strive for simplicity and clarity 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.
Anyone can get better at recognizing, understanding, and then improving his own ability to keep these forces in balance.
Looking at this list of conflicting but necessary forces can help you to step back, reconsider what you're doing and why, and make smarter decisions.
1.6 Pressure and distraction
- 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. - 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.
1.6.1 Confusing process with goals
- 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. - 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 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. - 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. - 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. When processes are required to manage processes, it's hard to know where the actual work is being done.
1.7 The right kind of involvement
- The easiest move for a weak manager is to abuse her power over her subordinates.
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 to the factory or software shop, 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. - 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.
1.7.1 Take advantage of your perspective
- 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. - 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 - 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. 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.
1.7.2 Project managers create unique value
- 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 every day. 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. - The core idea I believe in is that as long as no one gets hurt, 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.
1.8 Summary
Top
Chapter 2 The truth about schedules
- As human beings, most of us arrive at the task of scheduling projects with a questionable track record for delivering or receiving things on time.
We tend to estimate based on weak assumptions, predict outcomes for work based on the best possible set of circumstances, and given our prior experiences simultaneously avoid placing too much confidence in any schedule we see or create. Why we do this, how it impacts project schedules, and what can be done to avoid these problems is the subject of this chapter. - But before we can figure out how to make better schedules, we first have to understand what problems schedules solve.
2.1. Schedules have three purposes
- To make commitments about when things will be done.
The schedule provides a form of contract between every person on a team, confirming what each person is going to deliver over the next week, month, or year. Schedules are often focused externally, outside the project team rather than within, because they are used to help close a deal or comply with a customer's timeline. In order to allow customers or partners to make plans based on a given project, a time has to be agreed upon for when specific things will happen. - To encourage everyone who's contributing to a project to see her efforts as part of a whole, and invest in making her pieces work with the others.
Until there is a draft schedule suggesting specific dates and times for when things have to be ready, it's unlikely that connections and dependencies across people or teams will be scrutinized. Instead, everyone will work on her own task, and tend not to think about how her work will impact others. ‧It's only when the details are written down, with people's names next to them, that real calculations can be made and assumptions examined. There is psychological power in a schedule that externalizes and amplifies the commitment that is being made. Instead of dates and commitments existing only inside someone's mind, they are written down and exist in the universe all on their own. It is not as easy to forget or ignore something when it's posted on a whiteboard in the hallway, reminding you or the team of what needs to be done. Specific to PMs: with a draft schedule in place, questions about how realistic certain things are can be raised, and comparisons can be made between what the project is being asked to do with what appears to be possible in a given period of time. ‧This psychological or pressure shift is what's called a forcing function. A forcing function is anything that when put in place naturally forces a change in perspective, attitude, or behavior. So, schedules are important forcing functions for projects. If used properly by a PM, schedules force everyone whose work appears on them to carefully think through the work they need to do and how it fits into what others are doing. This awareness of the relationship between parts is somewhat independent of the schedule itself. Even if the schedule is goes through a variety of permutations, the commitments and connections everyone has made with each other will be maintained. So, this second purpose of a schedule can be entirely worth the effort of creating a schedule, even if the schedule itself turns out to be seriously inaccurate. - To give the team a tool to track progress and to break work into manageable chunks.
Breaking things down into one- or two-day sizes actually helps people to understand what the work is that they need to do. Everyone thus has a clearer understanding of what tasks will be done when, and each team member has a greater opportunity to ask good questions and clarify assumptions. From the PM's perspective, a good schedule gives a clearer view of the project, flushes out challenges and oversights, and increases the odds that good things will happen.
- The larger and more complex the project, the more important schedules are.
On larger projects, there are more dependencies between people, and decisions and timings have greater odds of impacting others. On a larger project, with dozens or hundreds of people and components, a one-day slip can quickly cascade and create problems in all sorts of unforeseen ways. Big team or small, schedules give managers the opportunity to ask questions, make adjustments, and help the team by surfacing and responding to issues as they arise. - A schedule cannot remedy bad design or engineering practices, nor can it protect a project from weak leadership, unclear goals, and poor communication.
So, for as much time as it takes to create schedules, they are still just lists of words and numbers. It's up to someone to use them as a tool for managing and driving the project.
Book_ArtOfPM
|
|
Tip: To turn text into a link, highlight the text, then click on a page or file from the list above.
|
|
|
|
|
Comments (0)
You don't have permission to comment on this page.