Book features include:
16 chapters on the critical and common challenges of leading projects and managing teams, over 50 clever diagrams, entertaining photography, war stories of success and failure, snarky humor, executive summaries for each chapter, annotated bibliography, extensive footnotes and references.

Updated edition adds over 120 thought provoking exercises, improved footnotes, tighter editing, and a handy discussion guide.

• Full table of contents
• Sample chapter: How to figure out what to do (pdf)
• O’Reilly’s official press release

Topics covered include:

• How to make things happen
• How to make good decisions
• Specifications and requirements
• Where ideas come from
• How to manage ideas
• How not to annoy people
• Leadership and trust
• Midgame / endgame strategy
• The truth about making dates
• What to do when things go wrong
• Power and politics
• Team communication & relationships
• Visions and plans

Reviews for the first edition:
“I’ve been working professionally as a software engineer for several years and I learned more in the first 100 pages of this book than from my years of experience in the industry.”
-Dan Herisham, Blogcritics.org

“I’ve been reading a new book from O’Reilly which, despite my intense aversion to books of this type, outshines its class.” - Slashdot.org

“The Art of Project Management (O’Reilly), is full of practical tools and real experience that will help you succeed with your projects.. it’s refreshing to see a book on project management that spends as much time on human factors…This book is a candid and honest piece of work.”
- MSDN Magazine

“I’ve finally managed to finish reading Scott Berkun’s The Art of Project Management. My review in two words: Buy it.”
-Steve Makofsky, Furrygoat.com, June 2005

“While the book is well-written and structured, it feels like a nice long talk with someone who is being completely honest about the way things work. It’s the talk that you have with someone that shapes your whole professional life. The moment when you figure out that you can do a good job, treat people with respect, and not waste too much time and effort on things that won’t work. I’m going to keep the book close to my side and refer to it often.”
-Chris Campbell, bitdepth.org, June 2005

“How I managed so long without this book baffles the mind.”
- Richard Stoakley, Group Program Manager, Microsoft Corporation

“…if your job includes any kind of project management especially in the world of web development, you might want to have a look at this. The skills Berkun encourages go beyond one team member’s role, though–communicating well, meeting deadlines, and moving your piece of the project forward are the skills that make anyone the team’s MVP.”
-Merlin Mann, 43 Folders, May 2005

“The Art of Project Management covers it all � from practical methods for making sure work gets done right and on time, to the mind set that can make you a great leader motivating your team to do their best. Reading this was like reading the blueprint for how the best projects are managed at Microsoft� I wish we always put these lessons into action! Berkun made me chuckle, made me think, and best-of-all, after just a few hours of reading, I found myself thinking of many ways I could make my team more effective and my products better.”
- Joe Belfiore, General Manager, e-home division, Microsoft Corporation

“A successful software application is a mixture of programming, designing, scheduling, marketing, testing, some black magic, and a lot of luck. Engineers see it as a technical problem; designers see it as a usability problem; marketers see it as a specifications problem; but nobody sees it as 100% their problem. This book is written for the people who take on the burden of making the whole problem their problem”
- Steve Capps, CEO of onedoto.com and Former Apple fellow

” If you’re a team member, project manager, or even a non-technical stakeholder, Scott offers dozens of practical tools and techniques you can use, and questions you can ask, to ensure your projects succeed.”
- Bill Bliss, Senior VP Of product and customer experience, expedia.com

“Berkun has written a fast paced, jargon-free and witty guide. It’s a great introduction to the discipline, and seasoned managers will benefit from Berkun’s perspectives.”
- Joe Mirza, Director, CNET Networks (Cnet.com)

“…Its strengths are its basis in experience; the inclusion of many illustrative stories; and the thoughtful sections on specs, making good decisions, and politics…an excellent resource for someone trying to make sense of project management.”
- Kent Beck, Author of “Embrace change: Extreme programming explained”

“Of all the many books on project management, ‘The art of project management’ is by far the most easy to read and entertaining. Scott Berkun’s insights, knowledge and sense of humor delivers an exceptional book that no project manager can do without.�
- Michael Viola, Senior Consultant, IBM

“I wish I had this book when I started managing projects. Scott shows us the heart and soul of project management: planning the project, keeping the momentum going, developing a solid relationship with the team, working in an organization. All of these are illustrated with plenty of great examples — both successes and failures — from his own career as a project manager at Microsoft.”
- Andrew Stellman, Stellman-Greene consulting

“Berkun conveys his considerable experience managing projects for Microsoft, while eschewing the technical jargon which plagues most books of this kind. He provides solid advice on how to make your next project go more smoothly. Over and over, I found myself thinking, ‘Oh yeah, *that’s* how it should be done’ and ‘Wow, that makes perfect sense - why didn’t I look at it that way before.”
- Mark Stutzman, Manager of Information Services, FTS Industries

“As a software engineer, the observations in ‘The Art of Project Management’ resonated deeply with my own experiences. Scott’s book gave me a new appreciation for the difficulty and risks, and the tremendous rewards of good project management. This book provides the knowledge and the incentive to become a better project contributor whether you are managing or being managed. Any stakeholder in a software project will benefit from reading this book.”
- Martin Frankel, Senior Software Engineer, TiVo Inc.

“The Art Of Project Management is unique because of its human approach. Berkun understands that people are at the heart of projects, and this makes the book both highly readable and instantly useful.”
- Rich Grudman, IT Project Manager

“As someone who alternatively manages a worldwide team of open source developers and works in a much smaller role inside a large corporation, I found Berkun’s practical, intelligent, and multi-disciplined approach to the art and science of getting things done in groups immediately applicable and extremely effective. Highly recommended for CEOs, project managers, and hackers alike.”
- Matt Mullenweg, Founder and lead developer, Wordpress.org

“This book should be required reading for anyone involved with development, from a single programmer in a small company to a vice-president of a large corporation. ”
- Samuel Greenfield, Manager of System Development, Sports Illustrated Magazine

“Scott Berkun delivers an extremely readable book on the pitfalls to avoid and the techniques to pursue in software program management. He writes with obvious real-world experience and demystifies everything from marketing’s requirements to bug triage in a way that is useful to all members of the development team. ”
- Chad McDaniel, Lead software developer

“In the Art of Project Management, Scott draws from not only his personal experience leading recent high-profile projects at Microsoft, but also lessons from many other fields. Like the broad foundation of the authors insights, this book applies to a wide range of situations, whether in developing software, running a business or any organization.”
- E. Castedo Ellerman, Vice President, Bear Stearns & Co.

” This book is useful to anyone involved in ongoing projects, regardless of whether they have an official leadership role. I�m a designer, not a project manager, and I found more practical information on how to get work done in a software company than any other book I�ve read.”
- Chad Thornton, Interaction Designer, Google Inc.

In “The Art of Project Management” Scott combines his veteran experience inside the world’s most famous software company with his unique and empathetic understanding of human behavior. The result is an amazingly practical and proven set of tools, tactics, and techniques for navigating the thorny waters of project management, people management, and software development. Written in the clear, concise, and often comedic voice his readers have come to expect, “The Art of Project Management” is an unflinching guide to anyone managing, influencing, or participating in the process of software development.
- Bob Baxley, Director of Design, Yahoo! Search

Available now at: Barnes & Nobles, Amazon.com

By Scott Berkun, March 2008

The biggest secret of innovation is that anyone can do it. The reason is simple: It’s just not that hard. Look up the word “innovate” in any dictionary and see what it actually means, instead of what you think it means. You’ll find something like this: To innovate is “to introduce something new.” That’s it. It doesn’t say you need to be a creative genius, a workaholic, or even have on clean underwear. It’s just three little words: introduce something new. And I promise that by the end of this essay, you’ll have all the secrets needed to do it yourself.

The key word in the definition is “new.” The common trap about newness is the assumption that new means something the universe has never seen before. This turns out to be the third most ridiculous assumption in the history of mankind (you’ll have to figure out the other two for yourself). Here’s proof: Name any great innovator, and I guarantee they borrowed and reused ideas from the past to make whatever it is they are famous for.

The Wright brothers, the inventors of powered flight in the United States, spent hours watching birds. As boring as it seems, we have bird-watching to thank for the supersonic jet planes we have today. Picasso’s development of cubism, one of the great artistic movements of the last two centuries, was heavily influenced by his exposure to African painting styles, as well as the work of an older French painter, Cezanne. And Thomas Edison did not create the concept of powered light: You’d have to talk to the thousands of people who died before Edison was born who turned wood, wax, oil, and other fuels into controllable and portable light sources (not to mention Joseph Swan, who patented the electric light before Edison).

Even in today’s high-technology world you can find easy connections between what we call “new” and ideas from the past. The World Wide Web and the Internet get their names from things thousands of years old. The first webs were made by spiders, and the first nets were used to catch fish by indigenous people around the world, thousands of years before the first computer. Google, the wonderful search tool, is often called a search engine, in reference to concepts of physical mechanics, not digital bits.

All these examples prove that the trick to innovation is to widen your perspective on what qualifies as new. As long as your idea, or your use of an existing idea, is new to the person you are creating it for, or applies an existing concept in a new way, you qualify as an innovator from their point of view, and that’s all that matters.

Even with these improved definitions, it takes more to make innovation happen. The tool kit of every innovator typically includes three things: questions, experiments, and self-reliance.

Ask Questions.

The easiest place to start is with things you do every day. Simply ask: Who else does this, and how do they do it differently? If you only know one way to do something, you’re making a big assumption. You’re betting that of the infinite ways there are to do it, the single one you know is the best. I’m a gambling man myself, but I wouldn’t make that bet, as those odds, one against infinity, are embarrassingly bad. Even simple things like washing dishes or tying shoelaces have dozens or hundreds of alternative approaches in use by different people around the world. Those methods are all potential innovations for you and everyone you know. The problem is that people have to go out of their way to find those alternatives and bring them back.

Not sure how to start? It’s with more questions. Useful questions for innovators include:

• Why is it done this way?
• Who started it and why?
• What alternatives did they consider, and what idea did their new idea replace?
• What are my, or my friend’s, biggest complaints with how we do this thing, and what changes might make it better?
• How is this done in other towns, countries, cultures, or eras of time?
• What different assumptions did they make or constraints did they have?
• How can I apply any of the above to what I do?

Many great innovators asked better questions than everyone else, and that’s part of why they were successful. It wasn’t genius, whatever that means, special top-secret brain exercises they did every morning, or even how much money they had. It was through the dedicated pursuit of answers to simple questions that they found ideas already in the world that might be of use.

Isaac Newton asked how could the force of gravity affect apples as well as the moon? And by framing the question that way, he made observations and developed mathematics related to gravity, something no one else had done to his level of satisfaction. Many of Leonardo da Vinci’s inventions started with him asking the question: How does water flow? It was his many studies of rivers, streams, and the way water moved that led to his inventions for water-powered wheels, ways to move water in aqueducts and canals, and pumps for wells. Without asking questions and looking around, even at obvious everyday things like water and gravity, Newton’s and da Vinci’s creative talents would never have had a chance to surface.

Try Things Yourself.

Asking questions is one thing, but trying to answer them is another. There is no substitute for firsthand experience when creating things. The unique aspects of who you are, including qualities you may not like about yourself, are an asset when it comes to creative thinking. No one can see the world exactly the way that you do.

This means that if you can experience, watch, or make something yourself, you may discover lessons and make observations that other people failed to notice. Those observations are the seeds of innovation: You might see an old idea or tool in a way no one else in your family, business, or city has before, and if you follow it, an innovation might be yours.

Remember that the knowledge we have today about the universe did not come from magic books that have been sitting around waiting for us since the dawn of time. It came from curious people who not only asked questions, but followed them to places others weren’t willing to go.

Francis Crick and James Watson, the discoverers of DNA, followed hunches and made guesses to answer their questions, spending hours in labs doing things their professors thought were not only unscientific, but a giant waste of time. Even Socrates, the greatest philosopher of the Western world, was against the idea of writing things down in books. Had his pupil Plato not picked up on the innovation known as writing, and written down Socrates’s story himself, we wouldn’t know either of their names, much less the Socratic method for learning that many universities base their teachings on today.

Progress depends on people thinking independently and following their curiosity as far as they can, including doing things others around them refuse to try.

Try, Learn, and Try Again.

The last step is not to expect success the first time. If you’re doing something new for yourself or your friends, it’s hard to predict what the outcome will be. And the bigger the innovation, the more risk — and work — there is: Making innovative cookies is one thing, but changing the way people think or work is another.

Since long hours of work might be required to satisfy your curiosity, what’s important is how you respond to failure. Can you find the courage to respond not with embarrassment or regret, but with more questions: Why did this fail? What can I learn now? What will I do differently next time? If you can, like most great inventors and creators throughout history did, you’ll be well on your way.

(Note: this essay was originally published at america.gov)

By Scott Berkun, December 10, 2007

Geniuses don’t exist in the present. Think of all the people you’ve met: would you call any of them a genius, in the Mozart, Einstein, Shakespeare sense of the word? Even the commonly called genius grants, from the MacCarthur foundation, shy away from actually calling their recipients geniuses. Most people throw the g-word around where it’s safe: in reference to dead people. Since there’s no one alive who witnessed Mozart pee in his kindergarten pants, or saw young Picasso eating crayons in kindergarten, we can call them geniuses in safety, as their humanity has been stripped from our memory of them. Out of respect, and worship, we allow ourselves to believe the 2% of our heroes we find superhuman is the entirety of who they were.

Even if you believe geniuses exist, there’s little consensus on what being a genius even means. Some experts say genius is the capacity for greatness, while others believe it’s that you’ve accomplished great things. Frankly I don’t care. Chasing definitions for a final, argument ending answer is a waste of time, since the interesting questions defy finality. Worse, you can’t accomplish much as a maker of things if your time is spent arguing about the meaning of words. To the core of my point, the chase for definitions never provides what we want: a better understanding of how to appreciate, and possibly become, interesting people.

I will now take a wild, manic, run through the history of genius. I make no commitment to be definitive in any way. However, I do promise to avoid easy answers, to use facts to support pet opinions, and to state the obvious and the contradictory, especially when they best define the truth.

Have a great, or horrible, family

Picasso, Mozart, Beethoven, Einstein and Goethe are five popular geniuses and they all had parents who took an interest in their creative lives. Mozart and Beethoven had fathers who were professional musicians, and at young ages they were taught by Pops how to read and play various instruments. Can you guess what Picasso’s dad did? Yes, he was a painter, and spent many hours with young Pablo, showing him the ropes. One popular legend around Einstein is his young obsession with a compass from his dad, but more potent in his development was family friend Max Talmud, who taught Albert science, philosophy and other intellectual pursuits throughout his boyhood. And of course there’s Van Gogh and his brother Theo, the only healthy relationship he ever had.

But lousy families can make for geniuses too. Beethoven’s dad was abusive and cruel, torturing him during childhood practice sessions. Unlike what happens to most child prodigies (burnout at age 15 and complete hatred for their gifts and micromanaging self-centered parents) somehow Beethoven’s passion for music survived. Leonardo Da Vinci was a bastard, a child not of his father’s wife, and the little we know doesn’t paint a picture (ha ha) of a healthy child-parent dynamic. Isaac Newton was also born to a single parent home, his father dying several weeks before Isaac entered the world. His mother remarried, Isaac didn’t like it, and perhaps found a seed of unrest to fuel his pursuit of an independent life.

I’m for independence, free will and the belief anyone can do anything, but when it comes to being a genius it’s hard to ignore the role of family, country, and era, all things out of an individual’s control. If Mozart’s dad were an electrician, or Beethoven’s a plumber, what would have happened? Had Emily Dickinson’s mother not been seriously ill for decades, forcing Emily to live mostly in seclusion, would we know her name? Whether positive or negative, opportunities in children’s development create potential, but their work has to surface at a time when their particular talents are valued in the world (demonstrated by the number of posthumously appreciated geniuses, including Kafka, Van Gogh and Dickenson).

Be obsessed with work

Show me a genius and I’ll show you a workaholic. Van Gogh produced 2000 works of art between 1880 and 1890 (1100 paintings and 900 sketches). That’s 4 works of art a week for a decade, and he didn’t start making art until his mid twenties. DaVinci’s famous journals represent decades of note taking, doodling and observations, and it’s a good guess that work was the center of his life: no spouses or children are mentioned in any of our records of him (though he likely had lovers in his studio). Picasso made over 12,000 works of art (“Give me a museum and I’ll fill it” he said, and he was right) in his lifetime, including sculptures, paintings and other mediums. Shakespeare wrote more than 40 plays, not to mention dozens of sonnets, poems and of course, grocery lists. These are people who practiced their crafts daily and sacrificed many other ordinary pleasures in life to make their work possible. Every math or music prodigy practiced to produce the work they are famous for (See the ten year rule).

And of course very few of these works are considered masterpieces, by their creators or anyone else. Sure, today, any coffee stained sketch by Picasso or Van Gogh garners millions, but that has more to do with the signature that’s on the painting, than the quality of the painting itself. No matter the field, the productive have more failures to show than successes by ratios of 10 or more to 1. Hemingway is noted for his belief that writing is rewriting, and that dozens, or hundreds, of attempts are required to write anything well (“The first draft of anything is shit”). Most painters, from Dali to Turner made sketches and studies to experiment and explore before committing themselves to the final versions of the amazing works we see in museums.

Whatever their talents or genetic gifts, most everyone who earned the label genius was dedicated to their work: the list of lazy geniuses is short. Certainly there are burnouts, suicides, and those who spent unproductive years in retreat (or rehab), but none could be called petrified of work. The debate over talent vs. work ethic is moot in history: without the work, we’d never heard of most of these people.

Have emotional or other serious problems

A high percentage of geniuses weren’t particularly happy, well adjusted people. It’d be unfair to say it’s a requirement, but there’s sure evidence for a correlation. For all their brilliance, it doesn’t seem like most of these people led stable lives. Picasso, Van Gogh, Edison, Einstein, and Nietzsche (not to mention almost every major modern philosopher) had difficult, if not disastrous, personal lives. Every one of them either never married or married many times, had children they abandoned or became estranged from, and had episodes of great depression and turmoil. Isaac Newton and Tesla spent many of their days in isolation, and had enough eccentricities and personality disorders to earn a cabinet full of pharmaceuticals today.

Michelangelo and Da-Vinci were troublesome employees, abandoning commissions from Popes and bishops, fleeing cities for threats of war and personal debts. Kafka and Proust were both notable hypochondriacs, each spending years of their lives in bed or in hospitals for medical conditions, some of which we’re psychological in nature or origin. Voltaire, Thoreau, and Socrates all lived in various kinds of exile or poverty, and used their response to these conditions in the works they are famous for. Positive emotions and experiences can work as fuel too, there just don’t seem to be as many genius stories that center on happy, well adjusted lives. John Coltrane, C.S. Lewis, and Einstein had deeply held, and mostly positive, spiritual beliefs that fueled their work. Stephen King seems like a happy guy at his core, despite all the horror that passes through his mind.

Emotions of any kind, positive or negative, provide fuel for work, and many geniuses were simply better at converting their emotions into work than their peers. The need to express feelings, escape suffering, or prove the possibility of an imagined world was stronger in these people than the challenges of the work itself, enabling them to spend more of their waking hours searching for expression, or solving problems, than most people choose to. Creativity and self-expression are hard work for anyone, but perhaps a lesson we can learn from the prolific is to widen our sources of fuel and raise our tolerance for hard work.

Don’t strive for fame in your own lifetime

This is the killer for the ego, but most geniuses received a fraction of the PR in their lifetimes than they received after their deaths. Kafka, Darwin, Melville, Edgar Allan Poe and Van Gogh all died young, poor, and with moderate (and in Kafka, Melville and Van Gogh’s cases, zero) fame for their talents. It’s possible that desiring legend status in your own lifetime spoils whatever magic you have. This theory explains why many people have a single amazing work, but never return to the same artistic, intellectual or creative brilliance in their later efforts. The attention of their fields, or the world at large, may create more pressure than they can manage. The list of suicides and young deaths among brilliant creators is painfully long, including Jim Morrison, Elvis Presley, Kurt Cobain, Van Gogh, Hemingway, Hunter S. Thompson, Sylvia Plath, Virginia Wolf, Alan Turing, John Coltrane, John Belushi, Chet Baker, Jackson Pollock, the lists go on.

Perhaps it’s best not to care what the world thinks, or what labels it gives you, and that independence is the true seed for making great things worthy of, someday, earning you the moniker genius. To focus on the making, the thinking, the creating seems the best way, leaving it to the world to decide, long after you’re gone, what value your work had. As long as you’re free enough to keep making and creating in ways that satisfy your own personal ambitions, or perhaps the tastes of a handful of fans, you’re doing much better than most people on this planet.

Compiled: 6/13/2005

The Situation:

I’m the leader/manager of a team of programmers. Last week we hit a major date, on time, midway through our v3 release. Much rejoicing.

But late last week our biggest competitor (aka "cunning mofos") just announced their v3 release will be out well before ours, and with two major features we do not have. This was a surprise to me and other leaders - we’re not prepared for how to respond.

Two questions:

1. My team is convinced we’re headed for a big project reset - morale and productivity has plummeted. How do I manage the team through this uncertainty? It will take us some time to define our new strategy.

2. What are some suggested strategies I should be considering? Do we release on schedule, with the initial feature set? Do we slip the schedule to match features? I’m trying to build a list of possible choices to work from.

- V3 or not V3?

General notes

• The architect as "roving experienced smart person with fuzzy responsibility" is a big company phenomenon. Most small companies aren’t large enough to have full time employees playing this kind of role. The organization isn’t large enough to afford it or warrant it.
• Someone is accountable for making the whole team function: who is it? Whoever they are, they need to know if there’s a problem. Don’t cry wolf, but do let them know if it’s not working well, or as well as you think it should be. You need someone with enough authority over all parties to help facilitate or negotiate who plays what role in the decision making process.
• Every power position needs and checks and balance system. It could be that one of your programmers should become the lead programmer, who has clearer tactical authority and can work with the architect on a near peer relationship.
• It’s worth talking to the architect directly. They may not be happy about how things are going either and if you can involve them in defining a solution odds of success are higher.
• Faisal pointed out that all good authority comes from argument and decision - dictators who tyrannize the code base become bottlenecks.

Good architect / Bad architect

• David told a story about an architect coming in to save the day. It took time to convince him on the issue, but once he saw where the rest of the team was going he used his considerable power to move things faster in their direction.
• If you’re in a big company, it’s worth asking other teams with architects how they define the architects role and how happy the team is with it. Your VP or general manager may benefit from more context on what architects should and should not do.
• Don’t forget personality conflicts. There could be chemistry issues between the Architect/CTO and one or more of the team leaders that’s leading the architect’s (bad) behavior.

References

Code Complete, Steve McConnell. Has some coverage of architecture vs. programming decisions.

Contributors

Karen Barrett, Faisal Jawdat, Yuval Yeret, John Wilger, Mark Colburn, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 5/31/2005

The Situation:

My mid-sized web development company recently reorganized. I’m a mid-level project manager leading a team of 10 programmers, testers and designers. As part of the reorg my team is expected to work with "the architect". He’s been at the company for a long time as a programmer (started at same time as most VPs), but right now he’s getting in the way of my team - or more specifically I haven’t figured out how to make us effective together.

We’re struggling to figure out what the proper role is for someone in his position. He’s pretty inflexible about his role - as architect he thinks he should be involved in every decision and has the highest authority, making changes or vetoing other decisions. Our team, which has worked well together for awhile, seems him more as a respected influencer, who should be involved enough to give us guidance, but has less accountability for the work than we do. Unless of course he’s willing to write production code, which so far, he isn’t.

We’re just getting started on this new project - does anyone have good/bad experiences to share about the programmer or architect role? How do you balance it with the PM role? What advice do you have for me in working this out?

-Stuck in the Matrix

General notes

• The architect as "roving experienced smart person with fuzzy responsibility" is a big company phenomenon. Most small companies aren’t large enough to have full time employees playing this kind of role. The organization isn’t large enough to afford it or warrant it.
• Someone is accountable for making the whole team function: who is it? Whoever they are, they need to know if there’s a problem. Don’t cry wolf, but do let them know if it’s not working well, or as well as you think it should be. You need someone with enough authority over all parties to help facilitate or negotiate who plays what role in the decision making process.
• Every power position needs and checks and balance system. It could be that one of your programmers should become the lead programmer, who has clearer tactical authority and can work with the architect on a near peer relationship.
• It’s worth talking to the architect directly. They may not be happy about how things are going either and if you can involve them in defining a solution odds of success are higher.
• Faisal pointed out that all good authority comes from argument and decision - dictators who tyrannize the code base become bottlenecks.

Good architect / Bad architect

• David told a story about an architect coming in to save the day. It took time to convince him on the issue, but once he saw where the rest of the team was going he used his considerable power to move things faster in their direction.
• If you’re in a big company, it’s worth asking other teams with architects how they define the architects role and how happy the team is with it. Your VP or general manager may benefit from more context on what architects should and should not do.
• Don’t forget personality conflicts. There could be chemistry issues between the Architect/CTO and one or more of the team leaders that’s leading the architect’s (bad) behavior.

References

Code Complete, Steve McConnell. Has some coverage of architecture vs. programming decisions.

Contributors

Karen Barrett, Faisal Jawdat, Yuval Yeret, John Wilger, Mark Colburn, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 5/25/2005

The Situation:

We have a weekly hour meeting to review project status - but for several reasons these meetings often run much longer (and there is much suffering). The dynamics of our team are such that each person feels the need to either: have an opinion on every single topic that comes up, or analyses the topics to death.

I’ve tried to keep things flowing by getting people to submit status reports before the meeting so that only the issues need to be discussed (but this is failing since everyone is too busy to submit anything); and using a stopwatch to enforce talking limits (but doesn’t fully work as everyone wants to convey their opinion again and again). I know we’ve talked about meetings on pmclinic before, but are there special considerations for project status meetings?

Sincerely,

- Switched Off

General status meeting advice

This discussion had many different kinds of suggestions that may or may not be releveant to any specific situation..

• Take all the chairs out of the meeting room (seriously). People aren’t as willing to gab if they aren’t comfortable.
• Disallow laptops/cellphones/pagers/whatever in the room unless they are necessary for the work you are doing. People tend to sink into their e-mail and then surface after their name is called, requiring a bunch of discussion to be repeated.
• Schedule the meeting for 15 (or 30) minutes and have a meeting right after that you must attend. Invent reasons for hard stops if necessary.
• Cancel the meeting and get the information you need in other ways. Examine how effectively you’re using email, websites or other ways to communicate with the team.
• Aggressively table discussions. Learn the different flavors: “I’m sorry, we don’t have time to talk about that right now, how about tommorow?", “We’re going back over what we discussed already, let’s move on" and “I’m sorry, but right now we’re talking about X. I understand you want to discuss Y, but we’ll do it at another time”
• Have an agenda (every day!) and only cover what’s on the agenda. If people want to talk about something move it to the next day’s agenda
• Schedule the meeting less frequently (2 or 3x a week rather than daily)
• Hand out Nerf weapons and allow people to “vote” with their weapon J (This method is actually used in one of our companies 2-day research offsite meetings—it probably wouldn’t work at most companies, however)
• Schedule the meeting at the end of the day, or right before lunch and let people know that the only thing between them and home/food is getting through the agenda items.
• Talk to people who are habitual “disrupters” outside of the meeting and see if you can find ways of getting them the information that they need so that they don’t hijack your meeting.
• Make sure that only the people who really need to be there are there. Send out e-mail summarizing the meeting to everyone else.

Thoughts on status reports

Something is wrong if people are too busy to write status. Status reports should be a way to help get work done, not just a lost block of time. If you ask people what they spend their time doing, and list the effects you want status reports to have, you’ll find some overlaps. Agree that status reports should be trying to achieve those overlaps.

Thoughts on bad status meetings

Often meetings only show the surface level problems. You probably can’t solve the deeper problems in the meeting itself. If two team leaders have serious disagreements, the meeting will be their battlefield. To solve real problems you often need to talk to people outside of meetings, one on one if possible, and make your case for what problem you see and how you think it might be fixed.

References

Scrum meetings

Contributors

Neil Enns, David Cortright, aisal Jawdat, Jeri Dansky, P Andrew, David Gorbet, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 5/9/2005

The Situation:

My team has finished major development work and is now turning the corner into bug fix mode. I’m the group manager, and I sat down with my dev managers and dev leads to discuss how we wanted the team to prioritize work. We quickly fell into quicksand. I felt we should be prioritizing around importance - the kinds of bugs that we needed to make sure we fixed.

Most of the development managers/leads made arguments in favor of complexity - they wanted us to focus on how difficult bugs would be to fix. The case in point were two examples:

1. Trivial to fix bug that made a pri 1 feature look *awful*
2. Difficult to fix bug that prevented a pri 2 feature from working properly all the time

My argument was that A should come before B, since Pri 1 features come before Pri 2. But they’re argument was that B should come before A. Since they bet we’d have to do it anyway (Executives wouldn’t let it ship), and since it was a big work item we should take it on first.

I quickly realized that my team wasn’t prioritizing for itself - but was prioritizing bugs around management and other perceptions of how other people in the organization would *force* us to prioritize bugs. So in essence my development team wanted to make pre-emptive political choices when it came to bug fixing. Any advice for making this process less frustrating?

- Lost in defect politics

Common bug fixing criteria

Just for reference, here’s some common criteria for evaluating bugs. Priority and Severity are two related but different criteria that all bugs should have.

Severity of this item.

1. Bug causes system crash or data loss.
2. Bug causes major functionality or other severe problems; product crashes in obscure cases.
3. Bug causes minor functionality problems, may affect ‘fit and finish’.
4. Bug contains typos, unclear wording or error messages in low visibility

Priority of this item.

1. Must Fix within 24-48 hours. Blocking build testing.
2. Must fix as soon as possible. Bug is blocking further progress in this area.
3. Should fix soon, before product release.
4. Fix if time; somewhat trivial. May be postponed.
   

Common project timelines that impact bug/defect decisions

Many projects use milestone to indicate overall progress. This basic timeline can be mapped to most methodologies. If defined right these help frame how bugs should be managed at any given time.

• Spec complete: The designs of features are written and reviewed by the team. Work estimates for all work items are in, and leaders add/cut features by this date. The clock of scheduled work begins.
• Code Complete: This is the date when all work items have been finished. Incomplete features should be cut or negotiated with other work. The team switches from creating features to refinement and quality work. All remaining work of any kind should be tracked in the bug database.
• Triage Starts: All bugs must be triaged by a bug committee at this point. Start punting lower severity bugs and ensuring that high-severity bugs get fixed. Battles about priority and severity, such as this week’s situation, should be fought here, if not earlier. There should be daily or weekly goals (and reports) for how quickly bugs should be triaged, how many should be fixed, etc.
• Visual/UI Freeze: All bugs that impact the UI (even if they’re trivial) must be fixed or punted by this date. Make this date early enough so that technical writers and localization folks have time to get their work done before you ship.
• ZBB (Zero bug bounce): This means you hit zero bugs at least once. This gives you the opportunity to settle into a final period where you will fix only the most severe bugs that will seriously impact customer quality. The only bugs considered during ZBB should be new bugs found that were not part of the earlier triage(s).
• RCs (Release Candidate): This should be the first build that seriously a candidate for release. Criteria should be set for what kind of newly discovered defect will cause a second (third, or Nth) candidate.

Managing general bug politics

Early on in the project someone has to define the criteria for evaluating bugs. Even if it’s just the list above (Priority and Severity) it will reduce the number of arguments people have, and elevate the quality of those remaining arguments.

The project goals should serve as the source for decision making. The goals should be interpreted against the current situation (bug count, remaining schedule, etc.) by team leaders and specific instructions should be presented to the eam. If the project goals need to be changed to reflect the current situation, then team leaders need to be very public about this.

So if you find yourself constantly fighting the same battles over bugs, talk to your manager or other team leads. Ask them for advice on how to avoid repeating the same arguments over and over again. if you are a team leader, it’s your job to step up and provide the team with some guidance.

Common ways bugs are manipulated

Here’s a partial list of things to watch out for:

• Inflated priority or severity.
• Feature masquerading as a bug.
• Hot potato bugs. (Bugs assigned away because no one wants to be responsible for them).
• Bugs described in misrepresentative ways to either help get them killed or help get them fixed.
• Bugs that are fixed outside of the team triage, but on the company’s time.
• Raw bug counts used to track competitive progress (10 trivial fixes is not as much work as 1 complex fix).

Managing bug manipulators

If you’re dealing with people that are playing games with bugs like in this week’s situation, here’s some approaches:

• Persuasion: get the one main bug manipulator to have coffee with you, and explain your case. Ask him to try working with bugs differently, even if just for a few days, and give you a chance to demonstrate the better way.
• Force the issue: get key players in a room and discuss this exact difference of philosophy. Outline the 3 or 4 common tactics you see being used and suggest alternative ways to deal with those situations. See if anyone else even cares - if they do, see if there are other bug manipulation issues that need to be discussed.
• Work around the bug manipulators. Stay ahead of the curve and triage bugs early, avoiding the involvement of other folks.
• Get someone with more power/influence than you to use persuasion or force the issue.
• Go to the dark side. Become a better bug manipulator than they are.

If you are seriously considering any of the last 3 on a daily basis it’s time to look for a different team.

The real costs of bug fixing

Several folks commented that bug fixes are often evaluated heavily on their programmers work estimates. This is shotgun thinking: typically the testing time is the bigger hit, especially late in a project. Another important criteria is the probability of fix related faults (bugs caused by the fix to the previous bug).

It’s important for team leaders to hold fast to their goals: if the priorities are really the priorities, then the amount of time it takes to fix a bug isn’t the most important criteria (unless two bugs are of otherwise equal value to the project).

Contributors

Mark Colburn, Shep McKee, Karen Barrett, Steven Levy, Faisal Jawdat, David Gorbet, Andrew Stellman, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 5/9/2005

The Situation:

The current rage in my organization is quality - how to define it, how to measure it, and who should be responsibile and accountable for it. The test team feels it’s their job to measure and drive quality, but they need more power to do so. The programming team feels they own quality, since they actually build everything. And the PM/manager types feel we own quality because we sit between everyone else and see the best tradeoffs.

But right now we’re just arguing in circles. We all agree that quality for our monthly web releases needs to go up - no one is happy. But we are just going round in circles on defining it, improving it, and defining ownership for it. Any advice or war stories (negative and positive), appreciated.

- Going off the rails on the quality train

First steps: What, how and who

There are at least three different questions in this situation. Defining what quality is (what), how to increase it (how), and who’s job it is to do so (who). You may be suffering from one or more of them.

Defining Quality

This is one of the key roles team leaders have to play. They decide which aspects of quality are important through the decisions they make, the goals they set and the behavior they reward. Some of the common attribute of product quality:

• Reliable (performs as expected)
• Easy for customers to use / Easy to learn
• Easy to maintain when completed
• Solves intended problems (for the business, for the customer)
• Good value for dollars spent
• Secure
• Well documented
• Responsive

There are many different perspectives on what quality means. There is a business view, a technology view, and customer or client view (See a client’s view of quality). Smart leaders integrate all three views into their thinking about what quality means for a given project.

Consider a bug free product that no one can figure out how to use. Or an easy to use website that causes browsers to crash every 30 seconds. It should be easy to get people to recognize how nieve singular perspectives on quality are.

In essence, the project goals are the most direct means of establishing quality. Good project goals are tangible enough to seperate what is important from what isn’t, what features are needed from those that are nice, and what problems the project is intended to solve for customers. All of the other forms of quality definition or assurance derive from the project goals in one way or another. If a project has well defined goals and leaders that defend and uphold the goals, including helping individuals match their own daily activities to the goals, the odds of quality results will be high.

How to increase quality

Assuming a fixed amount of time available for work, improved quality comes from using that time in the right way. You have to pick your battles with quality: you can’t make everything better all at once. Instead you have to prioritize and focus the team’s energy.

Simple ways to do this include: group work items in terms of their importance to the customer. Items that will be used more or are deemed more important deserve more time and energy than those that don’t. If certain known defects are causing more harm to customers than others, they should be prioritized accordingly. Resolving those 5 of the right issues will have a larger impact on quality than resolving 20 of the wrong ones.

Quality assurance and test planning is all about focusing energy in the right places. Test plans should be written early enough that the devleopment effort will be influenced by them. The test plan can help identify areas that will require more energy to get right, or that are likely to have more problems than others. A good test plan can positively impact quality well before any testing is done.

Another approach is to budget schedule time purely for improving quality. If the schedule has 10 weeks of development time, budget 2 weeks for additional quality improvements to existing features. Plan on the team recognizing new optimizations during development and create a window for them to take advantage of them. But make sure the team understands the goal: it’s not free time for new features. Instead it’s time to tighten the bolts, shore up weak infrastructure, and deal with some of the larger defects than normally would only get attention during bug fixing.

Who increases quality

The whole team is responsible for quality. Management is responsible for making decisions that enables the team to act on this responsibility: if there are too many features and not enough time, low quality is guaranteed.

Leadership enables quality by making decisions that impact the entire project. Goal setting, resource allocation and schedule making all enable or disable a team to take responsibility for quality. If the goals are clear (and help people make decisions) and resources are allocated to allow people to do great work, quality is likely.

References

Quality is Free, by David Crosby

Contributors

Mark Colburn, Shep McKee, Karen Barrett, Steven Levy, Faisal Jawdat, David Gorbet, Andrew Stellman, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 5/9/2005

The Situation:

The current debate raging across my development team is about how long into development specifications should be maintained. Who should get to decide when specs get updated, if at all? Has anyone in the real world ever continually updated them every day and kept them in sync until release? Was it worth it? How close to daily updates should we be trying to get? How late in the cycle do they need to be kept in good shape for? Who should decide when specs are to be abandoned? The dev team? the test team? The marketing team? the PM team?

Quick answers: Never, sometime, Always

Just to set the framework there are four possible answers to this question.

1. You update specs forever (Never abandon)
2. You abandon them midway through development (sometime)
3. You abandon them at some point after release. (sometime)
4. You never write specs to begin with (Infinite abandon).

Often #2 happens, but with the intent that the team can come back at any time and update the specification. In this all too common situation the the spec is never formally abandoned, but left in an ambiguous state where no one, other than perhaps the spec writer, is sure what’s going on.

What problem do specs solve

Before you can figure out how often to update specs, it’s worth thinking about what problem they solve for the team.

• Human memory sucks. Writing things down is more reliable than your brain.
• Provides a reference for later on as to why a certain decision was made.
• Good specs support the team in making things.
• Good specs explain the complexities people need to understand or are likely to be confused by.
• The quality of test plans, development estimates , and documentation are based on the quality of specifications.
• Specs are often the only documentation for what happened and why for people that come later.
• Updating specs only matter if people are still reading them.
• Specs tend to be read if they are the fastest or best available resource for answering questions.
• Specs don’t solve problems - it’s the questions they answer for people that matter.

So in some cases there might be simpler, faster, smarter ways to achieve these effects than don’t involve updating specifications. In other cases updating the specification is probably the best way to communicate to the team what’s changed,

But always remember: you ship code, not specs. Never confuse the making of specifications with the making of code and products.

Different kinds of specifications

One element of this debate was what specs consist of. Are they high level descriptions of functionality (requirements), detailed engineering plans (technical specs), or detailed designs of User interfaces and the end-user experience (feature specifications). The value proposition for the spec changes depending on what kind of specification you’re talking about.

Another consideration are the programmers. What do they need from specifications? Or more specifically, what information will they depend on specifications to obtain?

Before you make the argument for or against updating, be clear on what kind of specification you’re talking about, who will use it, and what they’ll use it for. Make sure that the customers of the specification are heavily involved in helping you to figure out where to invest your specification time.

Time writing specs vs. time suffering without specs

There was much debate on the list about the tradeoff of time spent writing specs, vs. time lost by those seeking answers to questions that should/could have been answered by the spec. Also, time is lost by people making mistakes that a decent specification could have avoided. If you consider DCRs (design change requests), integration issues or certain kinds of bugs as things possibly avoided by better specs, the costs of lousy or out of date specs are tangible.

If you don’t write specs at all, or don’t update them you’re making a bet:

Time to write/update > time team will spend suffering

If you do write specs and invest in updating, you’re making the opposite bet:

Time to write/update < time team will spend suffering

Several people in the discussion were strong spec advocates: they invest time in writing and updating specs and felt their teams appreciated (and in some cases depended on) this effort.

Before and after making these kinds of bets it’s important to involve the team. Before writing specs you should listen to what the team needs, and after writing specs you should listen to their opinions on how effective the specs were in satisfying them. You can’t evaluate the bet without involving other people.

Contributors

David Gorbet, Denise Neapolitan, J Kremer, Karen Barrett, Neil Enns, Jacquelyn Krones, Steven Levy, Mark Colburn, David Tate, Timothy Misner, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 5/2/2005

The Situation:

I’ve recently moved from a small development team/organization (10) to a much larger one (80) people. I’m having a hard time figuring out how to be effective getting things done without pissing people off - What I see as just being effective and efficient, is sometimes seen as cutting corners, going behind people’s backs, or being “a hacker”. What they see as diligence and proper procedure, I see as a (frustrating) waste of time.

Is there some way for a mid/large organization to keep the speed and autonomy found on smaller teams? Is there any advice I can give to the group manager that can help him balance his org size, and, assuming he agrees with me, with a desire to avoid bureaucracy and keep smart people like me moving at top speed?

- A fast fish in the slow pond

Big teams are trucks, Little teams are motorcycles

The basic rule of thumb is that the bigger the org, the more mass it has. It will take longer to get it moving, but once it does it can move more stuff than something smaller. The smaller the org the faster it can change direction and the quicker it will move, but it won’t be able to move as much stuff at the same time.

With this in mind, there’s nothing evil about big orgs. They just have different strengths and weaknesses than smaller orgs do. This isn’t to say that your desire to optimize or find shortcuts is misplaced, it’s just that the context is different and a successful optimization will be more involved than you’re used to.

Bureaucracy defined

Here are two definitions:

1. Management or administration marked by hierarchical authority.
2. An administrative system in which the need or inclination to follow rigid or complex procedures impedes effective action: innovative ideas that get bogged down in red tape and bureaucracy.

In any organization some hierarchy is required (Definition #1). But impeding effective action (Definition #2) is the opposite of effective management. It’s worth remembering the difference between these two notions of bureaucracy

Designing team process is hard

Hummel wrote "When designing software development process, the risks and consequences aren’t always as immediate and severe. It can be hard to see that the process itself is what is causing the project failures (delays, lack of quality, etc.). That is why process maturity models (i.e. CMMi) focus on ‘continuous improvement‘. In these models, every team member is incented to provide feedback. Over time, the process governors learn from this feedback and the process evolves. "

So this means that if you voice your suggestions of improved process to whomever is defining the process, it’s their job to consider making adjustments. If enough people share your opinion it should be in their interest to consider making changes.

The challenge though is that teams of any size have people with different opinions and needs. For every change that would make you super effective, it might make work mor e difficult for someone else. While it’s true your work might be more important than theirs, when we’re talking about the collective value of 10, 20 or 50 people, it’s difficult for a team leader to sort out the exact value of any kind of process change.

The person defining team processes has to find a way to balance them all out in a way that has the greatest chance of being successful. The larger the organization the more likely it is that leaders will result to a bland, procedure focused way of working. It’s the easiest way way, from a manager’s perspective, to easily track and understand everything that everyone is doing.

Big teams vs. Small teams

One simple way to think of this from a VP level is what level of integration work needs to have, and when you want to deal with integration between them. If there are 10 different products and they require no integration and share no components, there’s little reason to keep them all trapped in a mega-large Borg type organization. But if 7 of those 10 teams share a component from the 8th team, or if 5 of the 10 teams have related business and technological goals, it makes sense to try and keep those things aligned in some way from the beginning instead of waiting until it’s late to get them lined up.

Decentralization and high autonomy can certainly work for integrated projects. There are many good examples from military strategy of dividing forces into autonomous units that share strategic objectives, but diverge on tactics. But to do this requires a level of talent in executive and middle management that is hard to find. As a VP, distributing big amounts of authority to 10 mid level managers requires levels of trust that are rare. And the kind of management skill and philosophy that a VP or group manager would need to have to pull this off doesn’t seem particularly common.

So in some cases it’s not the organization or the people invovled: the organization just doesn’t posses the kind of leaders that could sucessfully manage a highly indepedent and authority distributed development organization.

Possible Tactics

• Do it the way you think it should be done, and to hell wit them. This is arrogant and risky. You’re gambling with people’s trust in you.
• Talk one on one with the people in power. Pick one specific thing you think should change, have a specific recommendation. Repeat until you find supporters, and then collaborate with them on what actions to take. Don’t fight organizational battles alone.
• Do it the way you think it should be done, and apologize later. This gambles that your approach is so much better that good results are guaranteed. If you can get support from your sub team before doing it.
• Play the game but attempt to suggest small changes from the inside. Plan to build the size of your suggestions as the smaller ones pay off and you earn respect.
• Go along to get along. Invest your passions outside of work (Volunteer for an open source project, spend more time with the kids, read those books you’ve been wanting to read). This doesn’t require giving in: instead prioritize your life differently and care more about the things you have control over.

Contributors

Steven Levy, David Gorbet, J Kremer, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 4/25/2005

The Situation:

“Features aren’t developed in Powerpoint, but my management seems to think otherwise. I’m spending the majority of my time reviewing my features with successively higher layers of management and changing the deck layout to match the expectations (or mandate) of the next layer each time. This is starting to impact my ability to ship products – dev and test are craving for specs I can’t deliver yet, and time is slipping by. How can I constructively educate management that visibility is not free and spend more of my time shipping products?"

- Death by Powerpoint

Find out who agrees with you

Some of the managers involved must know there is a better way: you need to find out who these people are and get them thinking about making changes. There may be more people that feel the way that you do than you think. You will have to ask around and talk to people to find them.

If you can’t find anyone in management willing to pursue this kind of change, you’re moves are limited. As managers they decide the team processes for making decisions and you can only go so far in circumventing them. You can either influence them, work around them, or give in.

Slide decks and meetings consume resources

Some managers forget that creating slides and planning / organizing / running meetings consumes real amounts of time. Unlike time spent writing code, time creating slides isn’t tracked or accounted for. It’s possible for a VP to forget that leadership time is not a zero sum game: every slide deck or additional review meeting they ask for is time you are not spending helping the team deliver code, keeping people focused and happy, and ensuring that the work described in the slides or talked about in the meeting actually goes well.

It’s up to you to remind them about what these things cost and what the tradeoffs are in having you spend 30% of your time preparing for and presenting at review meetings.

An approach to change

Colburn offered a simple model for talking to managers about what is currently happening.

1. Identify the Risk. Define how much time per area you are spending on slide decks compared with time on specs or other critical work. What is the risk to product quality? How is the bottom line impacted by the misuse of your time?
2. Evaluate the Options. What problem are the slides supposed to solve? How important a problem is this relative to other problems? What alternatives do you have in mind to creating lots of slide decks? If someone other than you benefits from the slide decks, perhaps they should have more responsibility for them.
3. Get people involved and make a decision. If you’ve managed to get some of the managers involved in evaluating change, get them together and go through #1 & #2 with them. If possible put yourself in the authority position: volunteer to pursue one of your options from #2 to try it out, and evaluate the results. If no one is willing to make a decision, you may have to put yourself in the middle and make the change happen.

Some, but not all, meetings are necessary

The size and culture of any organization influences how dependent people are on meetings. As a general rule the larger the organization the more meetings you will have as there are more people who are impacted by decisions. Also, the more democratic or spineless managers are, the more meetings you will probably have. Lastly, the less effective people are at communicating with each other, the more meetings you’ll have and the more frustrating they’ll be be.

So the goal should be to make as many slide decks or have as many meetings as needed for success to happen, but no more. Slidedecks and meetings are only as evil (or stupid) as the people creating or running them.

Contributors

Mark Colburn, Steve Levy, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 4/15/2005

The Question:

In every company I’ve worked for, there’s been a breakdown between developers and marketing about managing changes. Right now I’m in a small company that uses CVS and Bugzilla to manage development. Before a project starts, we have a marketing requirements doc and a Software requirements doc (SRD). The SRD has mockups done in Photoshop to give the developers guidance as to look and feel. Marketing here isn’t a strict role, basically it’s people that interface with clients on a day to day basis who understand client needs.

Everyone here wears several hats. Along the way, as in most companies, marketing/clients/executives request a zillion changes… move this drop down, change this text, change these colors. It’s not feature creep - just little things that drive developers crazy because of how many there are. To track them, marketing now enters them into the bug tracking system which drives me and the developers nuts. Now development is asking that instead, *they* write a document asking for this stuff and to stick the doc into CVS!!!

Any thoughts on the best way to deal with these myriad change requests? I suppose they could be entered into Bugzilla as “enhancements” rather than “bugs” but the overhead to enter a request, assign the request, make the change, update the entry, assign it over to QA, test the change and close the entry just seems frustratingly high.

- “Design changed” to death

How to manage change:

The lingo for dealing with changes during development is change management. You can find this topic in books on engineering or project management. Colburn defined it this way:

1. Communication of the desire to change something
2. Understanding and documenting the change
3. Quantifying the value of the change
4. Designing the change
5. Assessing the impact of the change (features, schedule, resources, etc.)
6. Accepting or rejecting the change

This can be a formal team process (Typically with some kind of meeting for #5 and #6) or an informal one.

All changes of any kind have some cost - that’s why they’re called changes. The more people impacted by a given decision the greater the odds of costs and the more complicated figuring them out will be (think localization, documentation, usability, etc. They all make decisions based before the change and may have to make their own changes in response to your change).

Questions to ask about incoming changes:

• Is this a change that is in the scope of our current product?
• Given the goals for the project how important is this change?
• What percentage of users will be affected by this?
• What percentage of the product code will be affected by the change?
• Are there easily identified workarounds to the change in the product?
• Is this a competitive threat? (Do our competitors have this feature?)
• How important is this to the customer? The user? Marketing?
• Does this augment, conflict with, or replace a current feature?

The sooner you can make clear to everyone that these questions represent the minimal checklist for even considering a change, the fewer you will have to deal with. You can make a list like this, get team leaders to agree to uphold it, and preemptively send it out to the team before change requests start to come in.

The change control board:

It’s common for teams to set up special groups to manage change requests. Typically the senior person for each role (test, programming, project management) are on the board and they review all incoming change requests.

When these boards work well, they don’t have to review many changes. They define a policy for what kinds of changes should even be considered (see questions above) and then review only those changes.

The change board should meet only as often as needed to manage the incoming changes and make senior decisions on them. The length and frequency of change board meetings indicates the state of the project: if meetings are 5 hours long and happen every day then either the project is in trouble, or the level of change requests being considered needs to be narrowed.

Defending the schedule:

Someone has to defend the schedule against change. If no one ever says no to the VP or customer, even if the request is bad/stupid/self-destructive, then the VP or customer will continue to make that kind of request. Someone has to remind the team of the commitments they’ve made and make sure there are really good reasons for breaking those commitments.

Of course you may not have the power to defend the schedule, but you can still try. Then if someone with more authority than you dictates change you will know that they are doing so in spite of your strong recommendation not to. Should things not turn out well later on, you objection may have been noted by enough people that a different course of action will be recommended by others next time around.

(And be warned: saying no to all changes is almost as bad as saying yes to all changes. Your position on change should be dictated by the project goals and an evaluation of the change in question).

Planned change:

A well managed project can budget time in the schedule for late adjustments. They will keep this in reserve until the project is complete enough that oversights will be visible and can be understood before resources are committed to them.

However, typically software projects are managed at 100%, with all resources being committed to features. This gives the project manager no reserve fuel to use later on and must scrap together resources or cut features / quality.

Contributors

Mark Colburn, Gareth Howell, Fasial Jawdat, Neil Enns, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 4/7/2005

The Question:

You’ve been tasked with interviewing candidates for an open PM position in the company. What do you look for in internal candidates (lateral move / promotion, etc?) What do you look for in external candidates (via a recruiter, etc?)

Extra Credit: You’re the PM who gets to interview an engineering candidate. What do you look for?

Hiring is never easy:

• Berkun and others mentioned how complicated hiring is. Traits are one thing, and fit for team and organization is another. There’s also passion, enthusiasm and a dozen other factors that in combination makes someone a suitable hire for a particular job.
• There is a big difference between knowing what traits you want and identifying them in an interview.
• You have to balance out many potentially competing factors: fit for now, fit for the future, their happiness and potential for growth given their interests and talents.

Internal candidates:

• I’d look for demonstrations of intelligence and drive. Do their peers respect them? Do the engineers and testers that work with them think highly of them, and would choose to work with them again? If they’re an internal candidate I’d take as much information as I can from all the people who have actually worked with the candidate.
• If there was a project manager or team leader that worked with them in the past I’d want their impressions. Did they think of this person as having the traits or skills needed to be a project manager?

Understanding the role:

• Do they really understand how different the project manager role is from their previous experience? Do you believe they are emotionally ready to be accountable for things they don’t have complete control over?
• Are they interested or skilled in how to put themselves in the place of customers, extrapolating from various sources of data to design and manage the making of software that will be used by dozens (or thousands) of people?
• Do they enjoy collaboration? Do they get excited about making other people look good (who deserve it)? Can they handle delivering bad news or talking the fall for their team?

Questions to ask:

There’s a wide range of skills needed to lead projects. These questions are not a complete list of things you’ll need to ask, but they hit on some of the core traits.

• In your experience, what causes things to go wrong?
• How do you get people to work effectively together?
• When do you know you don’t know the answer to something? What do you do about it?
• How do you define success for a project?
• What are the leading causes of software bugs / defects? Schedule slips? Unhappy customers? Cost over-runs? Products that don’t sell well?
• What information do you usually gather before building a schedule?
• When a project runs into serious problems (and all good PMs have faced this predicament), how did you handle it? What was the root cause of the problem?
• How do you usually track an ongoing project?
• Do you gather metrics? If so, what measurements do you gather?
• What is the best project team you’ve ever worked on? What made it so good? How do try to replicate this on teams you manage?
• Design something that solves a specific problem, and allows you to probe their ability to think about the customer, engineering and business perspectives. (Levy offered this example: "Design aloud and on a white board the algorithm for how an elevator services requests in a ten-story building. (Don’t sweat aligning with a floor or opening the door; simply describe how you figure out which requests get serviced in which order".)

And when interviewing for team leader / project management roles always emphasize their experience, and getting them to talk about it.

There’s nothing worse than the candidate who likes to tell you how perfectly everything has gone for them on previous projects. This always means one of three things:

1. They’re lying.
2. They had zero responsibly on those projects
3. They’re on drugs or insane.

On the other hand, there’s nothing better than a candidate that honestly explains what went wrong on a project, how they approached solving it, what the results were (both the good and the bad), and what they would do differently next time. Although some candidates can present these stories in ways that seem awfully packaged and prefabricated, if you ask good questions you’ll force them into new places where they have to really think about it.

Happiness vs. Success:

• Will they be both happy in the role you’re hiring for and successful? It’s possible for people to be successful and un-happy, and unsuccessful (from your perspective) and happy.
• To be happy, they’ll need to enjoy working on fuzzy problems like conflict resolution, leadership, planning and design. They’ll need to enjoy working on things that are big, and not entirely in their control.
• To succeed, they’ll need to be smart, good communicators, sensitive to the differences between people, have an interest in team politics, be good at debate, be good at various kinds of problem solving, likes to get their hands dirty, are comfortable making tough decisions, and have an interest in many different aspects of software development and business.

Contributors

David Gorbet, Fasial Jawdat, Andrew Stellman, Steven Levy, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 3/31/2005

The Question:

We’re in the specification phase for our next release, and the ratio of Product designers (UI designers) to PMs has dropped significantly from our last release. If we use the same process we’ve used in the past (i.e. Design is in on all the feature teams, PMs work with Designers directly for ui design, etc.) we’ll overwhelm the design team and we won’t get the right work done.

So, we need some kind of plan/process through which to prioritize features, assign resources according to priority, and manage the list when things come up that require shifting previous priorities. Or something like that. Whatever process we use, we want Design & PM to be bought in to the plan and both parties feel like their needs are being met.

I’d love to hear suggestions for models that have worked for you in the past when Design (or any partner team for that matter) was short on resources and a more formal process was necessary to keep the release moving and people properly focused and un-frustrated.

- A designer, a designer, my kingdom for a designer

How to prioritize anything:

• One way to look at this situation is about priorities. If there aren’t enough designers to cover the work, prioritize the work and assign designers to the most important work items / features.
• For areas that can’t be covered, find team leads or programmers that have some design skill and assign them as appropriate.
• For areas that still can’t be covered consider: hiring contractors, cutting the work, or postponing those features until resources can be found.

Levels of service:

• One model is to look at any resource (programmers, testers, designers) as a service to the team. If you’re a service, you can provide different service levels.
• Level 1: Platinum - we will drive the design of the entire area.
• Level 2: Gold, we will drive the concepts and core ideas of the design, but will then hand off many decisions to the engineering team, and
  supervise/consult.
• Level 3:Silver, we will supervise and consult, but can’t drive anything.
• Level 4: Dirt. We will ignore you and make silly faces at you when you’re not looking.
• Get all of the influential people thinking in this way and tie each service level to an amount of designer. "Oh, you want level 1 service? We need another designer to provide that to you."

It’s really about quality:

• If you are told to do work without the proper resources you’re really being told to drop quality. If you need 5 designers but only have 2, the real result will be that quality of the work will drop.
• If you want to make arguments to management about resources talk about quality. Don’t just ask for more people, ask what level of quality they want the work to be done at. Arguments about quality are more likely to result in more resources than arguments about resources.

Guidelines and templates:

• With some kinds of design work a good designer can make templates and guidelines that others can re-use. This will at least achieve some consistency across all the work and provide answers to some of the basic questions programmers will have.
• In some ways this helps the team in the future: it puts some basic design skills in the hands of the individuals doing the work. If you expect to face similar problems in the future it’s in your interest to start teaching people the basics now.

Schedules and quality:

• Another approach is to redesign the scheduling process to focus on quality and delivery. Instead of dropping quality when resources are low, each schedule milestone should be framed around the available resources. If there are only resources for 3 weeks of quality work, then that should be what the team schedules for and delivers to. If it’s done right these short milestones will trade low quality for high, and give more frequent deliveries to customers. The downside is that it may take longer for all features to be built, but the making the delivery incremental with high quality might be worth the tradeoff.

Contributors

Marc Colburn, Neil Enns, Matt Hummel, Steven Levy, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 3/24/2005

The Question:

I have a classic project management nightmare: poorly defined requirements, few specs, short lead time, no additional time or resources, and the kicker is it’s a client-based project that, if not delivered on time and to satisfaction, could cost my company a significant amount of business. To add insult to injury:

• the client *insists* that every issue is a showstopper, and refuses to prioritize.
• the client is still pushing to add new functionality
• The client is also peeved because they don’t think our company has been performing on this project.
• Internal politics include a dev manager who is about to be ousted, a tester who is about to be fired (and no replacement), and me: a lone project manager replacing someone who has been under performing but is staying with the company, and not inclined to help me in the transition.

I was brought in, yesterday, to clean up the mess (think Harvey Keitel). I have a ship date of April 15th. I’m in need of some very creative strategies, specifically to wind my way through all the internal and client politics, to soothe a pissy client, and to deliver quality software in 4 weeks! Much thanks to the smart folks at pm-clinic,

- In over my head in Toronto

General Advice:

There were several off list jokes about therapy programs, the availability of various illegal substances, and how one might apply for project manager sainthood.

• One basic concept of management is the tradeoffs between features, schedule, resources and quality. If you are asked to add more features but can’t adjust the other variables you have an impossible mission. You have to find a way to break the deadlock.
• Colburn suggested finding out the leadership history. Are people being demanding because of bad past experiences? What are each of the stakeholders hot buttons? There is more going on than you may realize.
• It’s possible everyone has already given up on this project. You being brought in so late could be a trap: you’ll be blamed despite the impossibility of the situation. Or it could be a way to help kill the project ("We tried 3 different managers and they all had the same result"). See what you can find out about why you were chosen, and what those in this role before you have to say.
• Don’t be afraid to ask hard questions. As a new person to the project play your "I’m new here" card and get answers others have been afraid to seek out.
• Don’t be afraid to walk away. Define what you need to be successful and ask for it. If they say no and are unwilling to negotiate they’re telling you they don’t really want success to happen.

Building Trust

• The failures that led to this situation created a lack of trust across the team. As a new element in the situation you have an opportunity to build new trust. Make small commitments and deliver on them. Make your word mean something.
• Put together an assessment of the situation, where the most urgent problems are, and what your timeline will be for delivering decisions (E.g. Here is where we are and what we’re going to do about it). If you do this honesty and intelligently some people will offer their support to you and your direction.

Clear the Slate

• Make sure your superiors understand the position you are in. If your assignment is the equivalent of running in a burning building, they should evaluate your performance with that in mind. You shouldn’t be held responsible for the failures of the previous project managers.
• Talk to individuals on the team one on one and make clear to them that your involvement creates a new opportunity.
• Talk directly with the client. They’re just as frustrated, or more, than you are. Apologize on behalf of your organization for what’s gone wrong so far. Express your desire to resolve the situation and deal with it directly, fairly, and honestly.
• If people have been misleading each other you can make sure it ends with you. Surface the hidden truths that others have been hiding from and get it out on the table.

Contributors

Marc Colburn, David Gorbet, Jacquelyn Krones, Timothy Misner, Andrew Stellman, Steven Levy, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 3/16/2005

On many projects, the estimation for how much time development and testing require are based on clear requirements and some kind of process. But how should an organization decide how many project managers are needed for a given project? Should there be some kind ratio to the number of developers/testers? Are there different flavors of project managers that are needed in different ratios (E.g. “project manager” vs “program manager” vs something else)?

Advice:

(Note: Currently about 30% of the pm clinic list are Microsoft employees. Microsoft has a strong project management and leadership role called Program manager, often referred to as PM. Large projects at Microsoft can have 20 or 30 people in this role each driving a single feature area of a product, with a group program manager managing all of their work. Some of the advice on this thread assumes a similar PM type role).

David Gorbet made the point that most projects can ship without PMs. The question is how much time or quality is lost without a dedicated leader / coordinator / manager.

Most people agreed there are many factors involved: the kind of work, the strengths/weaknesses of the programming team, and the culture of the organization. We also agreed that ratios were the easiest rule of thumb to work from.

• Neil offered: 1:2:4 (PM/Dev/Test) as the ideal ratio.
• David: 1:3 (PM/ Dev).
• Edwin: 1 PM to 3 Tech Leads / 20 Developers, to 3 Test leads / Testers.

You can not manage what you can not measure

The difficulty of measuring the effort of leaders/managers came up several times. PMs focus on the tasks that are harder to estimate: convincing people of things, keeping people in sync, putting out various kinds of fires, fighting for resources, coming up with ideas, and making tough tradeoff decisions.

Mark pointed out that if you want to estimate how many PMs you need, you have to carefully outline what you expect them to do. Even if you can’t measure it, you can estimate how much time per day they’ll spend on given tasks. And once you have one PM, you can gauge how close those estimates are to reality and know what to expect from a second or third PM (Assuming of course that first PM adds value and doesn’t just get in the way).

The Howell formula for estimating PM time:

PM time = (number of features * (design/spec/project manage + non-feature requirements + communicate and clarify + industry/government engagement ñ strong engineering lead design/spec/project manage + customer engagement*number of customers)) * 4 (if cross group dependencies) + process improvements + schedule management + time spend ëjust being an employeeí (answering email, etc.)

How to estimate project management type work

Here’s a checklist (mostly from Gareth) for helping estimate how much project management type work a project has:

• How ambiguous are the requirements? The more ambiguous, the more PM type work required to clarify them. Who will initiate, drive, document, and negotiate requirements?
• Who drives the design? Who will initiate, drive, document and negotiate the design?
• How much customer engagement is required? Does marketing hand you a marketing requirements doc? If not who will be the primary point of communication between the team and the customer? Is this a good use of programmers time?
• What beyond product requirements need to be met (e.g. compliance/participation in industry standards, company mandates, etc.)? The more complicated these non-feature requirements, the more PM work there will be.
• How self-sufficient is your engineering team? Are developers proficient at managing their time, staying in sync with each other, dealing with politics and non-technological essentials? Negotiating with marketing, customers, management and other teams? Same questions apply to the test or documentation team.
• How much cross-group work is required? If you have a feature that has dependencies from multiple internal or external teams, you’ll need more PM help. My rough rule of them is to multiply any estimates for feature development and PM work by 4x if it involves a dependency who is developing in parallel.
• How many important customers do you have? Are all customer requirements aligned? Multiple customers with conflicting requirements and priorities will generate more PM type work.
• Do you have to keep to a schedule out of your control? (E.g. your team is part of a larger product group). PM time is needed to manage this an ensure that you meet the externally imposed lock down dates, etc.
• What quality do design/specs need to be at? If you’re speccing for external consumption more PM resources are required.
• Are there dedicated resources for marketing, market research, UI design, accessibility? If not who will lead these efforts?

Remember: it’s hard to estimate how many programmers, testers or any role

Berkun mentioned that every conversation he’s heard about estimating the number of testers or programmers needed were just as fuzzy. It’s important to realize that for any kind of skilled work a good worker will be 5 or 10 times as productive as an average worker (Weinberg documented this for software programmers in his book Psychology of Computer Progamming). For fun, get several lead programmers or lead testers in a room and ask how they estimate their staff needs for a new project.

Contributors

Neil Enns, Edwin Marin, David Gorbet, Tim Bishop, Mark Colburn, Gareth Howell, J Kremer, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums

Compiled: 3/10/2005

The Situation:

I’m about to start development with an offshore group of three developers and one project lead. The project lead is based in India but will travel to my office in the US at various milestones. The project is a website redesign for an external client and requires connectivity to their existing database. Beyond my specific situation, what are some of the common traps of working with people who are far away, either in other office locations, or in foreign countries? How can I manage this project so that I avoid as many of them as I can?

- Anonymous manager person, somewhere unknown

Advice:

The less frequent your communication with someone, the more time you need to invest in it. Specifications and e-mails need to be written with a level of craft and care uncommon among those who share the same hallway.

The list of to-do’s for managing remote work:

• Have well defined points of communication at least weekly, if not daily. (Someone, probably you, will have 5am or 10pm phone calls).
• Use screenshots and layout things specifically.
• Use prototypes or demos to demonstrate flow.
• Make sure that your screenshots/prototypes exactly match your spec.
• Make sure that your error conditions, messages, and flows are all spec’ed
• Make sure that you don’t have big assumptions in your spec like “of course, all standard windows semantics will be supported (minimize, resize, restore, etc.) and they will all be run on a separate UI thread so they are responsive”.
• Make sure that you have performance goals specified in the spec.
• Watch cultural issues. Some cultures are very reluctant to bring up issues or complaints.
• You will be frustrated by your inability to take the common shortcuts you take with people down the hall.
• For foreign workers, the definition of test & development is less formal. Your testers may have no formalized test training (Test plan? what’s a test plan?). Check your assumptions and expectations early.

Turn around time

Colburn pointed out that the communication cycles are much longer than most team leaders are used to:

Day 1, you identify the issue, craft a response
Day 1 eve., India gets the message, asks some questions Day 2, you review the questions or initial implementation, and provide feedback
Day 2 eve., India reacts to the clarifications
Day 3, you review the final implementation

This means your response time to crisis/change is much slower than you’re used to. This is another reason for daily phone calls. You are not driving a porsche anymore: you’re now in a Ford Mustang that’s hitched, via a long cable, to a mid-sized trailer.

Contributors

Mark Colburn, Neil Enns, J Kremer, Scott Berkun (editor)

PM Clinic discussion group

General info
How to join
Full archives
Other web forums