IT Employment

My staff are bonussed for on time delivery. They get 100% bonus if 80 % of their deliverables are on time(if there are no external factors delaying which are out of their control)

Best practises also include a post-project review where everyone gets together and seeks to understand what lessons can be learned from the project. One of the things to be reveiwed is the schedule. If you do this on an ongoing basis, you improve your ability to plan and schedule, because you add to your assumptions and experience.

James

Bonuses are a little on the expensive side, try lunch instead.

If your team is going to meet its deadlines, your team is going have to manage its own time. One of the approaches I have found to helping the team to do this is as follows.

1) Break the project into a sequence of 2-4 week iterations. Each iteration needs to result in one or more well defined deliverables.

2) At the start of each iteration, give the list of deliverables to the team and have them come up with a work schedule to get the tasks done. The schedule should consist of 1/2 day, 1 day, and 2 day steps with no step longer than 2 days and most falling in the 1/2 day range.

3) Have a daily 5 minute stand up status meeting. Each person should answer "What did I do yesterday?" "What am I going to do today?" "What are the hurdles to getting done on schedule?" Keep the meeting to 5 minutes, do not let it become a bull session. Social interaction is good but must occur either before or after the meeting. Tehcnical discussion should be deferred to after the meeting and only involved the interested parties.

4) At the end of the iteration, have the team members present the results. Use a simple score card presentation - Green for tasks completed, Red for not completed - No partial credit. Have the team demonstrate the Green tasks. Have the team members explain why Red tasks were not completed.

Make the team fully responsible for managing their time. You cannot do it for them.

Why are they missing ?
Are the priorites clear.
Is some one confusing elapsed time, with time spent at the task.

Best practice is simple

Ask the developer, how long they think it will take. Make that your plan.

Reduce the scope of the task, lower priority of other work, throw more devlopers at it, throw a more experienced developer at it, take proper timeline on chin.

If you are already doing the above and they are still failing to meet deadlines, then get them to explain why.

If it turns out they spent the last two days on network quake, kick their ***.

If it turns out they underestimated, find out why, factor in for next time.

If it turns out that someone was on holiday, sick, drafted in to fix manager X's daughter's PC, put on another task which just had to be done, find out why you didn't find out in time to adjust your plan.

If it turns out the deadline was set without any reference to the developer doing it and their assesment of how long, make a brave attempt at kicking yourself in the ***, if you fail, get your manager to do it for you.

Based on the wording in your post, this appears to be a fairly consistent problem. I would suggest doing a full root cause analysis of the problem. Pick a task, and ask the question "Why was the deadline on this task missed?" Once you get that answer, dig deeper, keep asking WHY? to ascertain the root of each answer. Get in front of a whiteboard and draw a Ishikawa/Cause & Effect diagram. I would suspect that once you got to the root of the issue on a particular task, that problem would be accounting for the majority of your problems with missed deadlines.

A second point to think about is how skilled are your developers at providing you with accurate task timeline estimates? Is your team full of Junior Developers? If so, that could be the problem. Oftentimes, Junior level developers do not have the skill and experience to provide accurate timeline estimates. Consider some training for the team on how to properly give timeline estimates for their tasks.