Below are some of my key takeaways from reading the book, Making Things Happen by Scott Berkun. If you are interested in more detailed notes from this book, they are available here.
Summary:
A brief synopsis of the book is reprinted below from Amazon.
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.
Insights:
Role of the PM
The books starts with a high level, and historical overview of project management. The author points out that humans have been engineering throughout the history of human civilization. While the technologies and skills may have changed since the development of the pyramids, many of the core challenges that make engineering difficult exist in projects today, even in the modern age of software development.
Through this lens, the author points out that most projects have strong similarities including requirements and designs as well as constraints like a budget or schedule. The purpose of a project is to, “combine the works of different people into a singular, coherent whole that will be useful to people or customers.” At the end of the day, there are always three things: a goal, a pile of work, and a bunch of people.
From this fundamental definition of a project, we can determine the role of the person responsible for managing a project. According to the author, “project management is about using any means necessary to increase the probability and speed of positive outcomes.” I liked this definition for a few reasons. It captures the fluid nature of project management. The role is different at every company and even within a company, the role can evolve over time as the company matures. It also captures the notion that not every project will be successful, but the PM should be constantly working to get the team to reach the goal.
Ultimately, the PM doesn’t build anything, the team does. The PM is there to amplify the value of everyone on the team, making the project and anyone who contributes to it as successful as possible. The author describes this challenge by pointing out, “you have to invest in relationships with people, regardless of how much they’re investing in you.” Project managers are only as good as their relationships with the people on the team.
While the PM might not be directly responsible for executing the tasks required of the project, they do bring a wider perspective than the individual members of the team. I thought this was a really valuable insight that I hadn’t considered before. This is especially useful when helping team members prioritize work and understand how their work fits into the broader project. Beyond providing clarity around goals, roles, and execution plans, the PM can provide context to help team members understand the impact of their work and maybe even find it more meaningful. These are import dynamics for any effective team.
Don’t confuse the process with the goals
Some people associated Project Management with rigid structure and overly burdensome processes. Software development methodologies such as Agile were intended to enable rapid iteration and releases by empowered teams but implementation processes like the Scaled Agile Framework seem to impose structure counter to those philosophical principles.
Sometimes we get wrapped up in the process and forget that our job is to increased the probability and speed of success of the team and the project. Our planning techniques and tools to track process are meant to support the team, not inhibit them.
The author defines a process as, “any repeatable set of actions a team decides to perform on a regular basis to make sure something is done in a certain way.” At a basic level, a process is just meant to organize how people work and how they interact. These are very organic things and the develop naturally as a team collaborates. This means that processes exist, regardless of if they are documented and formally communicated.
This is important to remember when the team decides to improve some part of their existing process. It’s also important to remember that people design processes. If we have the right goals in mind when iterating on a process, it’s possible to make improvements that benefit the group. The author defines the following attributes of a good process:
- They accelerate progress
- The prevent problems
- They make important actions visible and measurable
- They include a process for changing or eliminating the process
- People impacted by them are in favor of them
I typically use a fairly frequent cadence of goal setting and retrospectives to trigger the process improvement process. Having the team reflect on shortcomings and brainstorm ways to mitigate these issues in the future helps develop the buy-in that’s required for any process to be successful. I’ve also found it helpful to encourage individual team members to propose changes to the group themselves. Not everyone feels the pain of a gap in process equally and it’s helpful for people directly impacted to propose adjustments for the group to consider and adopt.
Either way, these attributes are a good litmus tests to judge any proposed changes to make sure the process is enabling the team, not inhibiting them.
Having clear priorities is the backbone of progress
One of the core values a PM can provide to the team is context. While individual team members typically have significant depth in their domain of expertise, the PM typically have a broad perspective of how the team’s work fits into the goals of the rest of the organization.
The PM can provide this context formally, through goals or schedules. It can also be informal, by providing updates on the work of adjacent teams that may impact the progress of the project.
According to the author, most projects have three important formal lists: goals, features, and work items. To me, these are documented in Objectives and Key Results (goals), roadmaps or schedules (features), and the backlog (work items). I thought this was a good way to think about capturing the context for the team and making sure all three levels are continually refined and clearly communicated to the team.
The book also talks about using these lists in conversations with the team. The PM can use these lists to help team leads or team members prioritize their work and see how it aligns with the work of others. These lists can also be used to anchor disagreements and decisions. If the priorities are well understood and respected, they can be used to frame the discussion, enable people to focus, and ultimately resolve the issue at hand.
Schedules serve several different purposes, only some of which are focused on measuring the use of time
One of the common elements of any project is the schedule. Schedules serve three purposes:
- Make commitments about when things will be done
- Encourage everyone to see their efforts as part of a whole
- Provide a tool to track progress and break work into manageable chunks
I think we often focus on the last one but not the first two. It’s important to have a collaborative approach when developing the schedule to maximize the buy-in described in #1. It’s also important to make sure that the schedule is clearly communicated and regularly visible to everyone. As the PM, I interact with the schedule every day but I need to make sure that the rest of the team can view it as well, especially as team sizes grow and it’s not possible for the entire team to be present in the same meeting or communication channel.
Fundamentally, the schedule is comprised of a set of estimates. People are historically pretty poor at accurately estimating the time a task or project will take despite the various frameworks developed to support estimation. To improve the quality of estimates, the author states that “good estimates only come from credible designs and requirements.”
Sometimes, people will even refuse to attempt to estimate a task. When that happens, the author asks, “What questions can I answer that would make you more confident about giving an estimate?” I found this to be a helpful follow-up question to better understand the challenges the person had in developing an estimate. We could then work together to try and resolve some of these outstanding questions to create or improve the quality of the estimate.
Maybe the problem isn’t the estimate themselves, it’s how they are used. Daniel Kahneman and Amos Tversky coined the phrase “planning fallacy” to describe the tendency for people to display an optimism bias and underestimate the time needed to complete a future task. They state that planners should use a form of Baye’s rule to account for this fallacy. Planners should look at the timelines associated with similar cases and use that as a “base rate” estimation of the time the current project will take. The team can then adjust the timeline from the base rate based on the unique aspects of the current project.
The author recommends a similar approach. He states that estimates should be based on previous performance and the team should establish baseline confidence intervals for estimates. This leads to the idea that estimates aren’t discrete items, they are really a probability distribution of possible outcomes. The schedule is a set of probabilities and it should be used in that manner. A straightforward addition of individual estimates will almost always lead to a grossly incorrect estimation of overall time since estimates are based on probabilities and probabilities do not combine additively. This leads to a set of probabilistic modeling techniques that can handle events that are described by probability distributions like Monte Carlo simulations. For more information, check out Joel Spolsky’s article, “Evidence Based Scheduling.”
Prototyping for projects without UIs
Sometimes I’ve found myself in circular arguments with an engineer when it comes to writing a design document. This usually occurs when tackling a project that doesn’t directly impact the user like implementing a new systems architecture for some backend infrastructure. I’ll ask the Engineer for a rough timeline for the project and the amount of time and resources required. They will respond that they need to write some code before they know what the design will be so they can’t make any estimates. I will comment that we can still outline the contours of a plan before we dive into coding and we go back and forth.
When working on user facing features, I usually work with the design team (and relevant engineers) to craft the requirements, then develop and test a series of prototypes before transitioning the idea fully to the engineering team. The author shows that this process of prototyping can, and should, apply to projects without a UI as well.
The goal of the prototyping is to understand whether the ideas we have actually solve a real problem and can be completed with the resources provided. The same principles should apply to internally facing projects as well.
Just like there is no way for a designer to confidently answer complex design questions without a design prototype, there is no way for an engineer to confidently answer complex engineering questions without an engineering prototype
Engineers should pick the most difficult or complex technical challenges in the project and prototype them. Engineering prototypes can be at different levels of fidelity just like more traditional UI prototypes.
This understanding helped me better approach systems design projects. We can identify the technical risks at the beginning of the project and allocate time specifically for the development of prototypes to explore and de-risk those challenges.