There are many project management system available out there. Each of them has certain features that appeal to its user base. Regardless of what system is implemented, there are some inherent fundamentals and protocols that make the experience much more efficient. I will cover items I feel are universal to every system. The three project management systems I have used most frequently are Asana, Basecamp and TeamWork. The system I currently subscribe to is Basecamp. I like its simplicity for handling small to medium size projects.

The Title of the Task / Todo Should Not Contain the instructions

Regardless of the project management system being used, there will be tasks / to-dos that are assigned to a designed person / persons. The task name itself should only be the clue of what is contained inside the task VS. trying to place the instruction in what should only have a short descriptive title.  Below is an example from Basecamp of a simple but well formed list called “Site Fixes” that has two to-dos underneath it. If you look closely, you will see the number of comments on each individual todo.  The title of the todo should just be a clear enough indicator on what instruction reside inside the todo.  This is used as a reference and is especially useful as your list grows longer.

Assignment of the Task / Todo

The key propose of your project management system is to be able to accurately track who is doing what. Once a task /todo has been assigned and the “assignee” feels it has been completed per the instructions. He / she should reply with the update and reassign back to the sender. The original sender should be the only one that is able to close or complete the task being the one the requested it. Each time a task is reassigned, it should have some tangible actions that is required to the person it is being assigned to. These can include “check”, “clarify”, “provide more information” and “reassign” to name a few.  For the system to work, it is important to be continually monitoring your tasks to make sure there are moving in right direction.

Placement of Static Information

It is important to understand what information will be needed to be easily accessed throughout the life of the project. Things like project scopes, meeting notes and logins are very easy to disappear inside a task. These should be added to a notebook or text document.  Both Basecamp and TeamWork support notebooks for static content placement. Asana while probably the most robust and powerful of the three systems, lacks in the area of static content management.  Deciding what information will be needed in the future is a judgement call that comes with leaning the system over time.

Referencing the File in a URL

Anytime a document or image is needed as part of a task / todo and / or static document it should be referred as a URL inside the request. I can no longer count the number of times I have seen a request such as “please use the file” and have found myself have to go a hunting mission to figure out which one they mean. In almost every project management system including Asana, Basecamp and TeamWork, it is very easy to grab the URL out of the top of the browser to be able to reference it inline as part of the instructions. The person reviewing the instructions in “one click” away from having the absolute file(s) they need to complete the task.

I utilize both Dropbox and Google drive along with the project management system to be able to achieve the same goal.  Instead of saying “please use the logo for my Facebook page”, I would say please use this -> https://www.dropbox.com/s/onplyxkhnt0nddy/ logo for my Facebook page. This avoid any confusion.

What Should Be Inside a Task / Todo

A well formed task or todo is key to the success of the project. The three major elements required for a web page change is the page URL, body of the instructions, required digital assets and supporting screenshots.

1. Page URL – Listing out the page URL is a big time saver. The bigger the web site, the more time it takes to find the page that is only listed by name. I normally even list out the home page for the sake of absolute clarification.

2. Body of the Instructions – These should be clear and concise instruction with no extra commentary. Thoughts and ideas that are mixed inside a todo can be a big cause of misspent effort / hours.  More words in most cases does not equate to better instructions. Radom thoughts should not be placed within the instruction set.

3 – Required Digital Assets – Any assets such as images, digital documents and other files needed to complete the task or todo should be included within the task thread. This can be either done as an attachment or link to the digital asset itself.

4 – Supporting Screenshots  I could never emphasize the power of screenshots to save both the developer and the client time and aggravation. I find that clients that are not willing to send screenshots claiming that they do not have enough time, end up spending more time on the phone or going back and forth trying to explain in text within task thread. Incorporating screenshots as part of well formed boy of instructions is ideal.

Things That Never Belong Inside a Task / Todo

1. Copy / Paste Instructions That Have Not Been Reviewed – A todo / task should be a well formed thought of exactly needs to happen by the person adding it. It is equally important for the person responsible to review and execute the task in a “professional manner” as the one adding it. The developer saying, “well, I did not really look” would not go over very well. I feel the same way when I see agency clients that do not take the time to review what they send from their clients.

2. Extra Commentary – The task should contain only what is needed to complete that task. Information outside the specific task needed will just add confusion. It is important to remember there are no extra points for additional words.

3. Cost / Prices – Project / task quotes should never be listed inside a todo / task. There are exceptions to this rule, but as additional people are added to the project it could cause problems.  An alternative to quoting in a currency such as $, it to provide hours on the quote.