Boil it down: running a project

What comes to mind when you hear or read the term Project Management?

• Spreadsheets and timelines?
• Story points and estimates?
• Airtable, JIRA, burndown charts?
• Busy work? Large meetings where people are “held accountable” for dates and treated like a child if there are problems?

After working in tech for a while, it’s easy for this to become your “normal”, and that sucks. I’ve noticed myself getting lost in these implementation details and the frustrations that follow. I lost touch on the purpose of project management, and wanted to clarify my thoughts on it.

To be honest, when you boil it down, nailing project management basics gives you superpowers.

Table of contents

Project Management? Risk Management

I want to achieve an outcome and I need to spend some resources to do that - money, time, political capital, whatever. Projects are complex, and achieving them doesn’t come for free. There is naturally RISK in the value trade-off between what I spend and what I get back for it.

This is a small subset of the risks I’ve encountered in tech projects:

• misalignment on the purpose
  • “I thought this was to …”
• misunderstanding of why that purpose is important
  • “I thought this contributed to the company goal of …”
• misalignment on what is not the purpose
  • “I didn’t realise this wasn’t including …”
• assumptions of scope
  • “Oh, this doesn’t do X? I thought it would enable Y?”
• assumptions of approach
  • “I thought this would use/be integrated with …”
• assumptions of future direction and what this project will unlock next
  • “I thought this would later unlock …”
• … you get the idea

I suspect the fear of this list leads to the overused systems and forgetting the core concepts. Add a layer or tool, get more benefit - right?

Ultimately that’s a distraction and leads to less valuable action and more nonsense. Instead I want to focus on the core concepts, communicate purpose and intention, execute transparently, while bringing everyone with me.

Pulling out a few common themes:

Nail the purpose

Early in a project, you need to be able to clearly answer: why is this worth the time / effort / cost?

Communicate it really clearly and concisely, and then over-communicate, in that order. Don’t over-communicate something that’s long and winding, and don’t try to re-invent the explanation and purpose each time you’re telling it. Sticking to the script keeps things consistent, removes ambiguity and confusion that will build up.

It’s also good to explain what the purpose is NOT. Knowing what’s out of scope can help drive home what’s in scope, and areas to save time now because you’ll be tackling them later.

This phase needs to stick to business and customer problems. No implementation details just now, at all. If you’re describing any implementation details in this phase, you’re closing off the solution space early and solving it alone, and likely badly. Set the stage first and foremost.

Scope

This needs to come after purpose and business and customer value, since it’s derived from that. I’ve been tempted to continually nudge this larger and larger because I’ve been excited about what could come next. That’s the wrong move and will delay getting any value out the door and any part of the project validated in the real world.

Keep scope tight, keep it clear and keep it visible throughout. This is important for stakeholders to understand what they’re getting, and for your engineers to ensure they are working on the most relevant aspect of the problem space that needs solved.

Approach

This is where Staff and Senior Engineers shine. Are there current approaches to solve the problem, either locally in the company or in the industry you operate within? What opportunities are there to solve this in a novel way, that better solves the core problems and will pay itself off in dividends down the road?

Once the purpose has been nailed down concisely, communicated broadly, and generating hype without confusion - dig into the details with your engineers.

Bringing it all together: one approach (of many)

After slagging off the implementation details of planning and running a project, I do actually want to get more concrete details out of my head on this. Don’t take this as prescribed, and please don’t follow word for word. This is one possible way of distilling the above topics into something actionable.

Define purpose and value-prop

A light-weight Product Requirements Document (PRD) can achieve this. Ideally it would flow through the current state, the problem and how we know it’s a problem, the value of changing that, signals that it has been solved, and a possible sequence of how the problem be broken down and solved in smaller stages (optional).

Not to bang on about it, but the best examples of this are tight, concise and not filled with jargon. And seriously, try hard to not solve in this phase. It’s so tempting because you’re immersed in it and constantly reading why it should be solved. All it really achieves is limiting other solvers.

Share it wide to keep a feedback channel open.

Explore the problem space, together

Get together with stakeholders, team members and subject matter experts to explore the problem space. This is where I can get more concrete on details, like what is lacking and where, how a user might flow through the product to solve their problem. It can also highlight some really juicy Nice To Haves, and you will be very tempted to include them in scope; don’t. Find a parking spot area to store them and keep them visible for future you.

Find the right artifact to consolidate learnings and get it out there. Continue keeping that feedback channel wide open.

Do a breadth-first-search/hackweek to evaluate your solutions

Sometimes I go through the above 2 steps and still feel uncertain about approach or best next steps. There be too many options and I don’t have ways to differentiate between them.

In that case, I’ve found value in fast validation by engaging your engineers to spike the issue - something like a hackweek. Split into small groups to evaluate different options by building messy proof-of-concept code that outlines the solution in the cheapest possible way. I can really dig into how well a solution solves the problem, when I have something to work through.

It can be costly, so keep it timeboxed. Engage with senior engineers to lead each spike (or engineers looking to grow), then collaboratively evaluate and discuss fit-for-purpose.

It’s not about “winning” or “being right”; it’s about gathering more evidence to find the best next step. Keep that visible and in the minds of engineers to avoid them feeling too attached to their possible solution vs. others’.

Demo all or just the most right-fit solution to product people and stakeholders. Keep them engaged, and keep that line of communication for feedback wide open (see a pattern here?)

Align on and share the solution

By now, the team and I understand the problem space well and have explored options for solving. We’re aligned on the likeliest best solution to invest in further.

Let’s write it up! Maybe it’s a Technical Design Document (TDD) or an Request For Comment (RFC), or some other artifact. Either way, it’s a place to link back to the original purpose doc and at a high level, outline the solution for sovling it. Keep value/effort in mind - API specs here might be useful for a public-facing API, unlikely useful as internal implementation detail. Diagrams are also good, and can later be re-used in dev docs.

Share it for others to see and weigh in on, (all together now) keeping that feedback channel wide open.

By now I’ve enabled the team to do due diligence and we’ve mitigated risk enough to not warrant more governance (YMMV, and as always, “it depends”).

Decompose into Thin Slices

I want to write more on the topic of Thin Slices because it’s a cracker and a super valuable mindset. But the TL;DR is: find ways to decompose the project into meaningful parts, each of which works end-to-end. Don’t perfect one layer and move to the next; aim for an end-to-end working (and very very dumb/naive/limited) solution as early as possible, then bulk out by use-case/user story.

At this stage, I find groups of slices that can be combined into milestones for tracking progress later.

At this point, I have a single view outlining the work required to achieve the outcome. If your team/company does estimates, now is a good time to generate those random numbers (jk …).

Deliver the heckin thing

Get stuck in. Pair programming, TDD, continuous delivery behind feature flags - all the good things to achieve high-quality work with confidence while minimising risk. By chunking the work into thin slices and utilising best practices, the team should almost always have a working end-to-end solution throughout development too. Keep demoing progress, keep those communication channels wide open.

Instrumenting the solution with the right metrics, you set yourself up for success in determining the projects success in delivering the intended outcome.

Are we done…?

Check the numbers, gather feedback from customers, share it widely, revisit on a regular cadence. Is this achieving the intended outcome? Answer that question with the data, while asking “is this still the same problem to be solving now?”.

Reflect, refine, repeat.

That was longer than I was hoping, but very satisfying to get out of my head. There are good arguments to made that the outlined approach is too rigid, not agile enough, or not rigid enough. None are right or wrong. It’s just one way of trying to achieve the goals at hand. If I do it that same way every single time, I’ve failed. The real magic is in reflecting and refining the process, and determining if it’s solving the core problem at hand - de-risking and delivering value. Bit meta, that.