Review: Project Management for the Unofficial Project Manager

• Career
• Project Management

Software development projects are notorious for having problems. Late, over budget, not working properly, making people's lives miserable all around. Embedded systems add the further complication of hardware to that.

How many of us have lived through problematic projects? Hopefully some of them have at least been ultimately successful to make all the suffering worth it in the end, but there are plenty that haven't.

I don't consider myself a project manager, or a manager of any type. I'm an engineer. But the premise of Project Management for The Unofficial Project Manager, by Kory Kogon, Suzette Blakemore, and James Wood is that frequently non-management employees are put in the role of coordinating and managing projects. Meanwhile, they have no formal training in project management. Hence the "unofficial project manager" (which I'll call UPM).

I read this book purely in the interest of self-preservation. I've been in some form of that situation a few times, and I've often felt the need to participate more knowledgeably in project management. Rather than be a victim of the process, I prefer to take a more proactive role.

Part of it is just the natural progression of advancing in seniority level, even when working as an individual contributor. That means more responsibility and more influence over the projects and the teams. At the level of principal engineer, I'm expected to lead to some extent, not merely to participate. I'd like to be competent at that rather than just winging it.

Over the past two years, I've read John Doerr's Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs (Objectives and Key Results), Daniel Coyle's The Culture Code: The Secrets of Highly Successful Groups, Jocko Willink and Leif Babin's The Dichotomy of Leadership: Balancing the Challenges of Extreme Ownership to Lead and Win, and some of Angela Duckworth's Grit: The Power of Passion and Perseverance.

Those have all had good lessons to convey. But what they lacked for me was actionable practical procedures. OKR's offer some of that, but are too high level. I'm always looking to add discipline to the engineering process rather than live in the wild West, so I want how-to knowledge. To me, that's the defense against the chaos and misery of a project run amuck.

I address some of that in my Review: Clean Agile, by Robert C. Martin, and More Effective Agile, by Steve McConnell, which includes my critical reading list of four books for anyone directly or indirectly involved with software development.

There's a whole formal study of project management, and some projects I've been on have followed those tenets to one degree or another. So this week I ordered A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide–Sixth Edition / Agile Practice Guide Bundle, produced by the Project Management Institute (PMI).

There's also a PMI certification process, with Project Management Professional (PMP) described as the gold standard, but that's not what I'm interested in. I'm interested in the BOK (Body Of Knowledge). That's what I need, knowledge!

This book, Project Management for the UPM (which I'll call PMUPM), came up as a recommendation alongside the PMBOK. After a brief assessment of the information on it I ordered it as well, since it seemed applicable to my interests.

I'm glad I did. I've just flipped briefly through the PMBOK so far, but I read PMUPM cover to cover today. A few pages into it I realized this is what I need.

To some extent, PMUPM cherry-picks the PMBOK. I don't know how PMI and certified PMP's feel about that, but for those of us in the trenches, that's great. PMUPM is very readable, and offers a set of lightweight, practical procedures.

It uses a set of small workplace projects as examples. Your first objection might be that those are much different from larger, more complex embedded systems projects. The authors make the argument that the methods apply all up and down the scale of projects, from those budgeted at hundreds of dollars to those budgeted at tens of millions.

Clearly one would hope that those bigger projects have certified professionals involved, but I think it's incumbent upon us as disciplined engineering professionals to participate intelligently no matter what. And sometimes we need to do a little "managing from below."

One of the central tenets of the book is that people are really the thing to focus on. This is consistent with DeMarco and Lister's Peopleware: Productive Projects and Teams. One of the section headings in the first chapter is "Manage Projects, Lead People," quoted from Stephen R. Covey. I really like that. They expand on that in chapter 2: "People + Process = Success."

That leads to the Four Foundational Behaviors:

1. Demonstrate respect
2. Listen first
3. Clarify expectations
4. Practice accountability

The authors apply these repeatedly throughout the book. The behaviors form a virtuous cycle that is a useful tool in all kinds of situations.

They also talk about empathy. Yeah, some of that squishy stuff that engineers supposedly avoid. But it's important, because people get things done, not process. For another engineer's perspective on that, see my former coworker Chris Svec's excellent presentation, Empathy Driven Development.

Next are the Five Process Groups from the PMBOK:

1. Initiate
2. Plan
3. Execute
4. Monitor and Control
5. Close

The remaining chapters elaborate on these, providing specific tools to carry out the process steps.

One of the things to keep in mind is the famous Iron Triangle, formerly three constraints, scope, cost, and time, now six constraints:

1. Scope
2. Quality
3. Resources
4. Budget
5. Risk
6. Time

You might start getting concerned about overly process-heavy waterfall development, or wonder if this has any place in Agile shops. I believe it's applicable no matter what. It's lightweight, but the key is that it requires you to think and pay attention.

Lack of forethought, lack of planning, and lack of communication among all the parties involved are the real project-killers. Thinking things through, planning steps to take, and making information available and communicating back and forth, not just at the beginning but all along the way as you monitor, control, and adapt, are critical for success.

That includes risk management and updating for changing conditions. Conditions will always change. If nothing else, the progress of the project is a changing condition. But there will also be problems that arise, new requirements, scope changes, and personnel changes. Remember that no plan survives contact with reality, so you need to be able to handle that.

The tools in PMUPM address all of those. Write stuff down! The tools provide a simple, lightweight structure for doing that. You don't need voluminous tomes, but you need more than zero. The act of writing stuff down forces you to think and plan.

Then you have something to share with others and get feedback, so you can communicate back and forth to refine and update as necessary. That gives you something to monitor and control against, as well as leave for future projects to learn from. It also gives you something to help onboard new team members rapidly.

My overall impression is that PMUPM offers a very practical, manageable process for project management. It provides just enough formality to help bring order from chaos. The proof will be in the pudding when I try it out, and I'm sure it will take me a while to get the full benefits. But I do believe it will be beneficial.

Sign in