One of the great things about digital marketing is the ability to quickly scale your work. By working smarter and more efficiently you learn more and find additional ways to get the most out of your time. The downside is that you won’t scale forever.
At some point you’ll need to learn to break tasks down amongst team members. You won’t have a choice as projects become too large, the tasks and team members more numerous. Even this has limitations. What was once handled by quick chats at your neighbor’s desk soon becomes overwhelming and difficult to manage.
In my case, we had a solid team with great deal of knowledge and ability but the workload and responsibilities became large enough that it wouldn’t end well without formalizing parts of the process and systematizing the process for adding projects and tasks to the queue.
Today I will cover the scenario and explain how to go about tackling this issue as well as a few reasons for making decisions. The example I use will be based on a team of specialists across multiple roles but you can just as easily figure a way to fit it to your particular team set up. Let’s dive in.
The Problem
The main problem was that there were too many tasks and team members. The close-knit team was capable of sorting through many issues themselves whether it was:
- Asking for advice
- Seeking assistance
- Delegating tasks
But as a whole it was hard to know if the team focused on the right things or not. Although there were methods in place for managing projects for individual accounts, we needed a method that could apply to a different set of users and needs.
The main concern was the risk that this decentralized process would unknowing steer us into tackling tasks without considering what was most important for the group as a whole. We could be efficient at cutting the grass but would completely ignore the oak tree growing in the middle. Not only did we risk missing high priority projects, but also there would be stress down the road, creating more work as we attempt to fix them later.
Thus we established a formal process for prioritizing and logging projects in order to capture demand, balance resources, and a get a better idea of how the team functioned.
Considerations and Planning
First we had to figure out what needed to be tracked and how we would log requests. Although it seems simple, this process was subject to heavy revision. If anything, asking “does this matter” only brings up more questions. For this article we will keep the requirements as simple as needing an efficient system without much overhead with the ability to track the project along multiple stages.
To capture demand, I created a request form on a shared Google Drive. The form was simple and asked for a few key pieces of information on the project and logged the information in a spreadsheet.
Now comes the harder part, what do we need on the form? First off we needed the basics such as account, requester, due date, type of request, etc. One the most difficult areas is the information around the type of request. This needs to be both simple to encourage people to use the form, as well as detailed enough for the decision maker to have some ability to quickly judge.
This aspect is one of the more difficult to juggle. A shorter form is easier to fill out for the user but may be unclear to the project manager. A longer form may be more informative to the manager but puts the burden on the member submitting the request. Depending on the project you must also consider the most vital information. The longer forms also run the risk of being extraneous and actually clouding the manager’s judgment.
Figure 1.) An example of one of the early top level tracking pages for submissions, due dates, time remaining, and assignments.
After the initial submission we needed to decide what else to track. In this case it was:
- How many projects are submitted?
- How long does it take to complete them?
- How long after completion are they implemented?
Each of these categories covers key areas of the process. These were chosen because a break down at any of the stages hinders effectiveness. These areas were chosen because if something looks off, these are the places we will look to make tweaks or start asking questions. By simplifying our view, we found the vital areas to record.One of the most interesting areas to me was the third question.
By tracking the time from completion of the project to actual implementation tells us a lot about our overall effectiveness. If this isn’t happening or is taking too long, all the work is for naught.
For example, a long time gap may mean the requester is overwhelmed with other tasks, the project was completed incorrectly, or a client changed their mind from whatever they asked someone on our side. Each of these can easily fly under the radar if you aren’t looking out for them. Tracking these updates not only gives you insights and further questions but ensures that the process itself is valued and all the work is not for naught.
The Workflow In Process
Once we mapped the information we needed, we moved on to how the process works. This is where you’ll see the most variance between your needs and the needs of this scenario. At a simplified level we needed someone to monitor requests, evaluate feasibility, and assign the project.
More specifically a request comes in. Someone the project manager evaluates the request checks the other variables such as current workloads and workdays remaining.
One aspect that has worked well is a confirmation system. In our case we implemented e-mail follow-ups that detailed the request and was sent to everyone on the project. This not only served as a confirmation but also gave the requester a reference for submissions and whom they would be working.
Early Issues in Form Design
No system works perfectly right out of the gate. As with any type of form our largest hurdles were consensus on the fields. We originally implemented a task field of “I need something implemented”, “I need help diagnosing a problem”, or “I’m not sure what the problem is”.
Figure 2.) One of the submission forms we tested.
These options seemed simple enough from a management perspective. Each of these corresponds to a different position on the team. In practice though, we received way too many of the third option. Although the options were clear enough to the decision makers, they weren’t clear enough to the requester. Based on this we went back and rephrased the options such as “I need help from the production team”, “my account is having performance issues in a specific area”, and “my account is performing poorly or not hitting goals”.
Although these three didn’t change the management process itself, they immediately cleared up questions and improper categorization by the requesters. Immediately, we were more capable of sorting incoming requests, better gauging the time required, and cutting down on questions or apprehensions on the requester’s side. Similar to a lead gen form, you want to make the process as painless as possible when requesting information.
Going Forward
The system is still a work in progress and at some level, it always will be. We still continue to alter the form as needed. One thing I have not covered, although I’m heavily invested in the issue, is overcoming previous behavior patterns and habits. Besides putting the pieces of the system together, there is the ever-encompassing human element. Over time team members form their own habits and preferences that may not fit into the current system.
You’ll need to examine why this happens. Is it a lack of awareness, form filling anxiety, a misperception of the process, or something else? In most cases, I’d say it was a mix of all of the above. Sadly I don’t have a quick solution for you. The only way to circumvent these issues it to begin communicating and asking questions.
More often than not you’ll find solutions to problems you didn’t know existed and find many of these issues lie in simple confusions that are solved by a quick discussion as to why the system is the way it is. Who knows though, if you wait long enough and I find a few answers, there might be a follow up article in the pipeline.
Have you ever implemented a process like this? What issues did you run into and how did you solve them? Feel free to leave a comment to leave advice for your fellow readers, a question for me, or even a lamentation on the time you tried this process.
