Not on time

I was thinking what would be worse:
1. Finding a bug not on time;
2. Offering a solution on time;
3. Testing a solution on time;
4. Delivering a solution on time;

In all cases "Time" is the key word. The reason is always the cost of money or prevention of higher costs. If I'm correct "on time" means that there is an agreed point of time. And alternative is "in time". When speaking in terms of "in time" we are almost too late.

What I see is that projects are often "in time" or even "too late". Intention is to deliver found bugs or solutions for those bugs "on time" and resources are put in place to meet that intention. As long as we are still "in time" nothing really happens as the feeling we can make it is still there. Actually, no one is getting nervous about this as projects are just done this way.

As long as we don't "value" the bugs or solutions then we will keep planning "on time" and try to deliver "in time". Bugs will become defect ID's and solutions an addendum to that ID or new requirement ID's. In my opinion ID's are could for traceability, they are bad to express "value".

Based on this statement we should try to plan "value" instead of ID's. If "value" is involved people are involved and if people are involved they can be moved much easier as understanding is increased. Mutual understanding is the basis of communication and communication is one major item for success.

Instead on speaking in terms of "Time" we should start speak in terms of value:
1. Find "value";
2. Deliver "value";
3. Use "value";
4. Confirm "value".