Motivation &
Competitiveness Framework
for Application Support
Teams
Paper
By Piyush Shankar Garg
& Sandeep Jain
TATA Consultancy Services
C - 56, Phase 2, Noida
India
Mailto: [email protected]
[email protected]
Website: http://www.tcs.com
1. Introduction...3
2. Challenges for Support Projects...4
3. Need for Motivation & Competitiveness Framework...5
4. The Framework...5
5. How to Implement the Framework...8
6. Conclusion...9
Motivation & Competitiveness Framework
for Application Support Teams
1. Introduction
In today’s business world, the biggest challenge for project and program managers is to keep high motivation levels of application support teams who are doing support of legacy applications. As per the studies, 40-50% of IT projects world-wide are in the area of supporting legacy applications and some of them are mission critical applications for customers of IT consulting organizations. A typical support involves providing following services to end-users or customers:
• Incident Management - While using application, end-users may face following categories of issues:
• Application Data set-up issues
• Hardware, Network and System Software issues
• Database Tuning issues due to slow performance
• Data corruption caused due to wrong application usage
• Data corruption caused due to migration and cut-over issues
• Data corruption caused due to residual defects in application software (which have not been detected in SDLC)
Most of the incidents (except hardware, network and system software issues) are resolved by application support teams by providing a data fix so that end-user can proceed with subsequent operations or business transactions. Most of the customers need very aggressive service level agreements (SLAs) for incident resolution due to business continuity.
• Problem Management – While analyzing recurring “incidents”, support teams need to investigate the “root cause” and investigate whether issue relates to a residual defect in application software or not. Tasks under problem management categories are as follows:
• Provide Fix for residual defect reported
• Quality Assurance of a release or patch (comprised of one or many fixes) and installing the release in production environment Data corruption caused due to wrong application usage
• Perfective and Preventive Maintenance – While above two services are mainly “reactive” in nature, however support project also require perfective and preventive maintenance. Support teams identify weaker areas of application on a continuous basis (depending number of residual defects reported) and plan regression testing or application software improvement tasks.
Customers & IT organizations follow a “n-layered” support model (i.e. business help desk, IT help desk, application & production support teams) to provide solutions to end-user problems which are raised normally as a “ticket” and assigned to appropriate team for resolution.
However, due to very nature of application support work – employees working in these projects do not feel motivated while working on these legacy support assignments as
they feel that after a certain time – nature of assignment will not add any value in shaping their career for new technology areas. Lack of motivation impacts “service level” provided to customer (and in turn loosing customer confidence) and also results in high employee attrition.
There are two substantial challenges that IT organizations need to overcome while managing large support projects. The first is to establish a model that helps to create motivation and healthy competitive environment among various teams supporting a particular project so that they can “own” the overall performance of support project team and visualize contribution of their unit/module team in the success/failure of project results. The second is to establish a framework to provide continuous opportunity for building and developing individual competencies in the emerging technology trends. This paper will address above two challenges by providing a “robust” measurement framework which can be implemented easily in large support projects and help the IT organizations to have “motivated” teams while supporting legacy applications.
2. Challenges for Support Projects
From the service delivery perspective, IT support projects have many challenges which can be described as follows:
1. Efficiency: A typical support model has multi-layers to provide support to end-users of applications i.e. business help desk, incident support team and problem support team. The key to success of support structure lies in minimum number of “open tickets” across all support layers at any given point of time. Efficiency of Support team is a critical factor to meet this challenge.
2. Agility: One of the key challenge to make support model successful is to have increased responsiveness. Normally, customer defines aggressive service level agreements (SLAs) for support teams as part of contract. Turning around the tickets within agreed SLAs always become the biggest challenge for the support team. 3. High Availability of Application: Global applications have requirement to ensure
availability of application in almost 24*7 mode (> 99.9% availability). To meet this objective, It is very important that “support releases” (collection of ticket fixes solved by support teams) are very stable and reliable when these are applied in production. Therefore, Quality assurance of ticket fixes becomes the key to provide highly stable releases. Moreover, ticket fixes should not result into introducing “new” problems in the live application (Fix one problem, introduce many more).
4. Team Motivation: Application support teams work under tremendous stress and strain due to very nature of role and aggressive customer demands. It is mainly due to long working hours, working in shifts, and providing support as per customer time zones. The problem is also compounded, as employees perceive work as un-interesting as legacy applications are based upon old technology. Also, due to repetitive nature of work (as compared to bespoke development and product customization assignments), after certain period -people gets frustrated while working in these assignments. Majority of IT companies leverage the offshore capability to support the legacy applications due to lower operations costs and sometimes it result in communication problems as well. Due to slow initial learning curve and to ensure best support services (as applications are complex), employees are allocated for a comparatively “longer” period in such projects and “Job Rotation” becomes a key issue.
“Low Team Motivation” caused by above factors becomes difficult nightmare for project manager(s). Despite having robust support processes, support services are impacted and in some cases – “loss of customer” becomes a potential risk factor.
3. Need for Motivation & Competitiveness Framework
Professionals tend to exhibit certain behavioral characteristics. They need continual challenge, personal growth, and eagerness for visibility, clear goals, and continuous performance feedback. A less than fully motivated team will be a competitive disadvantage for any business organization. For application support type of projects, productivity and quality are correlated with the degree to which the team is engaged and committed to the job at hand. Therefore, it is very important to have a “Motivation and Competitiveness Framework” for IT Application Support teams which can result in high morale of team. It will help not only in providing best services to customer but improved employee morale will also result in alignment of individual’s career objectives with the organization objectives and employee attrition will be reduced. The framework should be based upon following pillars:
• Clear Goals
• Continuous feedback
• Rewards
• Participation in Decision making
• Autonomy with accountability
• Varied Work and Growth Opportunities
This paper attempts to describe a very simple framework that can help to improve employee morale and create healthy competition among various teams.
4. The Framework
This paper attempts to define a framework/model which can be implemented in support teams very effectively to increase motivation levels and healthy competitiveness among various sub-teams (assuming that large support project teams are divided among various sub-teams or modules to provide support for a particular area). It will help employees to own performance data of each sub -team and aligning it with overall objectives of the project. Moreover, some of the parameters of this framework will ensure that team leaders are ensuring continuous growth of employees in new and emerging technology areas.
This framework will help to compute “Sub-team Performance Factor [SPF]” on the basis of various parameters that are aligned with challenges of any support project and results will be shared with the support team on a continuous basis [e.g. monthly]. Continuous sharing of these results with entire team will create a motivating, transparent and competitive environment for various sub-teams and team members of respective sub-team will endeavor to put their efforts to improve SPF. Following parameters are used to calculate SPF.
1. Efficiency: This parameter is calculated as percentage of total tickets actioned by a team in a period divided by [open tickets at the beginning of period + Incoming tickets during the period].
EFF = (Total Tickets Actioned during a period)*100
(Opening balance at the beginning of period + Incoming Tickets during the period)
2. SLA Compliance: This parameter is calculated to measure ‘agility” of each sub-team and is calculated as percentage of total tickets actioned by a sub-team within agreed service levels with customer divided by total tickets actioned by the team.
SLACOMP = (Total Tickets Actioned within agreed SLAs)*100 (Total tickets actioned)
3. Productivity: This parameter is calculated to measure average “productivity” of team on the basis of resources allocated to team. This is calculated as “Total number of tickets actioned” divided by ‘”Total effort put by team [e.g.person-months] during that period. It will provide view of “effective utilization” of resources within a sub-team.
PROD = Actual Productivity [Tickets actioned per person months]* 100 Target Productivity
4. Correct Fixes: This parameter is the most important factor for ensuring application stability in production environment. One bad fix might result into outage in the system impacting thousands of users and critical business operations of the customer organization. Therefore, It is very essential that support teams are encouraged to “build” a culture of delivering correct fixes in the first instance.
Failed Fixes are categorized as follows:
4.1 Defects found during internal quality assurance process of software fixes supplied [IQADEF]
4.2 Defects found as “Failed Fixes in Production” i.e. software fixes which did not work as per requirement of original ticket [FADEF]
4.3 Regression Defects i.e. software fixes which worked correctly as per original requirements of ticket but might have introduced another problem(s ) in application [REGDEF]
Total Failed fixes are computed as follows: TOTDEF = IQADEF+FADEF+REGDEF
Therefore, Correct Fix % is calculated as follows:
CORRFIX = (Total Tickets Actioned during the period – Total failed Fixes i.e.TOTDEF) * 100 / (Total Tickets Actioned during the period)
5. Residual Defects: One of the major critical success factor for support project is preventive and perfective steps taken by teams to stabilize their respective modules (rather than working in “corrective maintenance mode” where team supplies software fixes against raised tickets only). As part of preventive and perfective maintenance activities, teams identify relatively weaker areas of respective modules [on the basis of incidents & tickets reported by end users] and plan additional regression testing/ code refactoring on a continuous basis on their own. These activities help to stabilize applications faster and results are
visible from the “residual defects” reported from the live application [i.e. declining trends of tickets]. Residual Defects can be calculated as Tickets per unit size [Tickets per Function Point OR Tickets per KLOC]. This parameter can be measured as:
REDDEF = Target Residual Defects for Application for life cycle * 100 Cuml. Actual Residual Defects for module
6. Support Size: This metric is a measurement of application stability, supportability and to some extent indicator of project profitability for the IT organization. It is measured as “average application support size supported by each team member” [FPs per support person or KLOC per support person]. Target for this metric can be benchmarked against support model advised by Caper Jones. As the application becomes more and more stable, support size should increase.
SUPSIZE = Target Support Size (i.e. size supported per person) *100 [Application or Module Size/Team Strength]
7. Competency Building: Major critical success factor for having good motivation of team members will be to build their skills in emerging technology trends by nominating them for good training courses. This will help employees to build and develop competencies as per their own “career” plan and organization “future” needs. On release from their role from support teams, they will be all set to take roles on projects requiring emerging technology. Effectiveness of nominating people for good training courses can be measured as:
TRGEFT = Actual Training days [Training days / person months] *100 Target Training days [Target Training days / person months]
However, organization also need to ensure that people from support teams are rotated continuously into “development” projects of emerging technologies on completion of support assignments and after achieving desired “competency” levels in that technology through training. Lack of organization commitment in this aspect may cause de-motivation to employees.
An empirical formula (as per weightage assigned to each above factor) is used to calculate SPF:
SPF = w1 * EFF + w2 * SLACOMP+ w3 * PROD + w4* CORRFIX + w5 * REDEF + w6 SUPSIZE+w7*TRGEFT
Where, w1….. w7 are weights assigned to individual factors [between 0 and 1] depending upon the type of support project and relative importance of above parameters in the context of a particular support project. However, recommended values for a typical medium size project are recommended as follows:
5. How to Implement the Framework
Support Project Manager or Team leader needs to implement above framework at sub-team level in the project. Normally, a typical project is divided in many application areas and a particular sub-team provides support services for a particular application area or application module. The recommended steps to implement this model are as follows:
• Define and implement data collection and analysis framework to capture data for different metrics described in previous section (ideally, it should be generated from data collection tool which is being used by team for project planning and tracking perspective)
• Explain the model and rationale to the entire support team with a perspective to have shared goals and vision and to create a competitive environment. Reward schemes and performance appraisals can also be linked to this framework.
• Establish process capability baselines for each metric and define stretch targets. Targets need to be shared with the team and these should be used while calculating various metrics described in previous section.
• Performance results of various sub-teams need to be communicated (using SPF and other parameters defined in section-4) across the project on a regular basis (e.g. monthly) so that “Healthy Competitiveness” can be created in the project. Project Manager can also provide guidance and his experience to the teams performing low so that they can improve score in the next review cycle.
Once this framework is implemented, people can start owning performance data of their respective application area or module and work out a continuous improvement plan for “bottleneck” areas so that they can also target higher SPF and better relative rank. A ranking system can also be established for various sub-teams depending upon respective SPF. To enhance motivation of employees, reward schemes could be put in place for teams coming up with good ranks on a continuous basis. In fact, module leads can also implement same framework at individual employee level in their respective modules to identify process and people improvement areas. This can act as a “good scorecard” at various levels of typical support team (individual, sub-team and project team) which can help in aligning entire unit performance. By implementing this framework, project manager can act as a good coach by becoming “Prime cheerleader” and “Prime Critic”; demanding and supportive for their teams. Since the results are very transparent and shared with respective teams on a continuous basis – the results can also be used at the time annual performance feedback and appraisal of employees. Due to transparency in the process, people will also accept “manager’s” view on their performance in a positive manner. As implementation of this framework becomes mature in the project, target for individual parameters can be further refined on the basis of improved process capability and stretch targets provided by the customer or organization.
6. Conclusion
We believe that above framework can be deployed successfully and effectively in large support projects where motivational issues exists. Deployment of this framework and commitment from top about future growth of employees [by providing them continuous opportunity in getting training for emerging technology areas and assignments after completion of their role in support projects] can create a “highly motivating environment” and “high competitiveness” in stressful environments of large support projects. As a result of this, IT organizations can provide “best services” to customers and can retain experienced and loyal employees. The framework can be extended to multiple support projects as a tool to create motivating and competitive environment across the organization.
