New clients are sometimes unsure about what type of goal to create. The aim of this article is to explain the difference between Metrics, Projects and Tasks.
Metrics (sometimes called Key Performance Indicators or KPIs for short) are numbers where we want to track our actual performance vs. a target level of performance. Metrics measure the critical success factors that drive our operating model - the things we do every day to create leads, make sales, provide our products and services, keep customers happy, grow cash and make profits. Let’s call this stuff “Business As Usual”.
Once we figure out the metrics that drive business as usual, we will likely measure these numbers every day, every week, every month - perhaps for many years. The aim with Metrics is to make sure we are "hitting our numbers" every day, every week and every month and achieving the performance thresholds we set.
Yes, there may be occasions where we set short-term transitory Metrics with a due date e.g. “Raise $5M for a new school gymnasium by 31 Dec”, but the vast majority of Metrics tend to be numbers that are constantly measured and discussed as a recurring agenda item in your weekly team meeting.
Projects are transitory in nature. We choose them at our planning meetings. Projects are typically things we want to create / build / document / launch / or develop. Some methodologies refer to Projects as: Initiatives, Priorities, Big Rocks, or OKRs (Objectives + Key Results). They are essentially the same thing.
Projects are initiatives we undertake to improve our organization, and we typically implement these Projects over a period of 1 month or longer until they are eventually completed.
Projects have a finite lifespan. We complete the Project, congratulate ourselves, and bank the learnings as part of an After Action Review. Then we archive the old Projects and replace them with new ones.
David Allen, the author of Getting Things Done, states that a Project is any desired result that requires more than one action step (Task) to get it done. In my view, this definition is sets the bar too low. My recommendation is that in order to qualify as a Project, it needs to meet the following criteria:
- The Project will take more than 1 month to complete, and
- It requires more than 1 action step (Task) to complete, and
- It warrants being mentioned at a weekly meeting to discuss progress and assign next steps
Yes, we should meet every week to discuss the status of our Projects and assign new Tasks to move each Project forward. If the Project does not warrant being mentioned in a weekly meeting to discuss progress, and does not require a series of sub-Tasks as action steps, then it is not really a Project. The item would be better tracked as a simple Task that you check it off when it is done.
Tip: Don’t keep adding Projects into your software dashboard every time you want to “do something” or the software will quickly become cluttered with Projects and it can be difficult to discern what is truly important, and which items require discussion at your weekly meetings.
When setting due dates for Projects or Tasks, I recommend a conservative due date. Most people fall victim to the "Planning Fallacy". Choose a due date that the person is willing to be held firmly accountable for. Yes, we “hope” to get it done sooner, but the due date in the software is a “must”; a commitment that everyone is counting on.
2 Questions to drive Project implementation
The key to successful business execution is to meet every week to discuss the status of each Project and ask 2 questions:
1. “What is the status of this Project in terms of % complete?”
2 “What’s the “1 Thing” that will get done in the coming week to move this Project forward?”
Weekly Project Status Updates.
It is a subjective assessment, and sometimes there is a bit of debate, and that’s OK, but eventually everyone agrees on the % complete status of the Project at the weekly meeting. 0% means we haven’t even started yet. 100% means we have fully completed the Project (as described in the scope).
What does 100% complete look like? It is important we fully describe what is "in scope" and what is "not in scope" for each Project. This gives us an objective basis for determining when it is 100% complete.
Every Project must include at least 1 sub-Task
Every Project must have at least 1 Task displayed underneath it at all times so everyone on the team can see that the next step is, and who is accountable for carrying this Task out.
Ideally the first Task you see under each Project is something that is due in the near term, i.e. within the next 1 to 2 weeks. We recommend chunking Projects down into bite sized Tasks so you can meet each week to maintain forward momentum as these Tasks get checked off as done.
A mistake we see many clients make is to just show a sub-Task that is due several weeks into the future (e.g. due in 4 to 6 weeks’ time). If you do this you run the risk of getting 6 weeks down the track only to find that this Task did not get done and the overall Project is now significantly overdue. We recommend breaking each Project down into small chunks, set these chunks as Tasks, and follow up each week to hold the Task owner accountable for getting them done.
Make each Task a clear and specific instruction that describes the work to be done. My rule of thumb is that if the Task were seen in isolation from the Project it is associated with, it should be clearly obvious from the Task wording, what needs to be done, by whom, and by when.
Don’t combine Tasks: e.g don't write “Provide 2 training sessions on new sales process”. Better to create these as 2 separate Tasks and check each Task off as it gets done.
Don’t put something vague like, “Work on the new website”. Be specific about exactly what you will get done on the new website. Tasks should be binary, in that they can only be answered yes or no. It should be clear to everyone whether or not the Task was completed by the due date.
Don’t put something like, “Make some sales”. The Task must be within the control of the person who is assigned the Task. Tasks should specifically state what you will do, by when e.g.
“Create the website landing pages for the software demo offer”
“Finish SpaceX proposal and courier it to them”
A Task is a promise
To stop people being flippant with Tasks they are not fully committed to, I suggest you institute a rule: “A Task is a promise”. People don’t like breaking promises and tend to give them much more thought.
A manager (or anyone for that matter) should only make promises that you know you are going to keep. Be very specific about what you are willing to be held accountable for.
Everyone should update their own Tasks every week, check them off when they are done, and add new Tasks to show their team leader that they are using their own good judgement to prioritize their work every week. Additional Tasks can be added as appropriate by the team leader during meetings. Everyone should have at least 1 Task each week to show the team what specific thing they will complete before the week is over (The "1 thing").
Never let a “red” go by.
If people don’t get their Tasks done on time and the manager does not say anything, you are conditioning your people to ignore due dates. In effect, the manager is saying to the team that accountability and honoring commitments doesn’t matter.
Actually it does matter…. a great deal.
Anytime something is “red” in the software, whether it is an overdue Task, Project or Metric, we must “ask the question”....
“What’s happening here?”
We ask the question in a friendly supportive manner, but we must ask the question so that team members know that every week if their Tasks are overdue or their Projects / Metrics are "red", they are going to get asked this question.
If the manager does not have the courage or discipline to ask this question every week, your team will struggle with accountability. The software dashboard will indicate “when” to ask the question, but it is not going to manage your people for you.
There may be a valid reason for something being in the red, but we must always ask the question so we understand what that reason is. Based on the given reason we can then discuss and agree next steps, and provide coaching where appropriate.
Don’t let Projects/Tasks remain as overdue. Negotiate a revised due date and get a new commitment (promise) from the Project/Task owner.
Remember my saying, “Successful Business Execution is 20% giving people clarity about what needs to be done, and 80% following up to make sure it actually gets done”
For more information, see our management training courses to learn our best practices for setting up and managing Metrics, Projects and Tasks.