5

Is it ok to communicate that a project is delayed due to a team member being sick? The reason I ask is because to some extend I feel it sounds pretty bad. But maybe there are some way to communicate it better than saying "sorry we're late because the main programmer puked all day and is unable to write a line of code". How do communicate a delay due to a sickness within the team? Examples/Specifics are welcome.

Thanks

Johann Savalle
  • 73
  • 1
  • 5

3 Answers3

6

It's not only ok, it's a bad idea not to.

Be upfront and apologetic. Most importantly be ready to update expectations.

Good luck.

Myles Horne
  • 168
  • 7
5

If this is the driver why you are running late, then you must communicate it. However, in doing so, you will be exposing your lack of risk planning. This is one of the most basic threats to any project or operations. It is an organic risk and should have already been mitigated via back-up resources to eliminate a single point of failure and / or contingency reserve to buy down loss when you have an illness on your team. Too late, so you need to communicate. Then go fix your risk capabilities.

David Espina
  • 37,143
  • 4
  • 34
  • 91
  • Right, the logic is clear, and I did exactly that. My question is how to communicate in the best way for the client to move along with it. Good communication and how you present the information is as important as the technical part of the execution (like logistic and staffing to ensure good capacity) – Johann Savalle Aug 10 '14 at 12:15
  • 2
    I thought your question read, 'is it OK....' By how do you mean verbally, in writing? You report variances in your status report. Do it there in a factually, non defensively, unemotionally way and be transparent in the poor risk planning done and how you will fix that moving forward. – David Espina Aug 10 '14 at 15:12
  • Great answer to think of. I remarked with external customers, they don't even care who is behind the walls of the provider. They recognize authorities and team from SOW and kick-off meeting. They know that they will be involved and communicated properly. Other PMs do not communicate more of what s expected in the status report. The acquisition and staffing is upon the provider and exposing this to the customer could be taken as an unacceptable excuse for the delay. As you said, it is an exposure to lack of risk planning. – Maximus Decimus Jul 17 '19 at 18:11
  • However, I think if it is an internal project, then it could be different because of the organizational structure and authority level. If resources are in the control of another authority or even in PM's authority, then I think it would be better to indicate that there is a missing resource and something is being done already to keep/recover everything on track. It is not only the excuse/complain, but the solution. If the relationship with external clients is close, then I think the PM can share the issue + solution + apologies. – Maximus Decimus Jul 17 '19 at 18:11
0

Even when one programmer is not available, the team should be able to recuperate by pulling in another programmer.

We follow pair programming in our company and even when one programmer is not available due to any organic risk or unplanned reason, the other programmer will be able to continue alone, this ensures that there is no high impact on the project.

While communicating to the client, I would follow this template:

  • Mention the absence of the programmer.
  • Convey the impact.
  • Mention the plan for compensating for the delay. (If was included in the risk planning, mention that it doesn't have any impact.)
Arun614
  • 24
  • 3
  • I disagree. Devs cannot (always) compensate the lack of a teammate. Even if all developers have the same skills, it's one dev less. You will feel that. External devs will not compensate that, in the short run. Overhours should be avoided. Talk to the customer! – Sven Amann Aug 25 '14 at 15:21