This idea came to my mind the other day: project management is security engineering. I’ve done both, one way or the other, and I started to see the similarities.

One thing that I’ve done quite a bit of lately is reframing problems. A lot of the time solving a problem is not about solving the problem but rather reframing it to a solvable alternative.

This is not a new and original thing; I dived somewhat deep into this idea when I went through NP complete problems and how to prove a problem has such characteristics by finding how it fits a known problem back when I was studying for my degree.

Security engineering cares about securing something. It’s never about making something unbreakable; it’s always about raising the bar for breakage.

Project management cares about delivering a project. It’s never about making it impossible for a project to not be delivered; it’s about raising the bar for the likelihood of a deadline slipping.

Security engineering deals with a threat model. You draw a line to define the set of threats you want to protect from.

Project management deals with scope. You draw a line to define what set of features/bug fixes/requirements/etc a project will have.

It’s all about process

Well, sure, it’s not all about process. You need smart and capable developers or security engineers.

But the best people in the world without any organization is not going to accomplish a lot in many situations. You’ll have a lot of hair on fire.

You also might not have the best engineers, since the best that I know are the most methodical workers I’ve ever met.

You might not have the best management if you have the best engineers but they don’t have a good environment for speaking up or making changes.

And even if you have the best of both, in most situations you need mediation, and that’s when process shines.

I like to describe process in project management as a house you build around development. When it rains from the business side, you might have a leak in the roof, but you’re going to get a lot less wet than if you had no house at all.

In security engineering, process can be seen in a similar way, just around code and data. You want to make sure you keep important data inside, only let data go through the proper doors. And you want to keep threats out.

The different stages you define in the process let you focus on smaller scopes. The smaller the scope, the easier it is to not drop the ball on something. Standards for code structure, or patterns, help you catch low hanging fruit easily (hopefully in an automated way).

On how a lot of people see both of them

Funnily enough, in many many many organizations, security is seen similarly to project management: that thing that is super annoying and pushes us away from actually solving the real problems we’ve got in front of us.

While in reality, doing things a bit slower at first because of the added overhead of process will give you faster results in the long term.

Security in a lot of places is a “thing you add at the end”. You focus on building your product, then remember it’s being served over HTTP and say “OK, let’s just add the S at the end of HTTP”. And for a lot of things, this works, when you know you’re adding a security protection in a specific way, so you can ignore it for now and add it later. But when it comes to designing systems, there are core ideas that need to be architected with security in mind.

In project management, a lot of things are seen in this way. Take the simple task of updating tickets. A lot of developers (including myself many years ago) see this as an annoying time consuming task that drives you away from actually doing what you have to do: coding. So you push these tasks to the very end, and do them without really paying attention when you could instead be using them as tools to define and clarify the work that needs done. Another example is planning, specifying a system, a lot people feel like the sooner they dive into coding the sooner they’ll be done with it, we can talk about how the project is going in a month when I have something.

That is not how it works, in both security engineering and project management, it needs to be an intertwined thing with development.

You need a framework to work on, that’s your process.

Process is about safety nets.

It’s about catching security issues before code reaches production.

It’s about having enough data to have reasonable conversations about why adding that feature is not possible in the time frame specified.

It’s about having enough hard data when trying to answer “is X being productive?”

Sadly not a lot of people see it this way.

Tool set

80% of problem solving is having the right tool set to approach a problem, 20% is specificity. An important part of this tool set is being able to abstract experiences and reapply them.

Another super important part of it that I keep coming back to over and over is: it’s about asking the right questions, to yourself or to others.

Finding similarities like the one discussed here gives you more tools for this, what questions would you ask when securing a system? Can you find an equivalent question to ask about project management? How about the other way around?

In both cases it’s about managing risk, source code and computers or tasks and people is the specificity portion of this.