make IT strategic - English blog notes

Program Management is the process of managing several related projects. In the recent years this new dimension of project management has been professionalized. For instance, the Project Management Institute does now propose credentials related to Program Management.

Whereas project management is focused on executing projects right, meaning on time, on budget and delivering required quality, the program management discipline will follow complementary objectives, such as, evaluating the value added of each project of the project portfolio, and potentially decide trade-offs that may conduct in reassigning resources, stopping projects.

A.C.C.E.N.T. describes the six main activities that a Program Manager should focus on when leading his program.

Anticipate. A program manager should above all be a visionary. He’s the one who will implement the long term strategy defined by the management. Therefore, his role will not be focused on ensuring that detailed work of each project will be done the right way, that’s the role of his project managers. He always has to look for the later stages of project execution, pointing project manager’s attention to the upcoming activities for which key dependencies or management decisions may affect to some extent the achievement of the program’s long term goals. Anticipation is also illustrated by a proactive management of program risks.

Communicate. This duty is common to both Project and Program Managers. It’s an accepted statement that communication is the job #1 of Project Managers. For Program Managers communication is even more important. Because Program Managers will constantly need to ensure top-down and bottom-up communications between the Management, the Customers and the project execution teams through his PMs. Communication is much more than mail forwarding, the Program Manager shall be more than a simple routing mailbox. We would rather compare the Program Manager as an advanced filtering and broadcasting machine. He shall communicate to the management and the Customers relevant program/project, escalate whenever appropriate when decisions are required. On the other hand, he’s communicating key decisions or information from the management and the Customer that his PMs shall know in light of their respective projects.

Conciliate. Diplomacy is probably one of the most important soft skills of the Program Manager. He will very often get escalations from his Project Managers or issues requiring resolution or arbitration. Obviously the Program Manager has to be a program leader, and he needs to make decisions that project stakeholders will apply. Taking people to jointly agree on what the best decision should be for the sake of the project, and therefore of the program, will be much more effective than forcing it.

Evaluate. Evaluation is also a common duty of Project and Program Managers. However, the items on which evaluation will apply are different. Whilst the Project Manager will constantly evaluate his project activities, assessing earned value and cost/time impacts, evaluating risks and their impacts, the Program Manager will evaluate how his individual projects will contribute to the long term journey of his program.

Negotiate. Programs and projects are obviously not straight forward and don’t evolve in a neutral, independant and apolitical environment. Scope creep is the first collateral damage of this interaction between projects and their environment. At the program level, the political dimension takes another extent. The Program Manager will definitely require to negotiate with his management, his Customer but also with his own Project Managers in order to maintain a balance between the diverging stakeholders’ interests. Our Program Manager machine is also a very powerful balance.

Track. This is common sense activity that comes to people’s mind when they’re asked what a Program Manager should do. Though the detailed follow up of each project falls under the responsibilities of the underlying project managers, the program manager has to keep track of the health of each project and provide a consolidated view of his program to the management. A regular, but quick, follow up of each project with the PMs is therefore mandatory to keep a close link between the program manager and his PMs.

When rationalizing IT support activity, the main focus is often put on the help desk. Therefore, companies organized in small, individual support teams are lead to structure their IT support by putting in place a more formal and standard IT support structure. The first level of this structured support team is the help desk. Dedicating teams to take user calls to troubleshoot incidents or deliver IT services is a best practice implemented by most mid-size and large companies today. Structuring a unique Service Desk using ITIL best practices to manage calls and incidents is an efficient manner to provide consistent IT support to the entire end user community.

Once the help desk has been setup, companies usually tend to optimize their teams and level resources to optimize IT productivity and limit support costs. The trend in the past ten was to outsource first level support to low-cost countries such as India, Maghreb countries or East-European countries.

But how do end users experience this transition from local teams to structured help desks, then to outsourced platforms? The main issue of Help Desk managers is to put the right balance between cost and quality. I will describe further in this post a proposed project approach to deal with quality issues at the Help Desk.

Step 1 - which quality issues?

What do we mean exactly by quality issues? This is the first topic to deal with. If the Service Desk was structured using ITIL best practices, Help Desk performance is likely to be challenged against Service Level Agreements signed with the customers – business units, departements, etc. But even if formal SLAs have been implemented, such as 95% of low priority incidents resolved in less than 10 hours, reaching formal SLA objectives is not synonym of quality. For instance, this latter SLA could be reached, but 20% of the calls may be closed without being properly solved, requiring end users to open new tickets. Another example: users may complain about poor communication skills of the help desk agent they were in touch with: bad accent, no customer focus, no empathy… Therefore, one essential factor to take into account, in addition to formal SLA objectives, is the measure of end user satisfaction.

Identifying root causes of quality issues is a complex exercise, and must take into account interviews with help desk leaders, customer representatives but most of all end users who are facing the help desk. An Ishikawa cause-effect diagram may be used to represent all possible reasons for low quality and track root causes.

Step 2 - identify most relevant improvements

Depending on the root causes identified at the previous step, you may focus on actions to improve agent skills, or improve user experience with help desk. For this purpose, you may settle workshops with Help Desk managers and end user focus groups, in order to assess what improvements will bring the best results to improve help desk quality, based on the root cause they’re supposed to mitigate. I strongly highlight the importance of challenging the possible candidate initiatives with end users from the “real world", and asking to users if implementing those will have a positive effect on their satisfaction and experience with Help Desk.

Analysts have put a strong correlation between user satisfaction and the First Contact Resolution rate (FCR). This rate expresses all possible ways for users to resolve their issues during their first contact to IT, whichever techniques are used: phone, web, self-service tools, chat, etc. This latter KPI may not be expressed as such by end users, but may have a real positive impact on perceived end user satisfaction.

Step 3 - define relevant metrics to measure improvements effectiveness

Before starting to implement the most appropriate countermeasures to improve Help Desk quality, I strongly advise you to think about the evidences that you’ll need to show in order to prove that such measures were effective. Let’s assume that one of the root causes identified was linked to improving communication and empathy skills of help desk agents, and that you have decided to run a series of trainings to work on that specific topic. How will you measure the effectiveness of this action? Thinking on KPIs before implementing the action may avoid you spending money on actions and keep your management dissatisfied as you’re not able to show the benefits of them. So ask you the right questions: is the KPI a good reflect of the improvement I am about to implement? Can I measure this KPI? Is this KPI valid for IT Management and/or end users?

Step 4 - implement improvements

This is a standard change management activity, so I will not detail this part too much. The only thing I will stress is the importance of communication in those activities, both towards the end users and the IT Community. Improving organizations requires a strong Organizational Change Management focus and the main role of the project manager, besides the formal PM techniques to track costs, time and quality, will reside in his/her ability to be a powerful communicator and agent of change between the various stakeholders.

Step 5 - measure success

As we have defined the KPIs on step 3, and taken their implementation into account during the implementation phase, this step has to be run possibly BEFORE, DURING and AFTER the changes have been implemented, so that we can show some progress, and depending on the results, possibly launch additional actions to improve results.

Step 6 - start again!

Do steps 1 to 5 look familiar to you? Maybe you’ve already seen that somewhere, for instance in a well-proven technique of continuous improvement: the PDCA model - Plan-Do-Check-Act, or Deming wheel! Indeed, implementing one-shot actions to improve Help Desk quality is not sufficient. It’s fundamental to measure Help Desk quality in a regular manner, by evaluating Help Desk KPIs and end user satisfaction to track possible degradations of quality. Help desks are facing very important turnover rates, that’s even recommended in ITIL best practices to motivate help desk agents by promoting them to level 2-3 support technicians, or moving them to other silos in the Data Centers or Network teams. For this reason, the agents that were involved in your initial improvement plan are not likely to stay for a long time at their place, but may be replaced by new agents, frequently young people with less experience.

So… do we need to start the stuff another time again? Maybe an appropriate way for doing it is to settle Continous Improvement cycles, as described in ITIL v3 Best Practices, and appoint an Help Desk Quality manager who will be in charge of running those plans in a continuous manner.

References:

1. Deming Wheel - PDCA, Wikipedia

Welcome to this new blog intended for IT decision-makers (CIO, IT / IS project directors, etc.). This blog will be animated by Serge Baccou and Arnaud Bonneville, co-CEOs and principal consultants from Baccou Bonneville Consultants.