CAI – Computer Aid, Inc. |

Computer Aid, Inc. (CAI) a US based software services company with 35 regional offices throughout the Northeastern US, Asia Pacific  and Sydney Australia . CAI has a 20 year history reducing its client’s application software maintenance costs by at least 30% – Guaranteed! The CAI application support service provides superior maintenance of legacy application software using industry standard (CMM and ITIL) [...]

CAI – Government Staffing Services

CAI has used its Managed Service Provider (MSP) program to source all levels of IT talent for several states, including Pennsylvania, Virginia, Arkansas, and New Jersey. As the point of contact between our client hiring managers and an open supplier network, CAI’s Government Staffing Services has filled over 4,600 requirements.

ITIL V3 Application Support Book

“ITIL V3 Application Support”  provides the reader with an introduction to the ITIL® Version 3 (V3) Service Lifecycle and Computer Aid, Inc.’s (CAI) Application Support Lifecycle. It describes how CAI’s Application Support Life Cycle processes align with ITIL V3 and can be used to manage Application Support services. The book is based upon CAI’s 18 [...]

Tracer – CAI’s IT Service Management Tool

“CLICK ON THE LINK ABOVE”
Tracer, CAI’s Application Support Service Management tool is the single point of integration for all IT Service Management (ITSM) processes, SLA performance goals, operational data and service operations reporting.
 Tracer enables IT service delivery professionals to track all work throughout the complete process lifecycle. Tracer insures that relevant work and performance data [...]

Today's Quote:

Patriotism is supporting your country all the time, and your government when it deserves it.

--- American author Mark Twain (1835-1910)

Recent Articles:

25 Truths of IT Support

Webster’s Dictionary defines an axiom as “a self-evident truth that requires no proof.” Over the course of decades in IT, I’ve discovered 25 axioms about the IT support environment. Being aware of these can help you design support processes that

will make sense, work well and improve your team’s performance.  Here are some of the great truths I’ve learned and how your team can apply them for better IT support:

 1.             The estimate a user hears is the estimate the user will remember; the date a user hears is the date the user will remember. Never give a verbal estimate or date you’re not willing to live and die by. 

2.             Work without defined boundaries is work that may never end. Don’t say, “I’m working on it,” without qualifying when it will be done and, if necessary, why it won’t be done on time.  

3.             The support team is most vulnerable when moving something into production. Just the right amount of constructive paranoia is a good thing. Are you sure the right modules and versions moved into production? Check again!  

4.             Users have selective amnesia.  Always get sign-off or written approval.  

5.             Nothing will be done and nothing will work unless you invest some personal time to check it. Assume that, and you  will never be surprised.  

6.             “No” isn’t a constructive response. Never use it when a request for work or assistance is made. Instead, say, “Let me review it, and I’ll get back to you by Tuesday. Then think about it; you just might be able to help.  

7.             What you can’t measure, you can’t control. Define service-level goals, and capture measurement data at its source.              Compare the “should” to the “is.”  

8.             You can’t come up with an accurate estimate without knowing the number and complexity of the functions required. Deconstruct functional requirements, even for small requests.  

9.             The fox is not a good henhouse guard. Don’t quality-control your own work. Always have independent validation.  

10.          The test environment is not the production environment. Never assume that because it works in the former, it will work in the latter.  

11.          If you take it, you own it. If you take the support call, it’s your responsibility to make sure it’s completed successfully.  

12.          Constructive criticism is positive; blame is negative. Don’t blame; figure out how the group can do it better.  

13.          Murphy’s Law is optimistic. Even the most carefully planned and executed activities will go astray at the worst possible moment. Always be vigilant, flexible and prepared.  

14.          Effective communication will smooth over a lot of problems or prevent potential problems from happening. Communicate potential problems or newly discovered issues to your colleagues and management team right away. Be proactive, not reactive.  

15.          Nobody likes surprises. Communicate changes to all who will be affected at the earliest possible time.  

16.          Your memory isn’t trustworthy; neither is the user’s. Don’t trust memory; write it down.

17.          Work isn’t completed until you get verification from the user that it’s completed. Never assume.  

18.          If you don’t clearly define expectations, you will get what you deserve, not what you need. Be specific about what you want and when you want it, what you will deliver and when you will deliver it.  

19.          Users are customers, not problems.  Treat them that way.  

20.          Perception is reality. Always get feedback about what you think you communicated. Never assume that your perception is the customer’s reality.  

21.          Accountability without authority leads to failure. If someone is being held accountable, give him the authority he needs to succeed. 

22.          It is easy to see problems; solutions are tougher. Never go to someone with a problem in one hand unless you have at least one solution in the other hand.  

23.          Your common sense is not always someone else’s common sense. Don’t assume that just because it’s obvious to you, it will be obvious to others.  

24.          Technology doesn’t always work as it is supposed to. Develop test strategies that thoroughly exercise the required operational limits of any technology on which the business depends.  

25.          Irretrievable data corruption usually occurs with files that are not backed up. Always back up your systems and data on a regular schedule.  

If you design your IT support processes with these truths in mind and get your group to live by them, you’ll improve your productivity, the quality of service delivered and overall performance.

 A SUPPORT PROCESS FRAMEWORK

 Best-practice support processes need to be well-defined, repeatable and compliant with industry standards like CMM and ITIL.  Designing and implementing repeatable processes is hard work.  But if you stick with it, the dividends in reduced operational costs as well as improved quality and customer satisfaction are well worth the effort.  It has been my experience that where defined, repeatable processes and metrics are implemented, a savings of 30% to 50% in IT support costs can be achieved.  In order to achieve these savings, processes must formally document the answers to the following questions:  

  • What type of work is being done?
  • How can the same type of work be done with a high degree of repeatability?
  • Who is doing the work? What are their specific roles? Who is responsible?
  • What supporting documents or other deliverables are required as part of each task.
  • How do we define quality in work products produced?
  • How do we capture data on all work performed and the people who do that work?
  • How do we measure performance, productivity, quality and customer satisfaction within all work processes, work products and customer services?

 These last questions are particularly crucial. Embedded within any good support process must be the ability to capture and report operational data that provides feedback on how the processes and resources are performing. With questions like these as your framework and “The 25 Truths of IT Support” as guidelines, you’ll avoid costly missteps or mistakes as you build or improve your support processes.

1 – Critical Application Knowedge is Becoming Extinct!

“The National Aeronautics and Space Administration (NASA) spent $24 billion in the 1960’s to send twelve astronauts to the moon.  Today they have to start all over again at an estimated $100 billion to  return a man to the moon. Why?  The engineers who had the critical know-how to send astronauts to the moon have either retired or died, taking the knowledge with them.  

If IT professionals do not do something quickly, practical application support knowledge will become a statistic of the Darwin Principle – EXTINCT!

1a – Application Support Knowledge Becoming Extinct!

The baby boomers are retiring at an ever increasing rate, critical IT application knowledge is moving off-shore at an ever increasing rate, and the work force is more mobile now than it has ever been. The IT industry is experiencing an unprecedented “Brain Drain” particularly within the IT application support environment. Who is going to be left behind to mind the store? Where will all the application support knowledge go that has been accumulated over many years?

1b – Application Support Knowledge Becoming Extinct!

When “Charlie” (the go-to-guy who fixes any serious problem) is gone who will take his place? How will others learn what took “Charlie” 10 to 15 years, if he is gone and all the critical knowledge was only in Charlie’s head?  

What took “Charlie” one hour to fix, may take several people many hours or days to fix.  This can lead to serious business interruption, project schedule overruns and a dramatic increase in application support costs.  

Loss of application knowledge represents a significant business risk and should be given the same consideration as the loss of any other critical business asset.  

Many IT executives say, “We have application documentation.” What IT executives should be saying is, “We have institutionalized our critical application knowledge and it is readily available by anyone who needs it.” However, in most cases this is not the case.  In this context there is a great deal of difference between “Application Documentation” and “Application Knowledge.”  

Application Documentation – Technical design and specifications

  • Created for developing the application, not supporting it.
  • Not organized in a way that makes specific content fast and easy to find
  • Badly out of date and reflects little of what the application looks like today
  • Current version is difficult to find and in most cases even more difficult to use
  • Does not reflect what lessons have been learned by the support SME’s (subject matter experts) over years of supporting the application
  • Written in “tech speak” and has very little use outside the IT organization – very little leverage with business users.  

Application Knowledge is – What is in the employee’s head

  • Knowledge gained over years of supporting the application
  • Practical knowledge used in support of specific application functions, output and users
  • Knowledge of application trouble areas and what is necessary to fix reoccurring or intermittent problems quickly
  • Critical application processing routings and calculations
  • Personal trouble-shooting utilities or processes developed over the years that are not common knowledge within the IT department
  • Knowledge of critical application components and how they effect the application
  • In-depth knowledge of data structures, their content and how the data applies to the business function they support

1c – Application Support Knowledge is Becoming Extinct!

Before any useful application support knowledge solution can be developed a prerequisite is an in-depth understanding of the application support environment and what is needed day-to-day by those who support the application. The following represent a small sampling of items that need to be addressed when developing any application knowledge solution: 

  • What application knowledge content is most useful and relevant to those supporting the application
  • Where is knowledge-content found? In what form? Who knows?
  • Does some of this knowledge content already exist? Where?
  • Can specific knowledge content be accessed quickly and understood easily
  • Is it in a form that is easy to use
  • Do standard knowledge content templates exist that can be used across many applications
  • Can application knowledge be used by others outside IT Organization: Application Users, Business Analysts, Developers, and Executives?

Successfully implementing any knowledge capture and management solution must include processes that the keep knowledge current. The most logical place is to update this knowledge within the service delivery process. Knowledge, like the application itself is dynamic and changes very quickly over a short period of time. These changes need to be captured when they occur and reflected in the Knowledge Repository.

 Finally, the knowledge delivery mechanism and navigation should be quick and easy, reflecting the needs of all those who may need specific application knowledge at any time.

 The question that business executives must always ask “is it worth it”? Will the benefit of developing and maintaining this application knowledge outweigh its cost? There will a different answer for each business; however, the place to ask this question is of those whose job it is to support the applications. Ask them: What would happen if “Charlie” was gone?

IT Support Services Comments

  • Bob Anderson: Pablo, I am not sure what your Changes Data Base contains or what the difference between Major change tickets and minor Changes. However, if I understand correctly, Changes referees to either applicat...
  • Bob Anderson: Mary, first what do you mean by "scalable" in terms of capability - what capability. Service Capability? Work Capacity? Quality Capability? - Capability can cover many areas. Depending on definition, ...
  • Bob Anderson: David, yes, you might be able to extrapolate required personnel using function points but I personally do not think that would be your best avenue unless you had a real certified expert in FP counting...
  • Bob Anderson: Kathy, Thank you for the kind feedback. Please click the link that follows and you will be subscribed to the blog. Additionally, you should now see a "Subscribe" button on the lower menu bar that was ...
  • Bob Anderson: In what context is the question asked? Why is what called "Software Engineering? If your question is related to CMM / CMMI, this is a term defined / used by Carnegie Mellon Software Engineering Instit...

ITIL V3 Application Support Q & A

If you have any question on the blog content or have some specific question on how ITSM & ITIL can dramatically improve performance and reduce the cost of your Application Support service "Ask Bob"
Question :
Answer :
Mary, first what do you mean by "scalable" in terms of capability - what capability. Service Capability? Work Capacity? Quality Capability? - Capability can cover many areas. Depending on definition, however, I think ITIL Service Life-cycle or CMMI-SVC model provides t...
Question :
Answer :
David, yes, you might be able to extrapolate required personnel using function points but I personally do not think that would be your best avenue unless you had a real certified expert in FP counting and you had a FP baseline on existing applications with FP/person cal...
Question :
Answer :
Kathy, Thank you for the kind feedback. Please click the link that follows and you will be subscribed to the blog. Additionally, you should now see a "Subscribe" button on the lower menu bar that was just added for those who wish to subscribe to an RSS feed.  Bob   f...
Question :
Answer :
In what context is the question asked? Why is what called "Software Engineering? If your question is related to CMM / CMMI, this is a term defined / used by Carnegie Mellon Software Engineering Institute (CMM / CMMI). Any material in the blog is using the accepted indu...