I have a few core team members who also look after daily support. It’s not uncommon for them to get stuck in some firefighting for a day or two which completely throws off a project schedule. How can I keep my stakeholders from getting frustrated every time the date pushes back?
Add a comment
|
4 Answers
When possible, make it visible to the stakeholders why the release date is being pushed back.
If it's in order to fix their own products, then they should naturally be less frustrated. It's even possible (if unlikely) that they could decide that the new development is a higher priority than the 'fire', thereby changing your priorities - it's good to give them both this ability and priority.
If it's in order to fix another client's products, then a skilled communicator may be able to spin the situation in such a way that the stakeholders become impressed with how seriously your team treats maintenance/support for existing customers.
Of course, this is mitigated if you're constantly pushing everything back because everything is always on fire. In which case, you need to start being more realistic; stretch your project schedules more from the start, and allocate more time to baking quality into the products (e.g. in the case of software, reducing technical debt).
If you are using a tool to keep the tasks such a Jira, try to setup your project in a way that stakeholders understand the capacity and the type of activities that your team is working on.
Also, if possible make an estimate of how much "firefighting" is costing, include not only the time invested on doing the tasks, but the cost of the delays of this tasks.
It’s not uncommon for them to get stuck in some firefighting for a day or two which completely throws off a project schedule.
This shouldn't be common, this is a smell of a bigger problem happening, while you figure out, I suggest that if possible you should:
- Estimate firefighting for each sprint
- Assign a team specifically dedicated to tasks that are not firefighting and other team that'll need to work on firefighting
answered Jul 30, 2018 at 16:45
On my team, we resolved this problem by assigning 1 volunteer (rotate each sprint, so everyone on sprint team has to play this role sooner or later) from sprint team as support-go-to-person for the sprint.
Any sprint story-points (i.e., work) delivered by this volunteer was considered a sprint bonus.
This person may or may not have all the skills required to solve all the problems. The person we expected to co-ordinate and request help as and when necessary. Team was encouraged to develop an ability to deliver support by learning from each problem.
In addition to the above; make a guess of how much firefighting is being done (in "time lost firefighting per time unit") and take it into consideration when determining when things are done.
If on average you lose 3 of your 15 man-days per week due to firefighting, that means you can extend all your deadlines by 25% and you should have a more accurate idea.
You need to account for all your (roughly) expected activities during the time working on a project when setting a deadline, not just a hopeful "each person equals 40 hours of work per week", or all your deadlines will be unrealistic.
