Maintenance project with insufficient staff - what should PM do?

Question

There is a project with huge technical debt which is currently in maintenance phase. However because of the technical debt a lot of effort is needed to keep the thing running - 3 people should constantly work on fixing bugs to deal with workload.

The issue is planned budget for maintenance is about 50 hours per month which is far less than what's really needed. Now:

• The sponsor expects maintenance budget won't be exceeded
• Development team director don't want to assign more than a single person to the project as planned work can barely fill 1/3 of developer's time
• The client expects maintenance work and bug fixes won't be delayed whatsoever

What should PM do?

Answer 1

Well, I pretty much disagree with eco. I believe that if things are at risk, the PM needs to act - and fast!

1st - Identify the reason behind this problem

It seems to be one (or maybe more than one, hope not!) problem somewhere that needs to be addressed for further cycles:

• OR the project has been presented to the sponsor in an over optimistic way
• OR there are far more bug to be fixed that initially expected
• OR the development team is performing below expectations

Either way, the PM needs to identify where the bottleneck lies. Once identified, take notes and keep it. We'll use them very soon.

2nd - Make the team / managers aware of the scenario

Ok, back to the current scenario. Now that we know where the problem lies, is clearer what needs to be done. We can't expect that bugfix guys will be available, so the PM needs to know how much can be done having 1/3 developers working on development. Gather all this information and formalize it, having a clear and realistic meeting with your managers about the problems. You need to clarify where (from the above items) this scenario came from. This meeting will be a post-mortem meeting (since the deadlines are pretty much in risk) so next time the PM will need to act as soon as he believes something will get out of the track.

3rd - agree with the client what must and what may be delivered

Your managers are aware of the problem, now we need to deal with the client. This meeting will be tuff. You need to provide the necessary information and agree with them what are the main developments to be delivered (based on the 1/3 resource).

They won't want to take anything out, but if the scenario is as you stated, delays or partial deliveries are a fact. Having the list of must-have, the PM will take a list of nice to have entries, in an optimistic case where the bugfix guys have time to do some development.

At this point, the clients have only two options: partial deliveries or delays. The PM needs to feel the best approach to propose to them (I'd go for partial deliveries, as above).

4th - Avoid this problem in the future

There are problems with the communication, estimation, development, bugfix, or all of them. The PM must identify them ASAP and act to have them solved (or mitigated).

Bottomline

Everything can goes wrong. It's IT, for God sake. But, the PM must act as soon as an unexpected scenario arrives, and the first action is communication. Letting everyone know that a storm is coming, they cannot blame the team / PM for problems (basically because the PM had already alerted about them).

A ps.: The PM is also a developer's agent. Thus, if the PM will have a long term relationship with the developers, his duty is to not expose them, but also acting very effectively when something goes wrong with a developer. If the relationship is a short term... he must not expose them either. :)

Answer 2

Sometimes a PM needs to get out of the middle and bring all interested parties together, in a single room or worst case conf call, to discuss the current state and the on-going plans. Cash is and always will be king, without sufficient funds resources can not be allocated - period. I'm not sure of the history of how the project 'failed' (did not meet expectations), but that's history and can't be changed. The focus needs to be on what steps to take to ensure the most benefit is derived from what there is OR worst case close it down (if it's found the best tool is another tool OR no tool - i.e. - the delivery has negative overall benefit).

SO -

• schedule a meeting with all Sr. team members, sponsors, etc.
• present the state of health for the project - very objectively
• discuss what can be done within the given budget and the priority of how the outstanding items/issues should be addressed (high level)
• discuss what the sponsor NEEDS to have done and when (upcoming events, etc. that impact the system's use or needs)
• open the floor to the IT manager and sponsor on potential solutions and track the conversation, next steps, etc..but start to identify who the problem owner(s) are and make sure they take responsibility (for example the sponsor might need to get more funding - it's the sponsor's problem and you - the PM - need to follow up on the progress of that

Answer 3

I honestly don't see that much to do, beside tell them being explicit on what's going to happen, fail their expectancies (giving the best and solving bugs with higher priority oc) and see if they want to find a proper solution.

This sounds like software/web development, being in rush prj refactoring becomes often a too much expensive luxury.

Answer 4

It's all about risk versus cost management.

Have risks been fully identified? Have consequences been assessed? Are the risks manageable? Is the cost associated with those consequences justifiable? Is the cost of a heavier maintenance option justifiable? Are there procedural ways to address the risks? Have the risks and consequences been formally recognised and endorsed by the sponsor?

The role of the PM is to provide all the relevant information so that the sponsor can make an informed decision. If you cannot be faulted for identifying the risks, consequences, and mitigation options (or absence of), then you have done your job, the ball is in the sponsor's court, let them decide.

Answer 5

I reckon the first thing for the PM to do is take a long hard look at the risks caused by the lack of resources being allocated to the project. If these risks have a high probability and impact, there may be a strong business case to be made for a follow-on project to fix the problem once and for all. Sure, there will be a cost of doing this, but the benefit could be massive by comparison (hopefully), through reduced ongoing maintenance and a better platform for future development. With such a cost/benefit case out in the open, it is relatively easy for the business to make an informed decision.

At the end of the day, the PM's responsibility is to do whatever (s)he can to deliver the project, but if this can't be achieved, it is also the PM's responsibility to flag the issue up to the Sponsor. If the Sponsor won't accept what the PM is saying, that's a different question entirely. Certainly, in Prince 2 terms, the Sponsor (or Project Executive) has the responsibility to take any issues that exceed defined tolerances to either the Programme (rather than Project) board, or to the corporate organisation. Even if that's not relevant in this situation, I guess there will be some corporate responsibility that the Sponsor has.

My final comment on this is that the PM should keep a record of all such conversations in the project diary or elsewhere, so that if challenged, the trail of events can be evidenced.