Product Description

"'The Art of Project Management' covers it all - from practical methods for making sure work gets done right and on time, to the mindset 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!" - Joe Belfiore, General Manager, E-home Division, Microsoft Corporation "Berkun has written a fast paced, jargon-free and witty guide to what he wisely refers to as the 'art' of project management. It's a great introduction to the discipline. Seasoned and new managers will benefit from Berkun's perspectives." - Joe Mirza, Director, CNET Networks (Cnet.com) "Most books with the words 'project management' in the title are dry tomes. If that's what you are expecting to hear from Berkun's book, you will be pleasantly surprised. Sure, it's about project management. But it's also about creativity, situational problem-solving, and leadership. 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 In The Art of Project Management, you'll learn from a veteran manager of software and web development how to plan, manage and lead projects. This personal account of hard lessons learned over a decade of work in the industry distills complex concepts and challenges into practical nuggets of useful advice. Inspiring, funny, honest, and compelling, this is the book you and your team need to have within arms reach. It will serve you well with your current work, and on future projects to come. Topics include: How to make things happen Making good decisions Specifications and requirements Ideas and what to do with them How not to annoy people Leadership and trust The truth about making dates What to do when things go wrong

Product Details

• Amazon Sales Rank: #255404 in Books
• Published on: 2005-05-06
• Original language: English
• Number of items: 1
• Binding: Paperback
• 374 pages

Review
"The book is written in an easy and witty style that makes for an enjoyable cover-to-cover read, although the structure of the book makes it easy to refer to particular sections as required. Whether you are an experienced project manager or making the transition from developer to manager, I thoroughly recommend that you read "The Art of Projects Management" and keep a copy with you at all the times!" - Jenny Smith, The Developers Magazine - Jan/Feb 2007

About the Author
Scott Berkun worked for ten years at Microsoft Corporation on projects including Internet Explorer, MSN, and Microsoft Windows. He worked for two years in Microsoft's engineering excellence group, teaching and consulting with development teams. He currently works as an independent consultant in project management and product design, and runs the pmclinic, a friendly discussion forum on project management issues at www .scottberkun.com.

Excerpted from The Art of Project Management by Scott Berkun. Copyright © 2005. Reprinted by permission. All rights reserved.
Chapter 3 How to figure out what to do

Few people agree on how to plan projects. Often, much of the time spent during planning is getting people to agree on how the planning should be done. I think people obsess about planning because it’s the point of contact for many different roles in any organization. When major decisions are at stake that will affect people for months or years, everyone has the motivation to get involved. There is excitement and new energy but also the fear that if action isn’t taken, opportunities will be lost. This combination makes it all too easy for people to assume that their own view of the world is the most useful. Or worse, that it is the only view of the world worth considering and using in the project-planning process.

"The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements."
—Fred Brooks

It’s not surprising then that the planning-related books in the corner of my office disagree heavily with each other. Some focus on business strategy, others on engineering and scheduling processes (the traditional focus of project planning), and a few on understanding and designing for customers. But more distressing than their disagreements is that these books fail to acknowledge that other approaches even exist. This is odd because none of these perspectives—business, technology, customer—can ever exist without the others. More so, I’m convinced that success in project planning occurs at the intersections in these different points of view. Any manager who can see those intersections has a large advantage over those who can’t.

So, this chapter is about approaching the planning process and obtaining a view of planning that has the highest odds of leading to success. First I need to clarify some vocabulary and concepts that different planning strategies use (it’s dry stuff, but we’ll need it for the fun chapters that follow). When that is out of the way, I’ll define and integrate these three different views, explore the questions good planning processes answer, and discuss how to approach the daily work to make planning happen. The following chapters will go into more detail on specific deliverables, such as vision documents (Chapter 4) and specifications (Chapter 7).

Software planning demystified

A small, one-man project for an internal web site doesn’t require the same planning process as a 300-person, $10 million project for a fault-tolerant operating system. Generally, the more people and complexity you’re dealing with, the more planning structure you need. However, even simple, one-man projects benefit from plans. They provide an opportunity to review decisions, expose assumptions, and clarify agreements between people and organizations. Plans act as a forcing function against all kinds of stupidity because they demand that important issues be resolved while there is time to consider other options. As Abraham Lincoln said, "If I had six hours to cut down a tree, I’d spend four hours sharpening the axe," which I take to mean that smart preparation minimizes work.

Project planning involves answering two questions. Answering the first question, "What do we need to do?" is generally called requirements gathering. Answering the second question, "How will we do it?" is called designing or specifying (see Figure 3-1). A requirement is a carefully written description of a criterion that the work is expected to satisfy. (For example, a requirement for cooking a meal might be to make inexpensive food that is tasty and nutritious.) Good requirements are easy to understand and hard to misinterpret. There may be different ways to design something to fulfill a requirement, but it should be easy to recognize whether the requirement has been met when looking at a finished piece of work. A specification is simply a plan for building something that will satisfy the requirements. These three activities—requirements gathering, designing/specifying, and implementing—are deep subjects and worthy of their own books (see the Annotated Bibliography). I’ll cover the first two from a project-level perspective in the next few chapters, and implementation will be the focus later on in the book (Chapters 14 and 15).

Different types of projects
Several criteria change the nature of how requirements and design work are done. I’ll use three simple and diverse project examples to illustrate these criteria:1

• Solo-superman. In the simplest project, only one person is involved. From writing code to marketing to business planning to making his own lunch, he does everything himself and is his own source of funding.

• Small contract team. A firm of 5 or 10 programmers and 1 manager is hired by a client to build a web site or software application. They draft a contract that defines their commitments to each other. When the contract ends, the relationship ends, unless a new contract/project is started.

• Big staff team. A 100-person team employed by a corporation begins work on a new version of something. It might be a product sold to the public (a.k.a. shrink-wrap) or something used internally (internalware).

These three project types differ in team size, organizational structure, and authority relationships, and the differences among them establish important distinctions for how they should be managed. So, while your project might not exactly match these examples, they will be useful reference points in the following sections.

Customer Reviews

Doesn't float my boat...
I'm afraid I'm going to have to go against the flow here. I really wanted to like this book. There is most certainly a place for a different angle on project management, other than the usual "how to use Microsoft Project" or other dry-as-dust doorstops, and Scott Berkun enthusiastically tries to fill it. However, the informal, rambling and slightly egocentric style that he deploys to very good effect on his website writings gets irritating and doesn't scale to a book. I kept finding myself quietly screaming "Get To The Point - if you have one". "The art of project management" really boils down to a thinly disguised autobiography of Scott's time with Microsoft. From other articles it seems that either his heart wasn't really in it at Microsoft, or he has resolutely moved on, realizing that to deny his creative side was getting him nowhere (and apart from the paycheck, what satisfaction could anyone derive from managing a piece of such insipid bloatware as Microsoft Internet Explorer ?). I fully empathise with him on this, but not to the extent that I'm going to read his book with blinkers on. The main problem is that there are far too many glib, superficial observations on the dynamics of software development teams dressed up as profundity (actually, this reminds me of a far better book, also from a Microsoft staffer: Jim McCarthy's classic "Dynamics of Software Development", which should be required reading for anybody in any software company anywhere).

There are just too many "so what" moments in Scott's book, things which he seems to think are great insights, but which are just plain everyday life in most companies. There is very little real creative thinking, very few ideas or solutions on offer.

I could take specific issue with a number of points - just one example would be that the "basic" functional requirement he uses to illustrate a point, "There will be a barn and it must be green", it just wrong. It describes an implementation, not a user need. It would be better expressed as a series of statements "there shall be a covered space", "the covered space shall not be heated", etc, which would then lead to the solution space he talks about. But in any case, this is in the domain of requirements management, not project management, and it is hardly the only substantive digression.

The text itself is full of minor digressions and little jokes, which start off ok, but get a little old very quickly. It is also illustrated with sketchy type diagrams, which look cute but convey nothing, and random photographs, a bit like Phil Greenspun's timeless "Phil and Alex's Guide to Web Publishing", but nowhere near as good - or indeed upfront (Greenspun declares openly that the photos are totally irrelevant). Actually, I get the feeling that Scott is a bit of a Phil Greenspun wannabe - well so was I once, and there are plenty of others out there.

Clearly Scott wanted to write, and the most marketable topic was going to be something like this that he could flog to O'Reilly. And clearly, there is a subject here to be written about in a new way. But to be honest, whilst I find his website very useful, and inspirational in places, and I'm sure I'd like him personally, I'm afraid the book is a total dud. With firmer editing and mentoring from a stronger publisher, he might have turned out a classic, but then again, since one gets the impression that despite what he says he couldn't wait to escape from Microsoft, I have my doubts. Perhaps he'll write the Great American Novel one day, but he'll have to tidy up his prose first

practical, well written advice
As someone relatively new to project management from the managing side, but having considerable experience of being managed, I picked up this book to see if I could pick up any tips. I'm glad I did. Scott has managed to distill a huge amount of information and guidance into a very readable work, avoiding the pitfall of so many other books where they end up being dry and dull.

Scott's style is lively and witty, with a mix of the technical jargon, followed up with excellent advice and guidance. The book is split into three sections: Plans, skills and Management. Each section is further broken down in to the core skills and approaches needed to get your project up and running.

I've put a lot of what I've read into practice, and have noticed immediate results - I can now back up my 'gut feel' for how to do stuff with concrete examples of 'why' that approach is best.

It doesn't matter what size of team or organisation you manage, this book *will* help. Do yourself a favour and pick up a copy. If you're being managed rather than managing, buy a copy and give it to *your* manager, then sit back and enjoy the results.

Simply the best book on project management that I've read
I've read a lot of books on project management, and Scott's book really stands out. Scott really captures the "heart and soul" of project management. A good project manager will read this book and become a better project manager, and a novice will learn a great deal about how to run a good project. I especially like the "lessons learned" aspect of this book -- I really got the sense that he's seen his share of projects, and he shares the ups and downs from his past in a way that's really informative. I can't recommend this book highly enough.

(Disclosure: I was a technical reviewer for this book.)