Projects and Tasks

Implementing Projects and Tasks

Projects:

All Projects are transitory in nature. Projects are typically things we want to create, build, document, launch, or develop. We typically implement these Projects over a period of several weeks or months until they are eventually completed.

Projects have a finite lifespan. When we complete the Project, we congratulate ourselves and bank the learnings as part of an After Action Review. Then we archive the old Projects from our software platform of choice 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 sets the bar too low. My recommendation is that in order to qualify as a Project, it needs to meet the following 3 criteria:

  1. The Project will take more than 1 week to complete, and
  2. It requires more than 1 action step (Task) to complete, and
  3. It warrants being mentioned at a weekly meeting to discuss progress and assign next steps

When it comes to Strategic Projects (aka “Big Rocks”),  I strongly urge my clients to meet every week to discuss the status of each Project and assign new Tasks to move each Project forward. Most importantly, what is “The One Thing“, the most important task that can be completed in the coming week to move this project forward?

Regardless of how many Tasks you have scoped out for each Project, chunk it down and make sure “the one thing” (the critical path) is agreed upon each week. And more importantly, follow up at next week’s team meeting to make sure “the one thing” got done.

In my opinion, 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. Such items would be better tracked as simple standalone tasks that you check off when done.

RACI.

For every major project, use the RACI model to specify people’s level of involvement, and set clear expectations. 

Responsible – The project team members who will be doing the work
Accountable – The project manager who makes the decisions and makes sure the work gets done (there can be only 1 name here)
Consulted – People who need to be consulted for input before decisions are made 
Informed – People who need to be kept informed of decisions and progress

Due Dates.

When setting due dates for any Project (or Task), I recommend a conservative due date. Most people fall victim to the “Planning Fallacy“. Choose a due date that the project owner is willing to be held firmly accountable for. Yes, we “hope” to get it done sooner, but the due date is a “must”; a commitment that everyone is counting on.

What is the scope?

What does 100% complete look like? It is important we fully describe what is “in scope” and what is “not in scope” at the beginning of each Project. This gives us an objective basis for determining when the project is complete, or when the desired milestone has been reached (if the project is being split into phases i.e. quarterly milestones).

Make a high-level list of all the major elements that need to be completed by the due date (i.e. “in scope”). Also, make a high-level list of the elements that will not be worked on during the course of this project (i.e. “not in scope”), especially if the project is being split into phases. For example, you may wish to clarify what elements will get done this quarter, and what will be deferred until a subsequent quarter.

0% complete indicates we haven’t even started the project yet. 100% complete means we have fully achieved the scope, or achieved the desired milestone for this phase of the project.

Develop a way of quantifying progress, or ensure there is a robust debate with the team each week to agree on the status of the Project in terms of percentage complete and update the software dashboard accordingly. You need good data to run a good meeting.

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 these questions:

  1. Any changes to the scope? (beware of scope creep)
  2. On track to complete the project, as scoped, before the due date?
  3. Key achievements since our last meeting?
  4. Any roadblocks?
  5. Lessons learned?
  6. Next steps?
  7. What is “The One Thing”?  (the most important task that can be completed in the coming week to move this project forward)

Tasks:

Chunk Projects Into Weekly Tasks.

A task is a single unit of work that needs to be accomplished within a project. Every Project must have at least 1 Task displayed underneath it at all times so everyone can see what the next steps are, and who is accountable for each Task.

Ideally, the “next step” (The One Thing) is something that is due in the near term, i.e. within the next 7 days. A mistake I see many clients make is to list the “next step” as being 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 the Task did not get done on time and now the overall Project is now significantly overdue.

I recommend chunking each major element in the scope into smaller weekly Tasks so you can meet each week to maintain forward momentum as these Tasks get checked off as done. Book a recurring weekly Project Status Meeting to discuss progress, and follow up each week to hold Task owners firmly accountable for getting them done. Don’t let things fall behind. I call it “weeding the garden“.

Task wording.

For Tasks, the action item must be stated as a clear and specific instruction of the work to be done. My rule of thumb is that if the Task were seen in isolation from the Metric or 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. “Provide 2 training sessions on new sales process”. Better to create 2 separate Tasks and check each one as complete when it gets done.

Don’t be vague. 

Incorrect: “Work on the new website landing page”
Better: “Create the website landing page for the software demo offer by (date)”

Be specific about exactly what landing page you will complete on the new website, and by what date. 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 be generic. 

The Task must be an action that is within the control of the Task owner, and clearly state what they will do, and by when.

Incorrect: “Make some sales”
Better: “Finish SpaceX proposal and courier it to them by (date)”

Updating Tasks.

Everyone should update their own Tasks every day, check them off when they are done, and add new Tasks in their software dashboard to show their team leader that they are using their own good judgment to prioritize their work every day and every week. Additional Tasks can be added as appropriate by the team leader during meetings. Everyone should be assigned at least 1 key Task each week to show the team the most important thing they will complete before the week is over (aka The 1 thing”).

Task Rules.

I recommend setting conservative due dates that factor in time for unforeseen delays and distractions. The task owner should feel safe to negotiate a mutually acceptable due date with their manager, and once this is agreed upon, be willing to be held firmly accountable for getting the task completed by the due date.

To stop people from being flippant with tasks or due dates they are not fully committed to, I suggest you create a set of “rules” or policies.

Here is my set of “Task Rules” I use to upgrade accountability and help create a high-performance team culture with my clients:

  • No surprises. No excuses
  • A task is a promise
  • Due dates are “commits” not “hopes”
  • Don’t give a date by which you “hope” to get the task done, “commit” to a realistic date that others can count on
  • Between now and the due date, it’s OK to ask for help if you get stuck, or renegotiate your commitment if something happens outside of your control
  • However, it is totally unacceptable to show up with an excuse on the due date with the task not done

For best results, involve your team members and craft your own unique set of Task Rules, so that everyone buys in and is willing to commit to them. Once finalized, post your Task Rules somewhere visible and refer to them during your team meetings so they become ingrained as part of your team culture.

Always Confront Overdue Tasks.

Many software dashboards show Metrics, Projects, and Tasks with a red color if they have fallen behind. Software dashboards can help you manage your people more effectively, but they do not replace the need for effective management practices. Managers still need to manage.

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 keeping commitments don’t matter.

Actually, it does matter…. a great deal. There may be a valid reason for something falling behind, but we must have a disciplined process for holding people accountable.

Don’t let Projects/Tasks remain overdue in your software dashboard. Negotiate a revised due date and get a new commitment (promise) from the Project/Task owner.

I have a 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 on this topic, here is my process for choosing your Strategic Projects (Big Rocks).

Need help? Contact me to discuss your strategic planning needs.

***

Until next time…
Stephen