The larger any business project gets, the harder—and less advisable—it is to play it by ear. An individual blog post probably doesn’t require much in the way of workflow tracking and task management, but an entire marketing campaign should be organized into related processes and workflows in order to prevent key requirements from falling through the cracks. An individual bug fix in your SaaS product might not necessitate a whole pipeline template with comprehensive tracking and visibility—but refactoring that SaaS offering certainly does.
In order to manage these larger projects, you need a cohesive project pipeline that lets you visualize the whole thing from end to end, while tracking progress from start to finish. In other words, you need to create a project pipeline. In this piece, we’ll get into how to do just that.
Side note: while the concept of a project pipeline is, in one sense, technology-agnostic (you could do most of what we’ll discuss here in an Excel spreadsheet—it would just be a lot of labor and create visibility problems), success here does depend in part on having the right tools for the job. At the bottom of this post, we’ll talk a little bit more about what the requirements for those tools might be.
Understand the Project Requirements
It feels like this should go without saying, but in order to successfully get a complex project off the ground, you need to understand the five W’s: what is the project, where is it happening, when does the project need to be completed, who is the project for, and why is the project important to them.
This might seem straightforward, but it’s not uncommon to find that there’s a lot of depth to be explored here. For instance, you’ll need to work with stakeholders to define the requirements of the project in clear terms. If you don’t, there’s a considerable risk of rework down the line as the requirements turn out to be different from your team’s working assumptions. Ideally, these requirements will be rooted in an understanding of the use cases that your internal or external customer has for the particular project. For a refactoring project, this might require you to understand how the existing product is being used and how it’s failing to meet user needs.
Crucially, at this stage you’ll want to begin getting a sense of the individual workflows and tasks that will go into creating a completed project. You won’t need to fully inventory these until later, but it helps to gather information early and often.
Create a Top-Level Overview with SLA Alignment
The goal of the step above is to gather the essential facts about the project; from there, you can distill them into a high-level overview that gets to the relevant facts as quickly as possible. This should include:
- Project name
- Location (if applicable)
- Project type or area (if applicable)
- Start date
- Target completion date
- Number of component workflows
Then, once the project is underway, you’ll update this overview on an ongoing basis to include:
- Project status (e.g. on-time, delayed, or blocked)
- Projected completion date
- Number of component workflows completed
- Number of workflows remaining, in-progress, or blocked
Wherever and however you’re storing information about your pipeline and tracking your progress, this overview should be the first thing visible to you. It’ll give you a top-level source of truth while keeping the relevant details of your SLA (e.g. target completion date) in view at all times. The result is that you have the beginnings of a cohesive structure into which you can fit the next items on the list: workflows and tasks.
Break the Project Down into Workflows and Tasks
Hopefully as you figured out project requirements you began to get a sense of the actual step-by-step order of processes that will constitute the full pipeline. It’s fine to start with an abstract, high-level account of them—but in this step it’s time to break them out on a more granular level. So, if we take something like a marketing campaign that’s fairly simple (compared to a cloud migration, anyway), we can start with a top-level set of workflows like these:
- Set the goal of the campaign
- Establish buyer personas to create a target audience
- Iterate a content calendar that includes all the elements of your campaign (e.g. blog posts, social posts, case studies, ads, etc.)
- Execute the content calendar and publish the relevant content (including setting ads to run, scheduling blogs, etc.)
- Track the results to measure effectiveness
Each of these items might be considered a workflow or process—but each workflow should then be broken down into individual sub-processes and tasks. So, for the first step above, we might have a few sub-tasks:
- Gather stakeholders to ascertain priorities
- Convert those priorities into SMART (specific, measure, attainable, relevant, timely) goals for review
- Get stakeholder sign-off for SMART goals
- Establish KPIs to track based on SMART goals
This flows naturally into the next process, which can also be broken down further:
- Circulate buyer persona worksheets to relevant stakeholders
- Compile the results and create a master persona document
- Get stakeholder sign-off
- Make personas visible to all other relevant touchpoints.
When we get to the content calendar, the complexity arguably increases, such that we have to divide into sub-processes—brainstorming topics by content type, doing keyword research, gathering data for case studies, etc.—and then sub-divide those sub-processes into tasks. And so on and so forth for each of the initial processes we listed out above.
Order Your Workflows by Dependencies
With our marketing campaign example, setting the correct order for each process is pretty straightforward. Each step will happen in sequence, with every subsequent step dependent on the completion of the step before it. Individual workflows might have sub-processes that can run in parallel, but at a high level you can track progress through the pipeline just by knowing the status of each workflow. With something like a full-blown refactoring project, it can be a little more complicated. Many of the processes can run in parallel, which means that checking your progress against your SLAs—to say nothing of organizing your pipeline into something cohesive and usable—is slightly tougher.
As things get more complex in terms of who needs to do what, when (and what the implications of a delayed or blocked project are), it can become harder and harder to visualize the project pipeline without the right tools for doing so. To wit, at this point, if your inclination is just to use a Kanban board to track your project’s progress, you might hit something of a wall: yes, you can see each task or process that has to get done and a progression of tasks from one to the next—but you can’t necessarily see how the process coheres into a finished product or campaign.
Assign and Track Processes and Tasks
This part is pretty straightforward: once you’ve got the project pipeline mapped out, it’s time to assign some tasks and start tracking progress. As tasks and processes are marked as completed, you can dole out more tasks to keep things rolling. Here, it’s possible for the amount of manual effort involved in managing the pipeline to become quite significant—since each workflow, once it’s marked as completed, potentially requires someone to initiate the next workflow manually. Likewise if a workflow is blocked—depending on how you’re taking in information about statuses, it may require constant vigilance to stay on top of tasks. Yes, it can be done, but it’s also an area where automation can be a huge boon if you can integrate it—which brings us to our last item…
Choose the Right Tools for Tracking and Management
Though this is the last thing we’re talking about in this piece, it’s really one of the first things that you’ll want to figure out before you create your project pipeline. We’ve sketched out a lot of potential areas for complexity above, and while that complexity can be grappled with manually, it’s much easier to handle with tools that are designed around the idea of a project pipeline. What would such a tool look like, and what features might it have?
- First of all, you’d want the ability to look at the full pipeline from end-to-end at one glance. This way, you could see the top level information we discussed earlier on and get an immediate sense of how far along you are, what processes or workflows are ongoing, and where blockages might come up. Crucially, this is where a lot of ticket and task management systems fall down: they don’t offer you a way to see the interconnectedness of the different workflows, or the way in which they’re networked together to form a completed pipeline.
- Next, you’d want automation. This could include automated time-tracking once a process or task has been started, automatic notifications when processes are blocked or completed, and processes and workflows that start automatically when triggered by a certain event.
- Repeatable templates are also crucial functionality. This, too, is an area where most ticket management systems don’t give you the capabilities you need to keep to work at the level of an entire pipeline. But when you perform large, repeatable projects more than once over time, repeatable templates for those project pipelines can be huge time savers.
- Lastly, automated reporting and analysis can be a huge boon. With the ability to do deep dives into the way your team’s time and resources are being expended, you can create smarter pipeline management flows over time.
Again, the larger and more complex a project is, the more important it is to gain visibility into the entire pipeline. If you don’t have a robust project pipeline—or the tools to easily create one—in place, you run the risk of delays and disruptions when your thousands of individual tickets simply don’t add up to a completed project.
