Working for a tiny, ambitious team, I often find myself needing to move quickly. As in, I really needed to be moving yesterday.
And while I don’t mind too much, that’s not the approach I’d associate with thorough project work. If you’ve ever been on a project that didn’t seem to end, felt disorganized, deviated from the initial scope or just straight up missed the mark, then you know that project work can be a slog.
This can happen for many reasons: lost momentum, a change in circumstances, lack of task management, and so forth. But unclear goals is another obvious culprit, and the big one we’ll discuss today.
Rough Waters
The start of a project is where we name our goals/destination. So even if the course has to change along the way, project teams still know where they’re ultimately headed.
But in our haste to kick off projects, we don’t always spend enough time on that first step! An unclear destination makes for a choppy journey.
And while there are many goal-setting frameworks out there (this roundup by Jell is a great digest), there’s still the question of how we pinpoint the true goals for a project.
Over the years, I’ve worked on projects where one thing seemed to be the goal, but turns out there were a bunch of other things that were also goals.
That’s why I’ve recently tried to push my team – and myself – to distill what it is we’re really trying to achieve and to make that explicit. Not just going off what seems obvious, or naming things that sound like good goals.
So far, that approach appears to be working.
Let’s set goals
The approach below outlines what I’ve found to be most helpful these days. It’s but one option for lean project teams, to quickly & practically scope projects at the onset. How it works:
- We consider outcomes, deliverables, objectives and process in order to suss out goals (see diagram ↓)
- This helps us name project goals that are targeted, sufficiently nuanced, and most true to what we want to accomplish
Now I don’t mean to say that any of this is groundbreaking. Outcomes, deliverables and objectives aren’t new concepts! And the questions below are fairly simple.
But it’s easy to cut these corners when you’re moving quickly. I’ve found that answering these questions slows us down just enough, in a way that’s organized & necessary for getting to what’s important.
1. Start by imagining outcomes
With most process-oriented endeavors, I find it helpful to start at the end. What does this project achieve if it’s successful? Who does it impact? How? Getting specific helps. Try to name outcomes that are either measurable or at least observable.
Some questions to help dig deep on outcomes:
- What will stakeholders be able to do that they can’t do now?
- What gets improved as a result? How exactly is it better: speed, accuracy, ease, etc..?
- How will stakeholders feel when all is said & done?
- What lessons/benefits will stakeholders take away as a result?
2. From there, brainstorm deliverables
Deliverables are the tangible “things” that get produced as a result of your project. They can be physical or digital assets, language, or even policies.
Specific examples of deliverables:
- The launch of a new platform
- Documentation – user guidance, technical docs, etc…
- External materials – promo decks, web pages, flyers, etc…
- Internal or external language/messaging
- A new product or program offering
3. Begin forming objectives
Objectives are like sub-goals. Now that you have your target outcomes & deliverables, what will it take work-wise to get there?
Try not to get bogged down with details during this brainstorm. Think of objectives as one, high-level task list.
4. Reflect on your team’s process
This step can get missed in the race to deliver. Spend time reflecting (again, high-level) on what it will take internally to get this project done right. Things you might consider:
- Who all needs to collaborate, and how best to do that. (If you need ideas for how to clarify roles, The Management Center’s MOCHA framework has been my latest source of inspiration)
- How major decisions will be made, especially when there isn’t consensus among the project team
- How to keep the team honest when a project threatens to derail
p.s. This is also a great opportunity to deliberately exercise your org’s stated values. For example:
- If one of those values is equity – where can you mitigate any potential harms that could arise from your project?
- If one of those values is transparency – what are some ways you can make the process more visible to stakeholders?
- If one of those values is learning – how will you have the team reflect on lessons learned?
There are too many values to highlight, but you get the idea. Use step #4 as a moment to help your org walk its talk
5. Using the above, arrive to a goal
Hopefully you have what you need to name a succinct goal, that considers the items above (without rehashing each one).
Tips for framing your final goal:
- Keep it short. You already listed things that shed light on the overall aims. I like to limit myself to 1 (or no more than 3) overarching goal statements
- Frame your goals in a way that considers all of the answers above
- And finally, if you’re having a hard time, try not to get too stuck on language.
Happy Planning
Have more tips? Please share below!
Share your thoughts!