IT Project Training Guide

This list is not exhaustive but will serve as a good IT project training reference guide when planning your project. We hope you find some of the ideas useful for your next project.

• Train the help desk staff and/or training staff first
• Train support staff before implementing technology within the rest of the enterprise
• Identify other employees who need training
• Tailor the training material to the specific nature of work that the trainee will be performing on the job
• Involve support staff early on so they have enough time to order licenses, install software and make any necessary configuration changes.
• Check to see if extra licenses are included or need to be purchased to cover training workstations.
• Install training software and properly configure workstations

Make sure training staff are familiar with trainees’ work issues so they can use them in their examples during the IT project training course(s).

Don’t Short Change Your IT Project Training

Schedule the IT project training as near to implementation as possible. In the rush to make projects live, training can be one area that is cut in order to save costs or meet deadlines. So it is important to make sure stakeholders understand the cost of training, and agree upon who is responsible for paying the costs. Make the goals of the training clear. When the participants have a clear understanding of what he or she is expected to learn, learning tends to be maximised.

• Identify training program outcomes as the skills and abilities needed to perform tasks.
• Test for these at the conclusion of training
• Adjust the training curriculum to fit varying skill levels of the audience
• Create a separate training environment so training data is not put into a production environment.
• Prevent testing and development from conflicting
• Reset the training environment between courses

IT Project Training is important but can be costly so one of the ideas you can try is to produce more customised training products and cut training costs by hiring in-house trainers and setting up an initial “train the trainer” session to prepare for corporate-wide training. Remember that it is always important to adjust the training to the meet the needs of the diverse levels of positions within the organisation.

JMR Consulting UK Ltd has core project management expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key project management programs and a constant focus on our service philosophy which is at the core of JMR’s business operation.

In the last four blog posts we have looked in detail at how a Project Post Implementation Review (PIR) is conducted. We can now reflect on the main points that we have discussed. The main purpose of the project post implementation review is is to evaluate how successfully the project objectives have been met and how effective the project management practices have been. Therefore, we recommended that a project post implementation review (PIR) should be conducted after completion of the project, but before making any final improvements.

Preferably,after the system has been live enough to allow for assessments to be made about how it will perform long-term. Make sure you document the results of the PIR in a close-out report called the post implementation review report. Conducting a timely and thorough PIR will help identify lessons learned which will assist in making final improvements to the system being implemented. Elements of lessons learned will also assist in planning, managing and meeting the objectives of future projects.

Focus on the project results

So in terms of project results, you want to be sure that you understand how technically successful the project really has been in terms of satisfying all requirements and the project’s main goal. Next ensure you understand the business benefits delivered and whether they satisfied the actual intent of sponsors and stakeholders. Finally, gather lessons learned that can be used to improve the future performance of projects and individuals in the organization. Ensure you get input from:

• the entire project team
• customers and system system owners
• and other major stakeholders

The three main steps for a successful Post Implementation Review which have been discussed during this series of blog posts are:

1. Post Implementation Review Corrective actions

With the new system and business process in place, there may be further refinement or the system, process or other environmental factors that could result in increased business benefits.Your recommendations here may go beyond the original scope of the project, but be important to call out as a potential business improvement.

2. Post Implementation Review Requirements Satisfaction

Once the system has been in place for a period, everyone is better able to judge it’s actual impact on the organisation. The issues covered in this section address three major issues:

• How well do the results match the requirements?
• How well do the results match the expectations of stakeholders?
• Are there gaps in the requirements that should be reviewed?

Using a comprehensive approach to reviewing the results allows you to judge the technical success of the project, recognize gaps in requirements gathering that need to be addressed in future projects, and the project’s real impact.

3. Post Implementation Review Lessons Learned – Best practices

Lessons learned are findings that could be useful as input to future projects. Many of the items in the section above can double as lessons learned. They are particularly useful, because they offer hard measures (performance metrics) of success of failure. The approaches below involve gathering information that is often more subjective and unanticipated. It can be equally valuable and often more broadly applicable to future projects.

Post Implementation Review Reporting

Ensure that any findings and recommendations are reported with cost and future savings implications and report recommendations to both project sponsors and current system owners. It is a good idea to attach appropriate documentation, which may a useful addition (adding context or support) to the PIR such as a final Quality Assurance Report, customer survey results, etc. This enables you to constantly add to your organisation’s repository of best practices where you have something new to contribute. Document specific and unique practices and procedures that led to project successes and make recommendations for applying them to similar future projects. Finally, ensure the PIR is recorded and accessible to anyone who may benefit from it in the future.

JMR Consulting UK Ltd has core project management expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key project management programs and a constant focus on our service philosophy which is at the core of JMR’s business operation.

The last blog post looked at the project post implementation review process and how well requirements were satisfied. Here we deal with how to approach the lessons learned for a post implementation review. When identifying lessons learned, the goal should be to identify what went well, what didn’t go well, and why. At this point, you might be thinking that spending time on a post implementation review, when the next project is around the corner, is difficult to justify or convince our team that you should be doing it at all. To many people, a project post implementation review sounds like a lot of bureaucratic overhead when there are more things to do. Once the project’s finished, we’re hoping to focus our attention on something else! However, lessons learned are findings that could be useful as input to future projects and should form part of the organisations learning process.

Post Implementation Review Discovery Process:

Many of the items in the previous two blog posts can also double as lessons learned. They are particularly useful, because they offer hard measures of success or failure. Our approach involves gathering information that is often more subjective and unanticipated. It can be equally valuable and often more broadly applicable to future projects. It is important to conduct a formal lessons learned exercise with the project team, sponsors, and stakeholders. The main steps to conduct a lessons learned exercise as a fundamental part of the project post implementation review are:

• Be objective,look for hard measures and facts,make judgments on that basis
• Capture positive as well as negative lessons
• Focus on the future and not on blame for shortfalls
• Conduct a customer survey to capture information where you need statistical relevance
• Evaluate the effectiveness of the project management practices
• Focus on events and issues that were “unknowns” early in the project life-cycle
• Be sure enough time has passed to draw conclusions

Capture the most salient points for inclusion in the Post Implementation Review (PIR). It is important to solicit feedback from a diverse audience within each subgroup you gain input from. Make sure you structure the review process so that everyone in the organisation has an opportunity to review finding that may be relevant to their work.

Post Implementation Review Reporting Process

Attach appropriate documentation, which may a useful addition to the PIR such as a final Quality Assurance Report, customer survey results, etc. Add to your organisation’s repository of best practices where you have something new to contribute. Document specific and unique practices and procedures that led to project successes and make recommendations for applying them to similar future projects. Provide only the level of detail necessary to offer a meaningful analysis of events and conclusions. Ensure the PIR is recorded and accessible to anyone who may benefit from it in the future.

The value of conducting a formal lessons learned section as part of the post implementation review is helping future projects, so they will experience fewer problems and setbacks. You don’t need to wait until the entire project finishes. You could capture lessons learned incrementally throughout the project, or at least very soon after it’s over, while the issues are still fresh. In conclusion, by capturing lessons learned and turning it into project foresight, you will achieve far greater long-term success than by blissfully ignoring or forgetting problems, or by simply moving on when a project ends.

JMR Consulting UK Ltd has core project management expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key project management programs and a constant focus on our service philosophy which is at the core of JMR’s business operation.

The last blog post looked at the need to conduct an analysis of corrective actions that can be taken to refine the operation of the system with experience in the live environment with the new system and business process. Once the system has been in place for a long enough period, the post implementation review team is able to judge the actual impact on the organisation.

The next two steps of the post implementation review are to cover off three major issues:

• How well do the results match the requirements?
• How well do the results match the expectations of stakeholders?
• Are there gaps in the requirements that should be reviewed?

Using a comprehensive approach to reviewing the results allows you to judge the technical success of the project, recognise gaps in requirements gathering that need to be addressed in future projects, and the project’s real impact on the organisation. As in previous blog post we will break this step down into two process – the discovery process and the reporting process.

Post Implementation Review Discovery Process

It is important to conduct the Post Implementation Review after the project’s deliverables have been in service for an adequate period of time so that the team can evaluate the product or service’s successful integration into the business. The starting point here should be to review the project charter to evaluate how closely the project results match the original goals, objectives, and deliverables. This stage of the post implementation review process should look at the following areas of interest:

• Perform a gap analysis between planned versus delivered requirements
• Document schedule variances, their timing and causes affecting interim deliverables and the project end date schedule
• Document budget variances, their timing and causes affecting interim deliverables and the project end date schedule
• Are the level and number of faults identified acceptable?
• Are adequate system controls in place and could they be improved to reduce future risk?
• Is data integrity being maintained within the system and in relation to integrated or interfaced systems?
• Does the system process transactions at an adequate speed?
• Are staff members following critical, supportive operational procedures
• Has the system demonstrated an ability to handle peak loads expected mid or long-term?
• Have appropriate project close-out activities been completed?
• How does the actual operating cost of the system compare with what was anticipated?

Post Implementation Review Reporting Process

The main item to bring out in the reporting process is to ensure users of the system are satisfied with its performance and capabilities and to the degree they find it easy to use and better than the system and process that it replaced. Ensure that any findings and recommendations are reported with an eye toward causes (not blame, but a description of influential factors). Report findings to both project sponsors and current system owners

JMR Consulting UK Ltd has core project management expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key project management programs and a constant focus on our service philosophy which is at the core of JMR’s business operation.

In the last blog post we outlined the purpose of a Post Implementation Review and discussed that the desired outcome of a post implementation review is to analyse, evaluate and rate how successfully the project objectives have been met and how effective the project management controls have been. The best time to undertake a post implementation review is after the system has been live long enough to allow for judgments to be made about how it will perform long-term in the live environment.

The results of the Post Implementation Review should be documented in a project close-out report called the Post Implementation Review Report which should look back at the project but also be a forward looking report to try and identify further benefits that can be harvested from the system in the operational environment.

Post Implementation Review Report and Corrective Actions

One of the first considerations should be an analysis of any corrective actions that can be taken to further refine the operation of the system in the light of operational experience in the live environment. Once the new system and business process are in place, there may be opportunities for further refinement of the system, businesses processes or other environmental factors that could result in increased business benefits. It is important not to limit your recommendations just to the original scope of the project, but take the opportunity to re-evaluate the system and its operating environment and report on any further potential business improvements.

Post Implementation Review Discovery Process

Every project is different and all project post implementation reviews should be specific to the project.  The type of areas that can be looked at should include, but not be limited to, some of the following areas of interest

• Could more training improve the level of benefits delivered or reduce ongoing costs?
• Can we improve benefits delivered or reduce ongoing costs through system changes?
• Could changes in business process improve benefits delivered or reduce ongoing costs?
• Any additional documentation to improve benefits delivered or reduce ongoing costs?
• Changes to policies or procedures improve benefits delivered or reduce ongoing costs?
• Any additional support to improve benefits delivered or reduce ongoing costs?
• Could changes in staffing improve benefits delivered or reduce ongoing costs?
• Are staffing levels and skill sets appropriate to the workload?
• Can corrective actions, process and system fixes, be handled at an adequate pace?
• Is the system structured and staffed for future flexibility?

Post Implementation Review Reporting Process

When drawing up and presenting the final report, it is important to make sure that you report any findings and recommendations with cost and future savings implications. Also ensure that you report recommendations to both project sponsors and current system owners.

JMR Consulting UK Ltd has core project management expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key project management programs and a constant focus on our service philosophy which is at the core of JMR’s business operation.

This is the first in a series of blog posts on the tricky subject of Project Post Implementation Reviews. The purpose of a Post Implementation Review is to analyse, evaluate and rate how successfully the project objectives were met and how effective project management practices were. It is a key project process in the “lessons learned” process for any organisation that wants to learn from its successful projects and those projects that have been less successful. Normally, the Post Implementation Review (PIR) on a project is conducted after completion of the project, but before making any final improvements. Ideally, the project post implementation review should happen after the system has been live long enough to allow for judgments to be made about how it will perform long-term in the live environment. The results of the Post Implementation Review should be documented in a close-out report called the Post Implementation Review Report.

Post Implementation Review and Lessons Learned

Once a project has gone live and you have experience of running the project in an operational environment, conducting a timely and thorough Post Implementation Review will help identify lessons learned and previously unidentified shortfalls in the project. These findings will assist in making final improvements to the system being implemented and are useful pointers for improvements to project management practices for future projects. A thorough Post Implementation Review will identify lessons learned that will also assist in planning, managing and meeting the objectives of future projects. We will include some suggestions on how best to conduct a post implementation review in subsequent blog posts. Every project is different and whilst these post implementation review pointers are meant to be fairly comprehensive they can be adapted or altered to suit your needs, the risk profile of your project or the scale of the project.

Post Implementation Review – Focus on the project results

So in terms of project results, you want to be sure that you use the project implementation review process and results to improve the future performance of projects and individuals in the organisation:

• Understand the technical success the project
• Has it satisfied all requirements and the project’s main goals
• Judge the business benefits delivered
• Has the intent of sponsors and stakeholders been delivered
• Collect a list of  lessons learned

Post Implementation Review – Who should be involved?

Depending on the size, risk profile and cost etc, you can take different approaches to conducting a post implementation review. On very large and risky projects, we have seen an approach that involves two teams undertaking the review independently. In this approach you can allocate an internal team to drive one version of the post implementation review and an independent team to drive another version of it. The internal team normally has a deep understanding of the project and will uncover insider issues that are technically complex because they have been very close to the project. An independent/audit team can be more objective and will pick up on issues that the project team may have dismissed as a group because they have been very close to the running and delivery of the project. We have also run post implementation reviews in a combined workshop format. The main important aspect is to make sure that you get input from the:

• entire project team,
• customers (system owners)
• and other major stakeholders

JMR Consulting UK Ltd has core project management expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key project management programs and a constant focus on our service philosophy which is at the core of JMR’s business operation. If we can help you with your business or project problem then give us a call on +44 (0) 845 052 0900.

In our previous blog post we discussed an outline of a Project Risk Review process that will guide you through the main areas that your project risk review should cover. So let’s look at one aspect in particular – project risk management. You’ve just started a new project, and are feeling confident and excited about the road ahead. As a project manager, you’re busy planning timelines, allocating resources, budgets etc and dreaming up ways to make your project really successful. But don’t forget project risk management because it needs your attention. While it can be unpleasant to even entertain the idea of project risks, it’s vital to do so for the life of your project. Project risk management looks at the whole lifecycle management of threats for projects.

First of all – What’s a risk? Well in project terms, a risk is an issue that has yet to happen, but it might. Risks arise in projects because projects usually possess uncertainty. It’s important to consider project risk management so that you have a plan and can resolve any project issues that may occur. In the past, however, some traditional approaches to risk management have been met with problems. For instance, sometimes project teams come up with invalid or unrealistic risk scenarios. In addition, some risk response plans rarely even get executed so a new approach is required and we call this proactive project risk management.

What is Proactive Project Risk Management

Proactive project risk management is a more powerful and valuable approach to managing risks on projects. We define proactive project risk management as a combination of attitude and approach because the successful Project Manager takes project risk management very seriously in order to protect their own their personal bandwidth and the bandwidth of the project for when the big risk hits.  Just like insurance, the project is paying upfront to safeguard the ability to identify and address the big risks, resulting in protecting value throughout the project.

Proactive Project Risk Management starts with a plan

The first thing a successful Project Manager needs is a Project Risk Management Plan. This plan outlines how risks will be managed throughout the life of a project. The Risk Management Plan should include:

• The basics of the Process, how risks will be identified and assessed,
• How risks will be monitored and communicated, and
• How time and cost contingencies will be calculated and included in the project schedule and budget.

The Plan will need to be signed off by the project sponsor, the project leads, and possibly the project Steering Committee, if applicable. This signifies that the successful Project Manager has the support of the primary stakeholders to manage those risks and prepare for the unknown.

Project Risk Management needs to be Proactive

It is important to adopt a proactive project risk management approach and is a key process that leads to successful projects. Because all projects will be challenged at some point, Proactive Project Risk Management will enable the successful Project Manager to deal with the big, unforeseen issues that inevitably will arrive and knock the project off course. Start by focusing on the management of specific, realistic, and actionable risks. Also make sure you measure the effectiveness of these risks at the end of each project.

Project risk management is not something that just occurs at the start of your project – you’ve got to make sure you keep your eye is on it during the whole project lifecycle. The benefits of project risk management run high. Perhaps most importantly, proactive project risk management will result in a better rate of return on the overall project portfolio and there is also an improved project predictability.

JMR Consulting UK Ltd can Help with your Project Risk Management challenges

JMR Consulting UK Ltd has core project management expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key project management programs and a constant focus on our service philosophy which is at the core of JMR’s business operation.

Are you a Project Manager who loves check lists?  I’ve worked with project managers of all shapes and sizes and in many different industries, but one thing that many of them have in common is that they love project management check lists. In my experience this is because Project Managers tend to be systematic people who love to put their thoughts, ideas or tasks down in one place. Then, I have observed that many Project Managers systematically work through their various project management check lists and check them off one by one until they can really see that their job is done. In this post, we discuss the foundation for a Project Risk Review check list.

The Project Risk Review process and check list

Most projects have some level of risk involved. Do you need to perform a risk audit on your project? Here is an outline of a Project Risk Review process that will guide you through a review of the effort, documentation, resourcing, delivery performance, financial performance to date and much more. It’s not just a check list of simple measures (because every project is different) but a complete list of the main areas that your project risk review should cover.

Preparation for the Risk Review

Before we look at the areas that your project risk review should cover.  Let’s take on step back. Every project is different and careful up front planning will help your project risk review to be more successful. You can use these main headings for most projects and mix and match depending on the scope, size, risk and budget for your project. If your organisation or project is big enough or risky enough to have a Project Management Office (PMO), then the PMO function is best placed to review project risks using a consistent structured process, as outlined below. Use this process and the outline check list headings as a base to objectively rate and then manage the main categories of project risk.

A Project Risk Review Needs Planning

An effective project risk review needs to ensure that the administrative elements of the review are planned and handled correctly. The first objective of the project risk review is to understand where the project currently is, relative to plan. Ensure you gather relevant working project documents and hold an effective briefing for the review team and that you close off the project with a formal project risk review report or presentation.

Your Project Risk Review Checklist should cover various aspects of the project in detail and should include these headings:

• Delivery
• Resources
• People
• Capabilities
• Finance
• Legal
• Reputation
• Quality
• Relationship
• Process
• Management
• Client Management
• Technology
• Business Environment
• Asset Management

Project Risk Review Follow Up Action

There are many ways to conclude a review but some form of documentation, either in a report or in a presentation is recommended. The post review follow-up process should include an identification and definition of any problems found, the relevant recommendations to identify solutions to the risk areas identified during the review with some appropriate time scales that have been discussed and agreed with the project team. A project risk review process will always work best when it is seen as a service to the project team and not working against the project team.

JMR Consulting UK Ltd has core project management expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key project management programs and a constant focus on our service philosophy which is at the core of JMR’s business operation.

Good technologists will bring up these questions themselves. But it never hurts to make sure. Take the time to ask these questions and any others you can think of. Use the project as an opportunity to expand your horizons a little, and learn about how these systems work and are built. More than anything else, stay engaged in the project from start to finish.

Below are 10 important questions that non-technical project stakeholders should ask their techie counterparts.

1: How will the business communicate with the Techies?

This is a question you can ask an IT manager. Maybe there is a business analyst or project manager from IT assigned to coordinate and communicate with your techies. But if there isn’t, that task may fall to you. Some techies will be much better at understanding your “business needs” than others. Make sure that the requirements are written down and that you read them (even if they are boring!). After you read them, go over them with your BA, PM, or techie. Even just paraphrasing each requirement can help avoid costly communication failures.

2: Can I see what you have so far? (On a weekly basis)

The sooner you can provide feedback to your IT counterparts, the less costly it will be to make important course corrections. Let’s face it: It’s difficult to conceptualise how something like a piece of software will work based on written requirements. It’s only when you see it in action that you find all the things that weren’t mentioned or were, worse yet, just assumed. Ask to see the latest work — even if it is incomplete — so you can provide feedback. Maybe you will be providing feedback on a login page or a search screen that doesn’t do anything yet. It doesn’t matter. Get the team used to regularly showing you progress. Also, it never hurts if you’ve got donuts or bagels when you come around.

3: Is anything holding up the progress?

Some projects will have a full-time project manager who will be keeping careful track of open issues. If you don’t have a resource supporting you like that, make sure you track open questions and issues carefully. It’s always a good idea to ask the techies if they’re still waiting for an answer from you on something you missed.

4: What is the test strategy and plan?

A well-managed software development team will create a test strategy near the start of the project; understand what that strategy is and ask questions if it doesn’t make sense to you.

5: When can we get involved with testing?

Make sure that you or your users play an integral role in testing. That role may be to help develop test cases or it may be to test, hands-on. Ideally, it is both. Be sure that representatives from the business side are playing an active role in testing. They will have a better intuitive understanding of what is “right” than full-time QA folks who need to rely on test-scripts.

6: What is the impact of the new system or change on our existing systems?

In a company with lots of systems that interact with each other, it can be difficult — for business users and techies alike — to identify how a change will affect other systems. As a business stakeholder, you should dedicate some time to thinking through how the project affects other downstream processes. You should also have a focused discussion with your technical counterparts on where the new or modified system touches other systems. If your project affects other systems, make sure they’re considered in the test strategy you asked about two questions ago.

7: How does the system handle exceptions and errors?

Unfortunately, things will go wrong. All well-designed systems should be designed to handle errors as gracefully as possible. Ask this question to verify that your system is being designed this way. Answers like “I don’t know” or “They will get some kind of exception message” aren’t good. Good answers will include an explanation of how the user and support staff will be notified in a way that makes sense; how bad or incomplete data will be prevented from going into the system; and how the process can be restarted after the error.

8: Is there an audit trail of changes in the system?

Most business users assume that all computer systems keep great records of what everyone has done on the system and all the history of changes and transactions. In general, none of this happens unless the people who developed the system thought to add those features. If these features are important to you (and I have seldom seen a business system where audit trails weren’t important), make sure that they are part of the requirements and ask for a demonstration.

9: Is there a plan for handing over the system to production support?

Many projects risk falling apart during the handoff from the technologists to the business. Make sure there is a clear plan for what happens when the programming and testing are done. You may be focusing on a training plan or customer communication strategy, but you need to make sure the technical team has a solid plan for moving the system into production and transitioning from development to operations. This should include establishing who supports the system going forward as well as mundane issues, such as making sure backups are in place. Also, you know there are going to be some changes needed after the first release. Make sure the technical resources are available for those inevitable adjustments.

10: What do you think we can improve?

There are plenty of techies who aren’t afraid to speak their mind about any number of subjects (regardless of whether they have an informed opinion). However, there are also plenty who really understand what the business is trying to achieve but are reticent about expressing their ideas. Ask them their opinions — you may gain some valuable insights.

And finally if all goes to plan,

11: Where should we celebrate the successful completion of the project?

JMR Consulting UK Ltd’s core expertise is based upon its Financial Services heritage and 15 years of operating in the Finance and IT sectors. JMR Consulting has vast experience in delivering successful IT projects, on time and to customer satisfaction. If you would like more information, please call us on 0845 052 0900 or send an email to info@jmruk.com.

This post was written by Mike Horning, Principal Consultant of the Professional Services Team. If you would like to become part of our professional services team, please email jobs@jmruk.com.

Being an executive in Information Technology (IT), I have managed business applications, IT infrastructure, processes, people and all the costs that support these areas. Usually, I have worked for the CEO, often with the CFO and sometimes it has appeared like I’ve been working against the CFO. Fortunately, these latter occasions have been rare. In my time as IT Director or CIO, I have  managed IT environments for both public and private companies. I’ve managed central environments and decentralised environments. I have supported staff that have built or deployed solutions on both custom and packaged software solutions in more languages and on more hardware platforms that I would care to count. I’ve managed through technology shifts and market consolidations, downsized, right sized, lost staff, re-staffed, re-tooled people and managed people out. I have run change programs that have experienced global sourcing, off-shore sourcing, outsourcing and strategic sourcing.

Reducing IT Costs is Good For Business

Through all this change there has been one constant – reducing IT costs. When I am asked to point to the one theme that has been constant throughout my career, the answer always is - Reducing IT Costs. Every IT manager is expected to manage costs. IT costs can quickly get out of control in many or all areas of IT. At some point in every IT manager’s career, he or she is faced with the challenge of holding budgets flat or reducing IT costs. Runaway costs are pretty easy to spot. Watch your budgets month to month or year to year and you can catch where things are getting out of hand. But once a manager holds costs and picks the low-hanging fruit, he or she may find it difficult to look for further cost reductions – feeling costs have been reduced everywhere possible.

However, there are many areas within IT that contain hidden costs and there are golden opportunities for reducing IT costs in any IT department.

Reducing IT Costs the Right Way

Many organisations look for quick cost reductions in hardware or application development. This is very possible and achievable as the first step in reducing IT costs. The second step to reducing IT costs in an effective and integrated way means that you have to eliminate costs in technology, processes and in the people-side of IT (beyond just lowering headcount). At JMR Consulting UK Ltd, we believe, support and practise the “smart” way to reduce costs while being very aware of the impact on corporate culture and the wider organisational IT environment.

Reducing IT Costs – How JMR Consulting Ltd can Help You

JMR Consulting UK Ltd has core expertise based on its Financial Services heritage and 15 years of operating in the Finance and IT sectors. Over this period, JMR staff have developed key IT cost reductions programs  and a constant focus on our service philosophy which is at the core of JMR’s business operation.

This post was written by Anthony Burke, Digital Marketing Director at JMR Consulting UK Ltd and Digital Marketing Consultant at WSI Digital Marketing. If you would like more information about our IT cost reduction services, please call us on 0845 052 0900 or email info@jmruk.com. If you would like to become part of our professional services team, please email jobs@jmruk.com.