Slow Project Management

We all want to go fast. But sometimes we need to fundamentally change the way we approach solving a problem to actually go fast. And our counter intuitive (state of the art) project management does exactly that. And no, it's not SCRUM.

Our society doesn't like to do anything slowly. "Slow" is usually not good. If you say a movie is slow, you mean it's boring. Or call somebody else slow and you actually mean they are stupid. The restaurant service is slow? That's code for lousy.

So surely I am not advocating for a project management style that's boring, stupid, or lousy. Certainly not. And I would argue that our project management system is exciting, smart, and world class. But our system feels slow because it's methodical and disciplined.

This isn't a new idea:

"Dress me slowly, I'm in a hurry"
- Napoléon Bonaparte

However, it's also structurally different from Fast Project Management. But before I elaborate on our process let me explain what a Fast Project Management approach looks like.

The Fast method is how we build houses. This method starts with planning, lots and lots of planning. You have architectural drawings, then blueprints, engineering details, electrical diagrams, etc. All those plans get handed off to the people moving dirt, followed by those putting in the foundation, then framing, etc, etc. Each trade works on top of what the last trade did. Because the work from one group flows down to the next we usually call this Fast approach Waterfall.

Fast does work. At least for very small houses and very small software systems. It doesn't take much of a house before the bank will require you to qualify for 20% more than the quoted price to account for overrun. Which is odd because we've been building houses for a really long time. You would think we have this figured out by now.

But you WILL have overrun. Any problems upstream cause more problems down stream. And we all know that no plan survives first contact with the enemy.

On top of that, at each stage we are trying to go as fast as possible because there's always someone waiting on us. Even if steps take a long time, there's always a rush to complete the step. We have the illusion of speed until that illusion crumbles and we see how slow we're actually going.

It turns out we have the same problem with software. And the overrun can be insane. Sometimes 100% or more of the original budget. Not to mention the delivery delays.

There's an alternative approach for software development called "Agile". Agile is a terrible name because it doesn't describe how the project management works, it just describes a quality that we are trying to achieve. But Agile is structurally different and that difference is the key.

So here is how we do our Slow Project Management.

Expectations

Our project management requires a few prerequisites from our customers to work correctly. So we first set some expectations.

1) Dedicated time

• Our team dedicates time to talking with you and keeping you updated as we go. You or someone from your team also needs to have dedicated time. We do not want to rush through or miss talking through important details with you.
• This is different from the Fast method because you need to have this time set aside during the entire course of the project, not just some magical planning phase at the start of your project.

2) Your Involvement

• Software is similar to having a custom suit tailored. Tailors take YOUR measurements, personal taste, and current fashion trends into account. If you don't come by to have your measurements taken the end result will not be great. Same with software: we need you to be involved so that the final product is just what you wanted.
• Review: you need to actually review the software that we send you. That means clicking links, adding data, generating PDFs, etc. We want you to actively try the software within 3 days of us sending it to you. (We will send you all the links to click, but you have to actually click them.)
• Training: we have weekly review meetings which includes training. You will be trained on the software as we build, not just at the end. You need to be ready to receive that training as we go.

Adaptive life cycle

We have a collection of project management practices that we employ that are commonly referred to as "adaptive life cycle" project management. The idea is that we plan some, design, build, test, review, and launch. Then we repeat that all over again. So our slow method doesn't try to plan everything upfront like the fast method. We only plan what can be built in a reasonable amount of time (no more than 100 days, but usually only 14 days).

No Project Managers

At BoltAffect we do not have dedicated project managers. In fact, we don't have project managers at all. We have Principal Engineers that oversee your project and communicate with you. Your Principal Engineer will likely write a good deal of the software for your project (depending on its size). This means that project management is embedded directly into engineering.

This also gives us the highest level of collaboration and feedback loops with you. And that's what we're going for. Instead of the Waterfall style handoffs we are replacing that with collaboration.

Of course we want the engineer to be doing engineering, not sending meeting invites. So we also have Project Coordinators that work with the Principal Engineer to get all the administrative tasks completed. This keeps the engineer from being task saturated.

100 Day Roadmaps

Even for big projects we only work on a maximum of 100 days at a time. We do not have crystal balls to see into the future. So planning too far into the future is just waste since those plans will inevitably change.

Also the weight of a task list that's 10 years long is not helpful. We like short task lists that can have continuous movement with rapid testing by your fine selves. This also promotes a focus on delivering the highest value features first.

Inspection, Inspection, Inspection

We regularly review with you how the project is going and where we are seeing any overruns. We write tests to verify the software, but we additionally prioritize fixing any bugs discovered. We use automated systems to log Quality Escapements (including detailed crash reports) and we regularly review this with you.

We can either look to blame someone, or just make it right. Making it right is what we do.

Slow Construction Projects?

So we started by talking about houses. If this works for software, why not actual construction projects?

The January 2020 issue of PM Network includes a case study for one of the 2019 PMI Project of the Year finalists: the Société de transport de Montréal’s (STM) eight-year project to modernize the underground Montréal rail system.

Their project was completed on time with only 1% overrun.

The case study highlights a number of practices which were used by the team that would normally be associated with projects following an agile or adaptive life cycle. This includes close collaboration and short feedback loops with customers, building a “whole” team representing all disciplines, performing operator training in parallel with build activities to streamline transition, and encouraging learning from failures rather than hunting for scapegoats.

So yeah, it works for construction also. The industry is just so entrenched in going Fast that it's hard to switch.