In chapter 2 of Ben’s book, Program Management for Open Source Projects, we are covering project management - the Munchlax to program management’s Snorlax.[1] As Ben describes, “many aspects of program management are the same as in project management but zoomed out. So when you understand project management, program management makes more sense.” Projects differ from programs in that they tend to be smaller in scope and are temporary, but both involve the management of tradeoffs between inversely related factors and similar superstructures to keep the effort moving in the right direction.
The Iron Quadrilateral
First takeaway was the reminder about tradeoffs. I’ve been a big fan of keeping those in mind when it comes to finding solutions to problems. When tradeoffs go unacknowledged, they often catch us by surprise later, and those consequences cause us to direct our frustration at something or someone else.
For example, if you want healthy food, you probably have to put more effort into your diet. If you don’t want to put in that effort, there is easier food to get, but it’s going to be unhealthy. You need to get over your resistance to the work involved in eating healthy if that’s your goal and find solutions to compensate for that struggle rather than complaining that eating healthy is hard. That or pick your battles and buy McDonald’s.
In a project management context, Ben outlines the four factors in a project that you need in order to get it over the finish line: scope, time, cost, and quality. They are also competing with each other for priority over the project where usually one of them will be hard to adjust. Time may be set by a deadline you have to meet. Scope can fluctuate based on input from different stakeholders. All of these can put a strain on the others, and your job is to optimize this tension for your goal.
Just grabbing this framework in the broadest sense is helpful. Whereas I normally can be zoomed into the details of the specific problems I’m trying to solve, this model shows what are most likely the elemental forms of the factors I’m trying to consider.
Those who cannot do, prepare[3]
Second takeaway is actually an encouragement for what I’m trying to do in reading this book. Lots of us have to manage projects in different forms, but in some ways it’s like taking a test that has the answers online. Other people have figured out what you should be doing in order to get the project done. That’s true in a high level wisdom sense, but also when it comes to the nitty gritty details.
The method I have learned to deal with projects has been primarily iterative. I identify a problem or goal and throw my mind or effort at it. With each attempt my meta goal is not to slowly approach the target, but to slowly build the system and workflow that reliably funnels me toward the goal. It’s worked for me for over a decade, so I don’t think that will go away.
From this perspective, the idea of trying to do a project charter, project plan, Gantt chart, RACI chart, and so on sounds ludicrous! What’s the point of spending all that time detailing a plan of action that you’re going to change in a week or at the drop of a hat? I know that Ben isn’t advocating for all that detail for all types of projects, but the sentiment still seemed exaggerated to me.
But these are the answers to the test. The idea of these documents are solutions to the problems project managers have been running into since this has become a formal discipline. Each document does a job. What are the jobs these tools are filling? Do I remember that these jobs have to be done in one form or another for a smooth experience?
For instance, the decision log stood out to me. Up to now most of my projects have been primarily on my own, but now I’m in a job in which we’re making many decisions on small actions to take. I knew they had to be recorded in order to be actionable and manageable, but here is the language for the thing. I can now look up more for examples and maybe find the inspiration for the version that fits the work I need to manage.
This book club exercise is my excuse to learn the language of a whole world of tools, systems, workflows, and structures for getting work done. When the challenge of the project seems daunting, at least I know I can think my way through the path, and these tools will help me clear the way faster.
