Unidentified Flying Project

It's hard to make things happen.

In any endeavour involving more than a few people, there are all sorts of constraints and complications that make it challenging to achieve a meaningful outcome.

This post isn't about how to deal with all of that.

This post is about the very first step in the process.

Naming the thing you're trying to do.

Gender Bender

If you can't describe the thing that you're trying to get a bunch of people to execute on, then you're in dangerous waters.

I don't mean that you have to perfectly understand every aspect and nuance though. That would be insanity.

Instead, what I mean is that you need to give the thing a clear and unambiguous identity. Something that you can reference from that point forward and use to build a set of associations. A pointer to where the real information lies.

I'm talking about defining a project.

By defining a piece of work as a project you make something that can be referred to easily, which is critically important if you need to engage with a bunch of people around it. It doesn't matter if they are directly contributing, affected by the outcomes or just interested in its existence, every stakeholder benefits from a clear identity.

Having a well-defined project also makes it easier to carve out a space, both digitally and mentally, around the work, which in turn makes it easier to deal with.

But how do you define a project well?

Shapes

To me, a good project consists of four elements.

The first element is a clear description of the problem or opportunity. This doesn't have to be an essay, it just needs to be enough to establish the motivation for the project. It's reason for existing.

Something like:

The current salary review and adjustment process is opaque and difficult to reason about. Employees do not understand how expectations are being set and what the process is in order to decide how salaries will be adjusted on a yearly basis.

The second element , which often overlaps with the first, is a clear definition of the impact or benefits. This helps to clarify the problem or opportunity, allowing someone to understand why the project should be embarked upon and what everyone stands to gain.

Something like:

As a result of the above, employees do not feel recognised, which in turn leads to an increase in dissatisfaction, low motivation and morale and at the end of the day, an increased chance that they will leave for a better opportunity elsewhere.

The third element, again, building right on top of the first two, is the success criteria. I've already written about this topic at length, but for the sake of completeness, success criteria are measures or metrics that will tell you when the project is complete. They should be based directly off the impact/benefit, but may also represent internal measures of progress while the project is being executed.

For example:

The number of employees who resign, stating dissatisfaction with their current salary or the salary review process, trends from ~3 to <= 1 per quarter for a sustained 4 quarters

Employee satisfaction with the salary review process trends from 23% to >= 75% sustained over a period of 2 quarters

Finally, you have the most important element of all. The one that you should spend a significant amount of time on, because once it's set, it's incredibly hard to change.

The name itself.

Using the example project above, a good name might be:

Less Sadness About Salary Reviews

Why is the name the most important you might ask? Apart from a significant chunk of facetiousness on my part, the name is the key to the whole thing, in the sense that it unlocks additional information and points any stakeholders in the right direction.

Personally, I like to make them memorable and a little bit fun, because otherwise why bother?

Squeeze

Obviously, establishing a clear identity for a project is not easy.

You have to understand it enough to draw some lines around it, bounding the workspace, while also being careful not to constrain things too much right at the start.

A classic mistake is to describe the work in terms of the solution.

This is by far the easiest mistake to make, as once you start talking about everything in terms of what you're going to do, you lose sight of the overarching context (the why), and you make it far more difficult to determine if you're done yet because there is no clarity about the value that is being delivered.

If you think that you, or the people you're working with, are focusing too much on the solution itself instead of the problem or opportunity, you need to take a step back and re-evaluate.

The second thing to keep in mind, which is less of a mistake and more of a general challenge, is that it's hard to get people to spend time defining the project.

A lot of people just want to do. To them, all of the things I've just described about establishing a clear identity feel like a distraction from the doing.

It's not, of course, because it helps to put everything into context, but it can be difficult to convince people of that, especially when they are focused on the implementation part. It doesn't mean they are wrong or doing a bad job or anything, it just means they value different things.

The only way I've found to deal with this is to be persistent and show the value of having a clearly defined problem space whenever you can. Concrete opportunities include things like demonstrations to more senior people in your organisation (i.e. disconnected but still interested stakeholders), annual reviews and evidence gathering for promotion purposes.

The last thing I've run into is that sometimes you draw some boundaries and identify a project, but things shift and mutate. That's completely normal, though very disruptive.

That's the nature of the game and the only thing you can do is accept it and move on. Be flexible, because if you're too rigid about the whole thing you're not going to be delivering as much value as you could be.

Shadows

Successfully executing a chunky piece of work is a far bigger iceberg than what I've touched on here. After all, entire books (and series of books) have been written on the topic of projects and project management.

But if you need a place to start, I highly recommended spending your limited time and effort in what I've described in this post. If you clearly identify a thing, your job will get a lot easier from that point forward.

I've tried a bunch of different ways to identify and track projects (spreadsheets, Jira tickets, Confluence pages, etc) and they all have varying degrees of effectiveness.

One of the things I've been using a lot lately is Atlas.

It's an Atlassian product that is still fairly new, but it's simple and lightweight and provides a platform to identify projects and update interested stakeholders about their progress.

On that note, I feel like a corporate shill, so I think it's time to recede back into my dank cave and contemplate what's next.