Time is money

Time is money is not necessarily a true statement but is a max statement for the reality which is how scarce time is as a resource.

To understand the importance of time you must see and understand time as a resource of your project and more importantly a resource that once spent cant be purchased back.

“Time is the indefinite continued progress of existence and events that occur in an apparently irreversible succession from the past, through the present, into the future” (Wikipedia).

By its own definition once time is spent, once an event is passed, it cant be retrieved back. This leads us to 2 time possibilities: now and future.

Looking at the time as an finite resource on a timeline, all time that is passed you can’t use again and what lies ahead is what is available and this is what make times a precious resource.

Suppose that you are working on a sprint cycle of 2 weeks. This means that each person on your project, has at most 91 hours available of work considering an average of 6.5 hours a day of work.

To help on this example lets consider that a project has 1 developer, 1 PM, 1 QA and 1 Tech Support. For scenario construction, lets consider that all the other team members have 91 hours available to deliver the project. Now lets consider that 40% of the stories and tickets from this projects is poorly written.

For any poorly written ticket this will inevitably happen:

  • Wrong feature developed by the developer
  • Testing Failure by the QA Team
  • Back and forth until the feature is correctly created.

If any of those scenarios above takes 1 hour each, this means that both the developer and the QA team members lost 2 hours each which takes a total of 4 hours from the project. These are 4 hours that you won’t have back.

Before monetizing this, lets say that after those 4 hours are lost, tests passed and the feature was released and a client identified a critical issue with the feature. Now, this feature that has already lost 4 hours, will be taking time from the tech support team member and from the PM. Using the same consideration of one hour per event per team member, now we have a total of 6 hours lost. Considering that this time the feature was correctly written, then 6 hours would be the most that would be lost for this feature.

This was one feature, and in our example it was mentioned that 40% of the tickets were poorly written. If the whole project has 10 features and 4 of them fails under this same scenario, then, now there are 24 hours of the whole projected lost.

Looking at the whole amount of time available for the project, 364 hours, those 24 hours is only 6.5% of time that was poorly spent but this is 6.5% of time that you cant retrieve anymore.

You can put a Dollar amount into the the amount of hours spent calculated by the value/hour by each individual or by taking 6.5% from the total amount of the project but, Time is Money is better reflected on how much time you have wasted.

That wasted time will do have a cost for you and any strategy that mitigates that loss of time is a good strategy. So far, by my experience, all the time lost in a project is because poor communication of what is wanted or needed.

Use your time well, you only have 24 hours each day.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store