In the updated edition of this critically acclaimed and bestselling book, Microsoft project veteran Scott Berkun offers a collection of essays on field-tested philosophies and strategies for defining, leading, and managing projects. Each essay distills complex concepts and challenges into practical nuggets of useful advice, and the new edition now adds more value for leaders and managers of projects everywhere.
Based on his nine years of experience as a program manager for Internet Explorer, and lead program manager for Windows and MSN, Berkun explains to technical and non-technical readers alike what it takes to get through a large software or web development project. Making Things Happen doesn't cite specific methods, but focuses on philosophy and strategy. Unlike other project management books, Berkun offers personal essays in a comfortable style and easy tone that emulate the relationship of a wise project manager who gives good, entertaining and passionate advice to those who ask.
Topics in this new edition 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 Complete with a new forward from the author and a discussion guide for forming reading groups/teams, Making Things Happen offers in-depth exercises to help you apply lessons from the book to your job. It is inspiring, funny, honest, and compelling, and definitely the one book that you and your team need to have within arm's reach throughout the life of your project.
Coming from the rare perspective of someone who fought difficult battles on Microsoft's biggest projects and taught project design and management for MSTE, Microsoft's internal best practices group, this is valuable advice indeed. It will serve you well with your current work, and on future projects to come.
Scott Berkun is the author of four popular books, Making Things Happen, The Myths of Innovation, Confessions of a Public Speaker and Mindfire: Big Ideas for Curious Minds. His work as a writer and speaker have appeared in the The Washington Post, the New York Times, Wired, the Economist, Fast Company, Forbes, CNBC, MSNBC, CNN, National Public Radio and other media. His many popular essays and entertaining lectures can be found for free on his blog at http://www.scottberkun.com, and he tweets at https://twitter.com/berkun.
This book is really good. A recruiter from Microsoft recommended it to me, saying if I would like to know something about project management, I don't want to miss this book. I bought it and yes it's true! The author gives plenty of details on how to get people involved and how to deal with difficulties in project management. Pretty useful. However, as a student then I could not remember or experience all he said in the book. I took a class in software management and the professor used this book as the textbook. How excited I was! We not only had lots of discussion around the tops of this book, but also acted as project managers for sophomore students in a six-week long project.
I think this book is great for experienced project managers, but for beginners, it's good to scan and skim at the first few times and get to understand the content within gradually.
Excellent book. My main complaint, if you can call it that, was that as an overview, it could only give a taste of the topics covered. Fortunately, Berkun sprinkled follow-up references liberally throughout.
This book focuses on the essence of project management: allowing a group of people to work together to accomplish some goal. It's not tied to any particular technique or methodology. Because it's so general, some individual ideas and recommendations come across as common sense. The value comes from how the ideas support each other. E.g., the notion that schedules are highly uncertain at the beginning and become more certain over time is common sense, but when that is combined with approaches for developing specifications or making decisions or managing risk, it becomes a powerful foundation for running a project.
I don't know how useful this book would be for someone trained as a project manager, but for someone like myself, who has had to pick up project management because someone has to do it, it's a great transition from intuition to a reasoned approach.
Endlich die Zeit genommen, den Rest des Buches zumindest durchzulesen.
Ich würde dem Buch wahrscheinlich sogar eine 5/5 geben, könnte ich es 100% auf mein Arbeitsumfeld anwenden. Aber es ist klar an Projektmanagement in der Softwareentwicklung orientiert. Dennoch lässt sich vieles daraus adaptieren, wenn man die Situationen übersetzt.
Außerdem habe ich bisher noch nicht alle (genauer gesagt - gar keine) Übungen aus dem Buch gemacht, auch wenn ich mir alle notiert habe, die ich nun nach und nach durchgehen will. Nur war ich doch zu neugierig, erstmal das gesamte Buch zu lesen, statt mich länger mit einzelnen Kapiteln zu befassen. Das kommt für mich nun in der Nachbereitung hinzu, die Inhalte, die für mich interessant und relevant sind, zu vertiefen, damit sie auch im Gedächtnis bleiben.
An und für sich kann ich das Buch aber nur empfehlen!
This is an excellent book for anyone who wants to understand project management on a practical level. The author, Scott Berkun, was a project manager at Microsoft, working on Internet Explorer, and draws on this experience in presenting his ideas on managing projects. One thing I like is that he shows his own growth and how he learned lessons in the course of his work, instead of just handing down pronouncements from on high. And the book is definitely full of experience and practical advice. What it is not is another PMBOK, which is OK because we already have one of those.
The book is divided into three parts. Part One focuses on the planning process, and discusses the usual planning and scheduling, but also adds some very valuable material on why you need a vision, what constitutes a good vision, Where good ideas come from, and how to use them. This gets into some very specific application, such as putting prototypes together and getting in front of people, which I think will seem natural to anyone in an Agile environment.
In Part Two he dives into Skills, with topics like “How to make good decisions”, communications, meetings, and how to not annoy people. This is very useful because sometimes we do things that do annoy people, and that is not helpful when we need their assistance to make the project move forward.
The last section is called Management, but a lot of it is based on an analysis of what constitutes leadership, how to get power, and how to use power. He is very practical, and I liked his discussion of the pluses and minuses of an office near the boss. The minus happens if your boss is a micro-manager who interferes with you, but being in a position to hear everyone else’s interactions with the boss can be priceless.
All-in-all, I think any project manager will find a lot of valuable advice in this book. The other good thing is that Berkun is a good writer, so I found I was drawn to keep reading, unlike some books that you slog through for a few nuggets.
This a very long-winded read. The author beats about the bush and pace around hot porridge like a cat. It seems like he wrote this book for software designers (that I'm not), and the chapters towards the end were more relevant to me. He would often advise you to skip a few lengths, and I wonder why he bothered to include it at all. It does contain useful information, but it's also a boring book.
Въпреки, че малък процент от книгата ми беше полезна е доста добре написана. Хареса ми систематичният и последватален стил. Ако сте в голяма компания е точно за вас. Частите за боравене с хора, конфликти и простите неща много ми харесаха. За съжаление голяма част от книгата е политика, комуникация в по-големи организации. Но пък лесно се усещах кои моменти да пропусна :-)
A gem. Must read for all developers, project managers and leaders alike. A must-have on the shelves of all experienced lead engineers, project managers and people managers
Key points:
- Project management requires us to master a number of things such as planning, understanding what needs to be done, writing a good overall vision statement,understanding where ideas come from, understanding what to do with ideas, writing good specifications, understanding how to make good decisions, communication and interpersonal relationships, what to do when things go badly, understanding why leadership is built on trust, making things happen, managing the strategy in the middle and at the end of the project, or understanding questions of power and politics - Technology and skills might change, but the central challenges remain the same. - The simpler your vision of what needs to be done, the greater your power of concentration to accomplish it. - Staying open and curious is what makes growth possible. To continue learning, we must resist the temptation to succumb to the safe and narrow visions concerning what we are doing. - Simple doesn’t mean easy. - Even when schedules are not reliable, we should and use them because: 1. They allow **the team to engage**. 2. They encourage **everyone to see their work as a contribution to the whole**. 3. They allow us to measure progress. - **Big schedules must be divided into small plans** to minimize risks and increase the frequency of adjustments. - **All estimates are probabilities.** Because schedules are collections of estimations, they are also probabilities. This works against scheduling precision because probabilities are cumulative (80% x 80% = 64%). - **The more estimates you make, the less precise they are.** However, rough estimates are the only way to create a point of departure for having better ones. - **Schedules must be made with skepticism**, not with optimism. Invest time in the design phase to highlight the assumptions made and the confidence that has been placed in them. - Vision statements **distill planning artifacts** into a single high-level plan. - Writing things down serves both the writer and the team. It provides a basis for discussion and a **point of reference that does not depend on people’s fallible memory**. - The amount of detail of a vision statement **varies with the nature of the team and the project**. - Team objectives must be **derived** **from the objectives defined in the vision**. Individual objectives must be derived from team objectives. - Good visions are **simple, goal-oriented, consolidated, inspiring, and memorable**. - Quantity does not mean quality. **It takes more effort to be concise than the other way around**. - **Keep the vision alive** by asking questions about the usefulness of the vision and about the daily decisions of the project. - A high-quality requirements definition and an exploration of the **concept are the best use that you can make of your time**. - Ideas are good or bad **only with the objectives or other ideas**. - Ideas morph into designs **via conversations between different people** with different types of expertise. - **Good specifications simplify**. They are primarily a good form of communication. - **Specifying is very different from designing**. - The person who has control over writing the specifications **should have clear authority**. A review process is the simplest way to define and control the quality of the specifications. - **Use comparative analysis** for decisions that are worth the effort. - Interpersonal relationships **improve and accelerate** communication. - To be a great leader, you must learn how to **find, build, earn and give trust** to others – as well as learn to **cultivate trust in yourself** - Middle-game strategy: 1. If things are going well at the end of the first day, the objective for the next day is to **make it so that things continue to go well**. 2. If on any day the project is not going well, it’s your job to figure out **what the problems are and to act** so that the project goes well again. This can take hours, days or weeks. 3. **Repeat** until the project is finished. - End-game strategy: - A big target is a **series of little targets**. - Every milestone has three smaller targets : - **Design** complete (specifications complete) - **Functions** complete (implementation complete) - **Milestone** complete (quality assurance and refinement complete) - Defining the exit criteria at the beginning of the milestone **increases the ability of the team to finish on time**. - Being on schedule is **just like landing an airplane:** you need a long, wide approach. And **you better be ready take off again quickly**, without having to make major repairs.. - You need **metrics** to track the project. Common metrics include day to day work, bug management and the business charter [?]. - You need **control elements** to adjust the levels of a project. Common elements include review meetings, tries, and centralized decision making at the end of the project. - The end of the game is a slow and difficult process. The challenge is to **reduce the scope of the changes** until you have a satisfactory finished product. - Now is the **time begin the postmortem process**. Give yourself, as well as your team, the benefit of learning from what went well and what didn’t go well. - If fortune is smiling on you, and your project works out, **be happy**. Very, very happy. A lot of people, even though it is not necessarily their fault, don’t get that far. Look forward to a great night out. Do something fun and extravagant (like inviting the author of the book to a party). **Provide stories** that will be told for years to come. - Politics is a **natural consequence of human nature**. When people work together in groups there is a **limited amount of authority** which can be distributed amount different people with different wishes and different motives. - All leaders have political constraints. Every executive, CEO or president has peers or superiors who limit their ability to make decisions. In general, **the more power someone has, the more complicated are the constraints upon it**. - There are **many different types of political power**, like rewards, coercion, knowledge, references, and influence. - Power is **misused when it is applied to things that do not further the objectives** of the project. A lack of clarity with respect to the objectives, loosely allocated resources, or unclear decision processes can contribute to this misuse of power. - To resolve political problems, **be clear about what you want**. Identify who has it, and then evaluate hoq you can get it. - If you are involved in project management, you lay out a political playing field around you. **It’s up to you to decide up to what point it is honest or unfair**.
If you’re looking for all the pieces to build your project management compass, this book contains a vast majority of everything you will need along with references to much more. As accomplished as I felt finishing this book I now have a list of half a dozen other books to guide me on my project management journey. Its important to realize that this book is also an extremely valuable reference tool for the current project manager as it contains a plethora of listed questions to ask yourself dispersed throughout the various appropriate chapters. Scott also continues to go the extra mile by providing digital formats like PM Clinic with which to create a living PM experience that grows far beyond the pages of the book.
I enjoyed the comedic relief throughout the book also, including one of my favorite quotes from “Fight Club”; “Just because you stick feathers up your but, it doesn’t make you a chicken”. In this book theres no faking it, he’s provided the whole chicken, no bull$@!t.
This is one of the first books I read about project management. In summary, being a PM is all about solving issues around the team, shielding and helping the members and thus the organisation to achieve its goals. How do you do that? The book gives good advice on many topics. Definitely worth reading.
Автор замахнулся практически на библию проектов - слишком много тем - и политика и психология. Интересно, здраво, но нет фокуса на самом менеджменте проектов.
This book taught me a new respect for project management. In a lot of ways my job isn't too different from software development. But this book really applies to any job where you (1) deliver something to a client or (2) work as part of a team. Project management is hard, that's why some people make careers out of it. At work we don't really have project managers, in fact they try to keep responsibility as diffuse as possible. Which is fine if you want to avoid drama and internal strife but really bad if you actually want things to get done. One idea that has really stuck with me is "management by walking around." The idea her is that with software development it can be very difficult to appreciate the team aspect. A lot of people work independently and other people only get involved when you screw up or they screw up. But a good manager will stop by, ask "what problems are you dealing with?" and provide input. Lots of other good stuff in the book, I really liked the section on writing good emails as well.
My only complaint is that the book is very wordy, though well organized. The author will have the first sentence / main idea in bold and then 4-5 lines explaining it. More often then not I could just read the bold sentence and understand his point.
A book that covers many areas of a project, starting from the project idea and planning to the project realization.
Some of the topics covered are: - Schedules and how to make more accurate predictions - How to take requirements and generate specifications - Relationships of a manager with the team - The importance of processes in a team - Making team meetings worthwhile and how to write non-annoying emails - The importance of trust in a team to tackle issues and get good project estimates - Prioritization of the project tasks and how to triage new tasks and bugs - The importance of exit criteria in work items (i.e. when to consider that a feature is ready) - What to do when things go wrong in a project - How to navigate through office politics and shield your team against them
In general, if you are interested in project management or in general how a project and a team is directed successfully to the end, then this book is a good starting point.
Great, Quick Read. A lot of useful information here. I've read many books on managing software projects, and they often tend to tell you what goes wrong or can go wrong, which I know already, as I've lived it. This book actually provides many helpful solutions. The book makes an effort to recognize that processes should support the workers, not the other way around, so the topics are not obsessed with schedules and charts and the rigidity you find in most pm books. The author takes into the human and organizational aspects of the project and intertwines these with the goals to present ways to organize yourself for success and stay there. I don't think you need to be leading a project to get something out of this book. I think the content is great for everyone from the manager(s) to individual contributors. Its a solution kit for succeeding at software projects and I plan to keep it by my side as a reference and re-read in the future. If you're doing any agile or feature driven development, this will be very useful.
Scott Berkun proposes an alternative, more casual and empirical approach to Project Management, and many elements of this book highlight that, from the hand-drawn diagrams to the chapter titles and of course the writing style. The result is a pleasant read that feels lightweight yet deep. There's a lot of good advise in there, drawn from both Berkun's personal experience with Microsoft and from third-party sources. Not every chapter is equally good however and some sections feel rushed or shallow. Most characteristically, the diagrams add almost nothing to the text and his attempts to list out all possibilities can fall short sometimes. But Berkun is a clear thinker and a very good communicator, so any drawbacks are overshadowed by the overall quality of this book. Highly recommended for Software Project Managers.
Great book on general project leading and a bit of management.
Gives a lot of good strategies and tips on how to get the ball running, structure a project and influence the decision makers. I would say its a must read for anyone who needs to get more of a "intuitive" understanding of how to run a project and deal with people, and who might not be the actual PM but more in a leading position. The theory of actual project management tools and techniques is not covered in detail and should be referred to in another book.
If you need to get an understanding of how to deal with tricky situations, handle people, monitor project progress, pitch a vision or deal with power politics, this is the right book for you.
I had, despite his other books, high hopes on this one about project management. Unfortunately, this book is a wordy collection of very general strategies and tactics, lacking the practical advise it advertises. There are a few original ideas, but right at the moment when you get interested and would like to read more, the chapter ends.
This second edition has “120 thought-provoking exercises”, but don’t get too excited. Those are questions, without answers, and thought-provoking isn’t a word I would use to describe them.
I can’t understand how this book got its glowing reviews. It must be the best-selling author that turned those banalities about project management into gold.
This book provides very general strategies and tactics to carry out successful software project management, including communication, politics. Yet this book does not include practical techniques, such as how to come up with a work breakdown structure, how to make estimates, etc. Still it raises interesting question about challenging situations, which most of us (I believe) have not been exposed to.
My favorite word in the English language is how. How does this work? How was this made? How did they do this?
Japanese word shoshin —which means beginner's mind, or open mind
simple is not the same thing as easy. For example, it's a simple thing to run a marathon. You start running and don't stop until you've reached 26.2 miles. What could be simpler? The fact that it's difficult doesn't negate its simplicity.
"Human beings, who are almost unique [among animals] in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." —Douglas Adams
Boeing Company, one of the largest airplane design and engineering firms in the world, keeps a black book of lessons it has learned from design and engineering failures.
The medical environment, especially trauma situations, offers a fascinating comparison for team-based work, high-stress decision making, and project outcomes that affect many people every day.
Some PMs in this situation resort to quantifying things that don't need to be quantified. Unsure of what else to do, or afraid to do what most needs to be done, they occupy their time with secondary things. And as the gap between the PM and the project grows, the amount of unnecessary attention paid to charts, tables, checklists, and reports increases. It's possible that at some point the PMs begin to believe that the data and the process are the project. They focus on the less-important things that are easy to work with (spreadsheets or reports), rather than the important things that are challenging to work
A checklist might help those people do the work in a way that meets the goal, but the checklist is not the goal either. Confusing processes with the goals is one of the great sins of management.
"Scott, this stuff is nice, but your project is your team. Manage the team, not the checklists. If the checklists help you manage the team, great. But the way you're going, soon you'll be using your team to help you manage your checklists."
Other times, it's providing good, high-level plans or finding clever workarounds for unexpected situations.
Scott Berkun's "Making Things Happen" is a brilliantly written project management book that covers a broad range of skills and scenarios that you will acquire and experience, respectively, during your journey of managing projects. The author comprehensively explains how project management is done in detailed yet easy to read words.
The book is presented in sections that Mr. Berkun suggests to be skim-read if certain parts do not relate to the reader, making it flexible for readers to keep reading and customizing the information as appropriate in their quest for managing their projects. Topics from planning to process to even work politics are discussed in a very honest manner that makes things more relatable for the readers, even if they are currently not managing any projects at the moment. This book is part of a useful learning process, and there are even exercise questions at the end of every chapter to help readers remember what they read and even implement their learnings from the chapters into real life.
Some exercise questions, however, have a downside. As I answered them in my notebook, I found some questions that assume the reader is currently managing a team like in a traditional workplace. As of writing this book review, I work alone on my own projects therefore these questions felt non-applicable to me, although I understood that they were definitely important for managers working with teams. I would have liked it better if the author framed such questions to fit all project managers, whether they are solo or part of a team.
Aside from that, "Making Things Happen" is an effective book for people interested in knowing how to start and take control of business and non-business projects, and offers proper strategies and suggestions for people to make decisions on projects. Recommended reading for business book readers and students of business.
I was asked to read this text for a Project Management course I am taking in a Masters Program. While the book does do a good job discussing the in's and out's of Project Management the inconsiderable amount of sexist overtones makes me burn with rage everytime I am forced to crack the spine of this text for my classwork. I will use this excerpt from Chapter 12 as an example:
" When someone consistently takes action without regard to her commitments, she creates waves of concern that disturb the team. Energy is taken away from people who have to work (or contend) with her. Instead of applying their energy toward completing work, they now have to expend energy calculating whether she will actually do what she says she will. Contingency plans have to be devised, and levels of stress and doubt rise (“ If Marla doesn’t get that code checked in by the end of today, we’re hosed.”). The more careless someone is with the responsibility she has, the larger the waves will be."
Prior to this there is an example given using men, but the imbalance of the two sexes and the use of pronouns in the text is incredibly alarming. Why did the author in the second addition of the text change the pronouns to they/them instead of she/her or he/him so NO sex was directed attention to? Personally, while the text does discuss Project Management I would never recommend this text to someone in 2021 unless there was a more inclussive re-write.
Book contains plenty of information on planning, scheduling, and leading the project to completion. Also, the author gives practical advice on communication and collaboration.
Pros: + The book based on the author's experience and contains plenty of observations, examples, stories. No theoretical nonsense. I appreciated openness with what the author spoke of his times as a PM. + Throughout the book the author provides checklists or lists of questions that can help during a particular stage of the project or situation to identify overlooked options/solutions/perspectives. + Clear structure and language, easy to navigate and read
Cons: - Overgeneralized. The author tried to cover all kinds of projects and developments - it's supposed to be a good thing, but it makes it pretty hard to apply in real life. I understand that there is no silver bullet solution, but when I tried to reread some chapters to apply on my project I had a feeling that solution was slipping away. It went something like this: according to the book in a particular situation you can do A, or B that is opposite to A. There are also options C and D. How do I know what to pick? As far as I got, the author's answer is - only from experience. Uh oh. - Every point in the book is thoroughly explained as if in a specification. Unfortunately, it also makes the book a bit boring and encourages skipping a paragraph here and there.
Making Things Happen is the revised edition of The Art of Project Management. Once it was clear how popular the text was going to be, O’Reilly and Berkun took out some of the superfluous bits, added in over 120 exercises and generally spruced it up to launch it into the best-seller list.
Making Things Happen is method agnostic – no recourse to PMBOK® Guide or the PRINCE2® handbooks – which again, is no bad thing. It makes the techniques easier to adopt as they are about the ‘doing’ rather than the ‘process’ which makes this a very practical, easy-to-read, easy-to-implement book.
The bottom line is that if you work with projects you need this book on your shelf. It’s the book I wish I had written. Ten stars for Berkun.
I recommend this book to anyone who works on projects, especially software projects. The author is a former product manager for Microsoft. The book covers many of the aspects of typical projects. It’s not specific to any one methodology, but it does provide an overview of agile and waterfall. If you are not a project manager, you still need to know how projects run, and this book is very accessible and the essay format gives a good overview of things like planning, estimating, project schedules, gathering requirements/user stories, writing specifications, and common things that can go wrong on projects.
The role of manager is to amplify team members potential
To reduce impact of emotions on decision making, write about issue and discuss issue. It will reduce the motional burden
Top things that annoy people: 1. He things I am stupid 2. He doesn't trust me 3. He does respect my time 4. He doesn't respect me 5. He asks me to read stupid things
Rely on conversation instead of on telling people what to do
Use MBWA approach (managing by walking around)
Finish each meeting with steps and responsibility
To solve the team conflict: 1. Find point of agreement 2. Do not focus on personalities 3. Use arguments and persuasion
While examples and anecdotes are frighteningly outdated, general ideas of the book are undoubtedly actual. Same as they were in pre-software development era and they would be in post-AI world of total automation. As a manager you would need to translate ideas of value brining solutions in terms of requirements, scope, work to be done overcoming obstacles of interhuman (interagent) communications full of assumptions, cultural and behavioural differences, simply state of mood. Versus strict boundaries of budget and time in ever changing project context.
Kopumā vērtīga rokasgrāmata gan projektu, gan vispārējā vadībā. Konkrētā situācijā var atšķirt konkrētu nodaļu kādam noderīgam padomam. Taču it īpaši pēdējo divu gadu kontekstā grāmata šķiet novecojusi. Daudz atsauces uz fizisko formātu (tāfeles, privātie ofisi, klātienes sapulce un komunikācija), kas mūsdienās kļūst mazāk aktuāli. Tāpat arī daudzas atsauces ir uz deviņdesmitajiem vai pat senākiem laikiem, kas tomēr ir attāls laiks, skatoties no mūsdienām. Bet būs situācijas, kur šī grāmata varētu noderēt profesionālajās gaitās.
Great book if you are getting started on product management, especially in software. It can get a bit dry at times, but the author does his best to make it interesting and explains at length the different phases of a product or feature development from inception to release, and gives good information on decision-making, leading teams and negotiating too, all while providing useful references to dive deeper. I was able to apply his advice on decision-making, vision documents, specs and schedules almost immediately.
"Making Things Happen" is an insightful read that delivers a practical approach to project management. Scott Berkun brilliantly demystifies complex concepts with real-world examples and actionable advice. The book offers a perfect balance of theory and practice, providing comprehensive strategies for decision-making, leadership, and team dynamics. Although it is tech-centered, the principles are universally applicable. Highly recommended for both novice and experienced project managers seeking effective, hands-on guidance.
A true classic in PM - even though I coordinated some projects already, I learned a lot by reading this one on strategizing, planning, leadership and employee happiness. It has some great tips and tricks, even if some of it is a bit straightforward. Though the examples come from IT, they apply to a broad range of sectors. This is must read for everyone who wants to get things done and plan better in any business!