Project Management for Maintenance Projects

[A0C61ZZ]

Hello,
I've been asked to manage a project by my company for our client and this includes maintenance & production support for existing 10 applications (which includes a plethora of technologies ranging from COBOL, PowerBuilder to Java/JXB ) in the finance sector.

The applications as such are very much crucial and form the backbone for day-to-day business functions and there is no robust failover policy in place. The approach is mostly troubleshoot as you go. The client mgr is not willing to share production support with any other members of my team except a couple of us, whereas my contracting company mgrs would like to have production support distributed amongst all other members.

I see the client mgrs point very well (as prod support in too many hands has its own risk). How should I approach this specific situation?
Thank you

 

[thedaver]

First, this is NOT a project. This is a contract, a program, a support arrangement... This is NOT a project.

OK, now having done that, he's a little more insight. First, the Finance teams of every corporation I've been in have always had an insular attitude that borders on cases of paranoia. Perhaps rightly so, especially in this world of Sarbanes Oxley compliance... Generally Finance doesn't like to play along with other IT strategies when it comes to their core systems, uptime, and support....

So what do you do? First, fully define what their expectations are for the "maintenance & production support for existing 10 applications". Start at a high level and get yourself to SLA-level terms: how rapid a response, what skills are needed, what Disaster Recovery obligations are they looking for? What kind of bug response are they needing? Backup and recovery: backup cycle, time to restore any particular dataset, offsite backup, restore point objective (how much data can be lost between now and what's available from the best available archive)?

Basically you need to spell out the requirements that they are going to require from a team. THEN, and ONLY THEN, can you begin to align your team's capabilities, skills, and projected expenses of providing the services to their original list.

You may find that your EXISTING team is capable of providing 80% of what the Customer needs; that leaves 20% to be negotiated over between additional cost for you to add skills/resources and them to reduce scope or slacken their SLA requirements.

You should also deliberately build in periodic (monthly) meetings with customer to discuss existing arrangements for support, performance, new/reduced scope, planned DR tests, planned restore tests, user training in readiness for DR events, costing relative to expected levels of service/hours used.

Finally, given your picture that you have a "small" team relative to a potentially wide base of required skills, many responsibilties, and DR commitments, you need to think through scenarios such as: your staff taking vacations, disaster scenarios that prevent workers from being available, disaster scenarios that prevent access to some or all networks/applications, people quitting service or being transferred, etc.







D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[planetant]

dave, what're you using to track tasks in this case?

 

[thedaver]

Support ticket system for things below any specific hourly threashold to repair them. Items that are bigger effort spawn new projects. The ongoing tracking of micro service requests are an ongoing program of effort, tracked through a system that best facilitates the support team's needs (owner, status, age, description, cost, priority, etc.)



D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/