Wednesday, December 05, 2012
Friday, June 01, 2012
ITIL outsourcing rarely, if ever, works for several reasons but mainly because vendors have little or no resources with the requisite knowledge and experience to successfully deliver what the customer needs. Further, the cost constraints of outsourcing agreements lead only to vendors acquiring low-cost, barely qualified resources to meet staffing requirements. After all, the outsourcers is in business to make a profit.
IT Managers would do well to remember that profit comes from keeping costs down. One of the biggest overhead costs for IT outsourcers is labor.
High quality does not equal low cost.
Saturday, March 10, 2012
Wednesday, December 07, 2011
Wednesday, November 09, 2011
- Establish specific and realistic goals with milestones
- Don't get too ambitious
- Identify project sponsors with skin in the game
- Create awareness of project objectives
- Identify and achieve project quick wins
- Provide context for the project
- Teach rather than do
Rather than this, the consultant should play the role of advisor, providing guidance to the client throughout the project lifecycle. At times, the consultant will lead the team through various workshops and exercises as a learning tool but the consultant should never take over the project. Our jobs as consultants should be to teach the organization how to keep going long after we've left. This message should be clear from the outset of the project and should be reiterated thought the entire project.
- Create a team of capable and willing participants
In short, if the project is important (as every project worth doing should be) be sure to carefully select core team members who are both willing and able to contribute to the success of the project.
- Set regular face to face meetings with team members
Besides setting regular meetings, our recommendation would be that whenever possible, assemble all team members together in a room for the duration of the project phase. This facilitates idea generation and problem solving and keeps the project on track.
- Break the project down into bite size mini projects or phases
- Don't do projects that have no benefit to the organization
Lastly, the consultant's reputation may be jeopardized by their involvement in a meaningless project. A consultant most valuable assest is always his/her integrity. This should not be bought and sold for any sum of money.
Monday, May 02, 2011
2. Gain a profound understanding of your IT customers.
3. Develop an objective and rational understanding of your internal resources and capabilities.
4. Develop a plan to effectively implement strategic intentions.
Tuesday, November 23, 2010
Outsourcing Leadership - Article - The RFP Pricing Template: A Tool for Provider Selection, Negotiations and Contract Management
Sunday, May 16, 2010
By now, we should all be aware that Availabiity should be measured by Service. This means that if there are several systems necessary to deliver a service (email, internet access), we should measure the average uptime of all system components required to deliver that service. In doing so, we can arrive at a predictable level of uptime.
This is the baseline used to determine the improvements necessary to meet customers requirements and expectations regarding availability. If a higher level of availability is required, then additional components (bandwidth, storage, memory) can be added to reach the desired level of availability.
Additionally, availability is always relative to the timeframe in which it is measured. This means that a service that requires 99.999% availability between the hours of 9-5 (M-F) may be much different (in terms of architecture & resource requirements) than a service that requires the same level of availabilty 24/7. Thus, not every service requires the same level of availability.
This concept of relative availability is one that is always missing from the discussions of uptime.
What is also missing from these discussions is a definition of "uptime" and the impact of performance on that definition.
If a service is available but very slow, is it still considered "up?"
Here is where the specifics in a Service Level Agreements become very important.
The ITIL library provides guidance on these and other IT Service Management process disciplines.
We are often asked to conduct small workshops for IT organizations to help Service Desk agents to better understand the differences between Incidents and Service Requests. In most cases, once the differences are explained and a few example are provided, people start to get it.
However, there are some instances when simply looking at a list of examples is not an effective approach to the correct classification of Incidents. This is primarily due to the fact that no list can predict every possible user call to the service desk.
While it may be possible to capture, record and classify the most frequent system breakdowns and user requests, the possiblities are infinite. If there were such a rule, we could simply program a computer to do the work and save a lot of money.
Until then, Service Desk agents will have to use their knowledge of IT and ITIL to make the determination.
For example, sometimes the difference between an Incident and a Service Request is determined by the details. An error downloading software to a user workstation can be attributed to several different causes.
The user could lack the appropriate knowledge or skills (Service Request)or, the error could be related to a fault in the infrastructure (Incident). By asking follow-up questions, the Service Desk agent, should be able to determine to most appropriate classification and course of action.
The point, is that in many situations, it is "why" rather than "what" the user is unable to do that determines whether the ticket should be classified as an Incident or as a Service Request.
Understanding this helps the IT organization to produce more accurate reports about the health of the inftastructure. These reports are also useful in identifying areas for targeted improvement and user training opportunities.
This post was contributed by Danielle Baker, Managing Director of Red Engine Consulting. Danielle is a certified V3 Expert and has extensive experience in ITSM, Organizational Change and Project Management.