As you progress in your career, your focus shifts from completing discrete tasks assigned to you, to owning larger projects. Being able to execute complex projects with limited support expands your potential impact on your organization. And as you take ownership of bigger initiatives, you’ll need strong project execution skills to see them through smoothly.
Project execution is both an obvious and unappreciated need for senior data practitioners. Work settings often don’t clearly teach you the skills to break down projects and coordinate cross-functional project teams. I learned the hard way through missed deadlines, tangles of poorly scoped work, and very disappointing meetings. I worked hard, then shared what I thought represented the completed project – only to find it wasn’t what my stakeholders were expecting. Once you add in collaborators who share the responsibility for delivering an outcome, the complexity multiplies. So let’s dig into the key components of project management, for data projects and others:
- Clarifying expectations
- Documentation and common project management frameworks
- Breaking down work into discrete chunks
- Unblocking yourself and others, and
- Holding the team (yourself included) accountable
This is part 4 of a series on the skills that enable data practitioners to develop consistently high impact. My goal is to help individual contributors understand how to build the skills they need to drive results, and help data managers provide clear, constructive feedback to help their team members grow. Links to the full series are at the bottom of this post.
In the following sections, I’ll focus on what less developed and well-developed skills look like in a particular skill area. I’ll also offer some concrete suggestions on how to start improving these skills.
Clarifying expectations sets your project up for success
Setting clear expectations makes it much more likely that you will achieve what you intend with your project. You must define success in terms that your team, manager, stakeholders, and anyone whose help you need will understand. Some even argue that lacking a straightforward plan, clearly communicated to the relevant team, is the root cause of all failed projects.
What it looks like with underdeveloped skills
When you under-use this skill, you may jump into work without a plan at all, or with a plan you haven’t socialized well. Your work may not reflect what your stakeholders need – whether because they are surprised at the limits of the project, or because you’ve solved the wrong problem. Your manager may have trouble understanding what you’re spending your time on, or why. Your manager may also be frustrated that your work isn’t aligned with their expectations.
When you overuse this skill, you spend too much time planning. You may spend too much time on documentation or on breaking down a project into overly small milestones before you have alignment on the overall goal. You may try too hard to reach consensus and waste time trying to make everyone happy when you already have the support of the true key decision-maker.
What it looks like with highly developed skills
Your team, stakeholders, and collaborators clearly understand your project at a high level. You outline what you’re trying to achieve (and why), whose help you will need to achieve it, and what a successful outcome looks like. You share this information early and get feedback. While you will almost certainly not be able to deliver everything that each person wants, you take the time to communicate what you can deliver, and document potential future expansions. You understand who the key decision-makers are and ensure they have all the information necessary to greenlight your project.
How to develop this skill
You can practice this skill with projects large and small. A few approaches to learn to clarify project expectations include:
- Practice clarifying the problem statement (two approaches, from Lenny Rachitsky and Make Iterate). Without describing a solution, write a sentence or two that describes why you’re doing this work. That way, if you need to pivot mid-project, your team has a shared understanding of the high-level goal. For example, “Sales reps struggle to navigate between our visualization tool and CRM; we highlight leads that need attention in a report, but they have to look up the user in the CRM to take action.”
- Make sure roles and collaborators are clear. Designate who is providing input versus making decisions. Clarify whose feedback you will need up front, so they are prepared to review and give you that feedback promptly. See the following section for suggestions on ownership frameworks like RACI that can help create role clarity.
- Once you’re aligned on the problem, you’ll use skills I’ve outlined in other posts to design the right solution. Make sure you’ve socialized what you expect the solution to look like so stakeholders have a chance to react before you invest in building. Following our sales example, perhaps your MVP solution is just to add a link to the lead in your report. You might write “We will add a column to the existing Next Steps for Leads report that links directly to that lead in the CRM.” If your stakeholders were expecting much deeper integration, find that out early and determine the path forward.
- Where a description might not be enough, invest a small amount of time in a low-fidelity prototype. Sketch the table, the dashboard, the workflow, either on a piece of paper or in a digital tool. The more quickly stakeholders have a tangible item to react to, the more quickly you’ll get valuable feedback.
The more quickly stakeholders have a tangible item to react to, the more quickly you’ll get valuable feedback.
Documentation and frameworks bring structure (but not too much) to your projects
While documentation is not an end to itself, documenting your projects enables clear communication of what you’re working on, why, and whose help you need to achieve your goal. It streamlines decision-making during the project and is often valuable after the project to explain what was built and why.
What it looks like with underdeveloped skills
Many failure modalities for this skill look similar to those for clarifying expectations, as the primary intention of this documentation is to record an aligned version of those expectations.
When you under-use this skill, your teammates and collaborators may struggle to understand or remember what your project will accomplish (or won’t). You may experience misalignment between what you believe you’re delivering and what your stakeholders believe you’re delivering. When you leave an organization, an enormous amount of history and context leaves with you.
When you overuse this skill, you spend a large portion of your time writing documentation. You get overly attached to your preferred frameworks and are unable to see when a different approach might be more successful. You may struggle to get people to read your documents because you have overwhelmed them with documentation. You may get frustrated with teammates who didn’t read all of the documentation and missed a small detail. You may under-invest more synchronous and human communication systems on the team.
What it looks like with highly developed skills
You have a few default documents that you can use to quickly and clearly record key aspects of a project. Significant projects likely have a problem statement, roles and responsibilities, and key decisions documented. You leverage the preferred formats of your organization, if they exist, or follow a consistent format of your own if they don’t. You evaluate each project to determine whether it needs more, less, or a different approach to documentation. You track project progress in some form and either make it public or proactively push progress updates to key stakeholders.
How to develop this skill
The right level of documentation and which frameworks to use will vary from organization to organization. However, being aware of standard frameworks will help you avoid reinventing the wheel when a widely used approach could help. Some areas where you might want to focus to build your skills here include:
- Familiarize yourself with commonly used frameworks within your organization, if they exist. Bookmark any templates that exist and use them whenever possible rather than your own versions.
- If you need more clarity on roles and stakeholders, read about common responsibility frameworks like RACI, RASCI, RAPID, or others. These frameworks clarify what roles each team member plays, who has decision-making authority, and who is actually doing what work. If your org doesn’t have a preferred responsibility framework, pick one and start using it for your own projects.
- Create a lightweight template to capture the core items the team aligned on in the “clarifying expectations” phase. This likely includes the problem statement, what the deliverable will look like, and who your core stakeholders and decision-makers are. Experiment to find what works for you – a few bullets in a ticket may be sufficient to start, or you may want to create a more robust one-pager template. Make this process lightweight and second nature so you don’t skip it.
- Practice using a lightweight decision framework to clearly document decisions to be made (and the outcome of those decisions). This structure will nudge you clearly communicate when a decision must be made, what information is relevant to the decision, and who should decide (likely based on your responsibility framework!).
- Determine how you will share your expected timeline and progress against major milestones. Many productivity tools do this out of the box – start by checking out the documentation for the tools you use, whether that’s Jira, Asana, or another tool. Remember that making your progress visible can save you from constant inbound questions about progress, so consider it an investment in your focus time.
- Work with professionals with strong skills in documentation and leveraging frameworks. Project or product managers in your organization can provide suggestions for how to structure your work or provide for feedback and advice.
Breaking down work enables consistent progress
When you are responsible for delivering larger projects, it can feel a bit like the “draw the effing owl” meme. Particularly when you’re coordinating multiple people, you need clarity on the interim steps you and your collaborators must accomplish to deliver the work. Breaking down work into manageable pieces makes it easier to predict how long a project will take, identify and manage dependencies, highlight areas of risk, and make consistent forward progress against your goals.
What it looks like with underdeveloped skills
When you under-use this skill, you take on overly large units of work. You find yourself working on the same big chunk of project work for many days or weeks. You may get stuck because you don’t know the next step to achieve your end goal. Your estimates of how long work will take to complete are inaccurate – you consistently fail to deliver results on your timeline. You are surprised when your unstated assumptions prove false or by other points of failure.
When you overuse this skill, you spend a large proportion of your time planning work rather than executing. You create overly detailed project plans, and they may become irrelevant as the work progresses.
What it looks like with highly developed skills
You clearly translate high level projects into actionable next steps. While designing the right solution is a skill unto itself, once you have the design, you can break it down into small units of work. You proactively identify assumptions, dependencies, and likely points of failure, and communicate them. You can estimate how long a project will take to deliver with reasonable accuracy (and if you can’t, you can break it down into a smaller piece of work that you can estimate).
How to develop this skill
A few approaches to learn to break down projects include:
- Before you write any code, spend 5 to 10 minutes writing out a rough work plan for each task. What tools will you need to use? What data sources will you primarily use? Do you have any open questions (for example, “I’m not sure if the mart includes this field”)? Roughly how long do you expect each phase to take? Categories like a couple of hours, a half day, a whole day, or multiple days are sufficiently granular here. If you expect any stage to be much longer than a day, see if you can break it down further.
- Practice using acceptance criteria – when this chunk of work is complete, how will you know? This is particularly useful when chunks of work will be handed off (either completed by someone else as an input to work you are doing or completed by you as an input to another teammate’s work). Clearly defining a successful outcome for each chunk of work also ensures you keep milestones high-level enough.
- As you look at your work plan, are you dependent on others for any stage of the process? If so, talk to that team about timing and make clear when their work is needed for you to proceed.
- Check your work plan for significant risks or assumptions. Be open with your manager and other relevant stakeholders about where you see risk. This may not prevent failure, but it can prevent surprise failure, which can feel much worse. They also may be able to help brainstorm alternative approaches to mitigate risks.
- Much digital ink has been spilled on agile methodology and how to break down work to deliver incremental value. Michael Kaminsky takes a relatively brief look into what works well in analytics in his Agile Analytics series (part 1, part 2, and part 3). Start there, and further research techniques that might be useful.
- One of the reasons agile is challenging with data is that some kinds of data projects are circular – you don’t know what the next step will be until you do the first bit of work, and often you need an as-yet-unknown amount of investigation before the project begins to progress. Alexis Johnson-Gresham and I wrote about how to manage those circular projects and break them into small, linear pieces in Linear and Circular Projects in Data (part 1 and part 2).
- As you finish the work, note how long various stages and the project overall take. Compare it to your initial work plan and identify where you under- or over-estimated. Though delays happen, giving yourself a clear feedback loop is the best way to improve the accuracy of your estimates.
Unblocking yourself and others
Sometimes, we all get stuck on a project. That may happen because you don’t know how to proceed technically, you need feedback or input from someone else, or other reasons. As you become more senior, you’ll become better at knowing when, how, and to whom to reach out to unblock your work and keep moving.
What it looks like with underdeveloped skills
When you overuse this skill, you may ask for help too often and/or too quickly. You deny yourself the opportunity to learn how to be independently effective and potentially wear out your manager or peers.
When you under-use this skill, you may struggle to make progress on stretch projects and cross-functional projects as quickly as you would like. You wrestle with blockers too long before asking for help, slowing you down when a quick assist could get you back on track. You delay asking for feedback or input from other stakeholders, keeping you from progressing as quickly as you might like (or you don’t follow up on that input effectively). You may not have the organizational awareness or cross-functional relationships you need to know who to ask for help. Your requests may be unclear, making it harder for others to help you.
What it looks like with highly developed skills
You know how long to try to muddle through before asking for help. You ask useful questions. You know that stretching into new challenges, searching for answers, and testing multiple solutions on your own will accelerate your growth. But you don’t let yourself lose too much time when you just need a nudge. You know when and how to reach out to stakeholders to get the feedback you need to proceed. More importantly, you know how to frame that request so it is easy for them to help, and when to bring in your manager or other team members to assist.
How to develop this skill
A few approaches to getting better at unblocking yourself include:
- Make sure you understand what’s blocking you. Do you know the prerequisite you’re missing (I can’t do Y without X) or are you unsure what you need (I just don’t know how to do Y)? Is it a technical blocker, or a non-technical blocker (you need alignment on your approach from another team and they aren’t responding)? Articulating the difference will help you identify who and how to ask for help.
- Make it easy for others to help you. Ask specific questions, lay out requests of other teams clearly, and make it easy for them to follow up (framing needs in terms of acceptance criteria can be helpful here). Keep explanations and questions crisp. Bold your call to action in email or Slack to make it clear.
- Leverage your manager. Of course they are there to help un-block you. I like this Julia Evans post about things your manager might not know. It provides some specifics on what to keep your manager informed about to make sure they can help remove blockers.
- Wherever you track your work, have a clear section for blocked items. Make clear in the task what is blocking you. If you’re blocked long enough that you pick up new work, make sure you return to that blocked task and finish it before it goes stale.
Make it easy for others to help you.
Holding yourself and collaborators accountable ensures delivery
The ultimate goal of all of these skills is to ensure that your project delivers the outcomes and value you intended. As a project leader, you don’t have to do all the work, but you are responsible for ensuring that your teammates deliver their portions. Holding yourself and your collaborators accountable is perhaps the most important skill to ensure that you deliver high quality work on an acceptable timeline.
What it looks like with underdeveloped skills
When you under-use this skill, you don’t deliver what you committed to when you said you would. Colleagues often have to reach out to you to understand where the project stands, and that outreach often prompts you to reset expectations or push out a delivery date. You may not feel comfortable holding your collaborators accountable. Your teammates don’t deliver their work on time or with high enough quality, causing project delays.
What it looks like with highly developed skills
You follow through on what you said you would complete. Your colleagues consider you reliable and are eager to work with you because they know you will deliver. You hold others accountable to what they said they would deliver; you understand competing priorities but nudge for clarity on delivery. When timelines, high level assumptions, or goals change, you proactively communicate them to the relevant team. Your colleagues may still check in sometimes to see if work is on-track, but that is rarely when they find out about delays or issues.
How to develop this skill
A few approaches to learn hold yourself and others accountable include:
- Regularly ensure all contributors understand their next step and when that next step should happen. Spend the last 5 minutes of any synchronous meeting reiterating next steps. For asynchronous projects, find the right cadence to remind folks. While the project you are managing may be a very high priority for you, it may be the fourth or fifth priority for some of your collaborators. Make it easy for them to keep the project moving by keeping the expectations very clear.
- Actively check in on your collaborators. If you expect someone to reach a milestone and you haven’t heard from them, follow up promptly to understand the source of the delay and consider its overall impact.
- The chunks of work you identified in the “breaking down work” stage give you an estimated timeline for each phase of the project. As soon as you see that you are off-schedule, proactively communicate it to your manager and/or team. Delays happen, but like failure, surprise delays are worse than well-communicated ones.
- Similarly, if any high level assumptions or goals change, proactively communicate them to the relevant team. Proactively communicate changes in scope to your key stakeholders. When you complete the project, everyone should agree that it is complete.
- Build your comfort with uncertainty and failure. Not every project achieves its initial goals; you can’t answer every question with the data you have. Be part of building a learning culture within your organization; when a project fails, be open about that but take time to celebrate what you learned from the experience.
Become a teammate known for delivering value
Taking responsibility for delivering larger, more complex projects can be both exciting and nerve-wracking. These projects can deliver significant value, but can also become a swamp of missed deadlines, unclear decision-making, and misaligned expectations. You can hone project execution skills even when your projects are still relatively small and simple. Become known for delivering projects effectively and collaboratively, and you build trust with your management and peers. That trust will lead to bigger projects and expand your impact.
What skills have you found particularly important for delivering complex projects? Do you have any favorite frameworks or tools that have made it easier? I’d love to hear more about your experience in LO’s Slack community.
