Your team member fails to meet the deadline for the coding and testing of a component. What do you do?

Question

You are the manager of a software development project. One of the team members fails to meet the deadline for the coding and testing of a component. What do you do?

Answer 1

If the developer failed to meet deadline - there is a reason behind that. Find out what happen, make sure it will not happen again, or create a contingency plan for when it will happen again.

In my practice, the best way to approach this - is to establish communication guidance with developers.

First of all, i would recommend for developers to give you their estimates for the task they will be working on, or if there is a deadline for the task, ask them to do a review/research for 15-30 mins and either confirm they going to meet the deadline or deny and provide new estimate, based on info they found out from research.

During the actual execution, Developer should update you if something went wrong (issue occurred, a risk was realized, or dev just understood that this is going to take more time) and he/she will not meet the deadline. Based on the reason, you can try to help him out in many different ways, if necessary.

Try to avoid situations when you give developer a task with a deadline, and check the task progress only when the deadline comes.

It is also your job as a PM is to support developers through their work and help them do their job at best.

Answer 2

You manage your variances. Fast track or crash succeeding tasks where you can and what you can afford. And communicate early, honestly, and as much as possible. This is project management. Unless you consistently plan fat and happy, which is not an objective you should have, you will be late as much as you are on time and early. How you manage those unfavorable variances is what makes you a good PM, not that you are never late.

Answer 3

You get used to it, as it happens all the time. :-)

You start be readjusting the schedule. Then, if needed, you escalate the newer deadline to those who need to know, so they can adjust their plans and the customer's expectation.

In the real world you probably have a buffer in the schedule so that the missed deadline doesn't cause major harm.

If this happens often, then you have to either learn to adjust the estimates this programmer gives you, or else send him to a course for better training.

Answer 4

In classical project management there is only communication. Your project is late not because that one developer, your project is late because of bad planning or risk management. What your stakeholders want you to do in this situation is explaining the situation, the consequences and of course what you do now to keep the postponement as small as possible.

If there are still things to do support your developer with more developers and create an environment where they can focus on their work.

If he is basically done there is only honest communication - and don't forget to take responsibility, there is nothing weaker than blaming the developer.

If you look on the root cause of the problem, your complete project depends of planning the wrong or too less people on a specific task. This is not bad project management. In software projects it's normal. On new software components it's simply not possible to plan properly, depending on the complexity of your software. That's why you should think about switching to agile methods like Scrum or Kanban. They deliver a much better way to plan and forecast based on solid statistics.

Answer 5

Your success as a PM depends on your ability to create a bond of trust between the team members. Everyone on the team should feel and believe that truth, cooperation, and mutual support are values shared by all on the team. Throwing your tardy team member "under the bus" will destroy that bond.

Instead I would have a one-on-one with that person to understand what obstacles they faced that prevented them from meeting your expectations. Be willing accept and admit your role in creating those expectations. Recall the original agreement assigning the work in question. Was it SMART? Ask what they thought would help them better deal with the obstacles they encountered.

At the next stand-up or retrospective meeting, you and the tardy team member state the facts and aforementioned obstacles. Let the needs of the situation speak for themselves without judgement on your part. This should be done in a routine manner at the daily stand-up meeting rather than a special event/flogging. Allow the team to self-organize the recovery plan so the entire team owns the situation, not just you or the tardy member. Set the grounds rules that we will keep the discussion positive and comments brief. Ask all to use "I statements." This will reduce the projection of judgements and emotions they are moved to share. If team members start blaming, remind them that we all share in the consequences for the situation.

Lastly I would end with the adage that "Bad news never gets better with age." If anyone is having trouble at any time, they should speak up immediately so that the team can deal with the situation. The longer problems are hidden, the fewer our options for corrective action, and the more difficult our recovery.

If you take action without team consensus, the team morale will suffer and your action will appear arbitrary. However, after repeated missed deadlines and efforts to support this person, your team will likely realize that your tardy member is not up to par, and they will "vote them off the island." With that consensus, your job as PM will be to make it so. Team members may be saddened (or not) the departure, yet they will know that they (and you) have done all that is reasonable to help their former colleague succeed.