The Importance of Dates

Often times, people will create a quick task. They’ll write down a few things and put them in the proper columns in a kanban board, or in the proper to-do list, but it never includes a date.

Sometimes, we need to jot these things down quickly to get them out of our heads, but it’s exceedingly important that we go back and put dates to the tasks that we create.

Everyone wants to be on the same page about the mission and vision of a company. Right? In smaller organizations, Sales would like to know where Engineering is with updates, bug fixes, feature releases, etc. Engineering would like to know the "business requirements"?from Sales, (or at least this is what they like to say).

I’ve heard it many times throughout my career, especially when working at large corporations, that people distant from executive management feel that they don’t understand the mission or vision of the company. In their defense, this is often not communicated very well throughout the entire company. But there are times that it is out there for people to read, or see, but they don’t look for it, or it’s buried deep and hard to find.

If we maintain organization and put things where they’re supposed to be, it should not be hard to find. And if we put dates on our action items, then that in itself is communicating when we think something will be finished, something will be ready for testing, or when something will be launched for our customers.?

Dates are not set in stone. They are not final. It doesn't have to be perfect. Things come up, changes are inevitable, and it’s understandable that sometimes dates will change. It’s OK to change a date on a task. But then the question is going be asked, why? If we don’t put the reason why as a comment/update when we change a date, now we failed to communicate again as to why something got pushed out. Most PM tools today have a comment / update section. Some even have the running activity of every change made. So when you change the date on a task and push it out a few days, weeks, or months, it'll record the activity of the person who did and when they did it. So put a reason for changing the date.?

Putting dates communicates to the rest of the team when something is going to be done. When it can be expected for our customers, we expected in testing. This is a direct communication between engineering and sales and vice versa.

Failure to put dates is a failure to communicate. When a date changes, failure to put “why” it is getting pushed out is a failure to communicate.

When a customer wants to know when a certain feature is going to be ready or when a bug is going to be fixed, sales people can know without having to bother others or create a meeting, if there's simply a date on some thing.

No one wants more meetings. So put a date on it.