hi
I've just been assigned to a set up a maintainence and support team . After spending a couple of days with the team just to understand where we are.there are around 130 appl, though small ones but without any docu. I have to present a plan to the mgt , regarding the process which should help us to establish this team.
I can think of things like getting docu in place, studying the past ticket details , etc.
Earlier the same team whas been handling the development of these aplications and now we've a seperate maintainece /deve team
Can anyone help me with some more inputs . pl suggest the approach that should be ideal for this situation. We'r planning to have 24 x 7 support in over a span of 2 mnths
Appreciate any inputs in this regard.
Saving Changes...
Sort By:
Javier CitalanExecutive Director| JPMorganChaseDallas, Tx, United States
I would recommend listing all of the applications and collecting additional feedback regarding how these applications support "critical" business functions. You can do this by meeting with the main stakeholders of these applications (preferably business users). You should also categorize by departments and specific critical times (i.e., accounting app for month-end processes).
You can also create a matrix identifying how these apps depend on some of the other apps in order to develop a priority list. Developing a priority list will help you when analyzing resource requirements for the 24X7 support and implementing a Service Level Agreement (SLA). In other words, if an application needs support or development resources, which application will be #1 vs. #130? And more importantly, what agreements do you have with the business community to fix a problem? Or the length of time this application can be unavailable to the users?
I would also suggest considering the ownership of applications by a functional team that includes both development and support resources (perhaps creating 1st, 2nd, and 3rd level development/support teams). Maintaining ownership of an application by team improves your support time and knowledge transfer requirements otherwise needed with separate teams. In my opinion, this reduces confusion to determine whether a software fix requires support or development resources.
Another interesting aspect of these kind of projects are unavailability of the core team who initially designed the system. So it is very important to make sure their support is available specially in the scenarios where the documentation is not available. However this team then will not have to be there on full time basis. Also as and when the support activities are carried out its important to start documenting them. So future activities on similar areas will have some documentation support. Saving Changes...
Bipin Lekshmanan PMPProject Manager| Wipro TechnologiesEdison, Nj, United States
I hope you will have access to historic data to many of these applications on support usage. Those information can guide you in understanding what are the critical/most used applications and how to prioritize them from a support angle. You can even renoegotiate the SLA's applicable at that point.
Hope this helps! Saving Changes...
