Friday, October 9, 2009
"Following a basic maintenance plan is the best way to keep an automobile running efficiently and at peak performance, in both good and poor driving conditions. Getting regular oil changes and tune-ups, checking the water level, keeping the tires properly inflated, and other such tasks not only will keep your car running smoothly, but also will lesson the chance of a breakdown on a long journey. Similarly, following the best practices outlined in the IT Infrastructure Library, better known as simply ITIL, will help your IT organization run at peak performance and efficiency on its journey through the current economic landscape."
For the full article, see ITSMWatch.com Article
Wednesday, September 16, 2009
The Incident PAT is where the rubber meets the road. This is where we analyze metrics to see if the process is actually working. We discuss ways we need to improve. And then we make assignments to implement those improvements. This week we specifically discussed changes to Incident ticket categorization, creation of reports to measure metrics, and ticket resolution. The time for abstract theorizing is over. This is the process in action!
Thursday, August 20, 2009
With the Process Improvement efforts, we're trying to take efficiency and visibility to a whole new level. It has nothing to do with bowing our heads and submitting to a Process - it's all about WOWing our customers, managers, employees, and co-workers - because with these new Processes we can get a lot more done in less time. That means happier bosses, happier students, happier vendors - happier everyone!
Let's really try to apply these Processes with feeling, not just because our boss expects us to. Let's WOW this University.
Tuesday, August 4, 2009
- Accountable - Liable to being called to account; answerable
- aility or -ibility is a suffix meaning - Ability, inclination, or suitability for a specified action or condition
- Model - a pattern or mode of structure or formation
So, we're really talking about a pattern or structure that shows us how to select the group most suitable to be answerable for a specific task.
What!?! What weirdness is this and what does it have to do with me?
As we progress with our process reviews and redesign, we're finding more and more that the better we define the Accountability Model, the smoother things go. It's a point that we illustrate in our latest round of Incident Management training. It's also the point the a large number of our trainees say was the biggest learning for them when they come to the training.
Essentially, our Accountability Model for Incident Management says that we can distribute all incidents into three specific types - Individual, System, and Design, and each type of incident has a specific group that is 100% accountable to get that incident resolved.
Individual incidents are those affecting an individual, whether it is their account, computer, connection, or ability to do what they need to. An individual incident can't be duplicated using another account or on another machine, etc - you get the idea. Accountability for individual incidents resides with either the Service Desks or Field Services, depending on the specific details of the incident.
System incidents are those affecting many individuals and are resolved by restoring, restarting or reseting a system component such as a server, switch, router, system, etc. Accountability for system incidents resides with either Operations or Field Services, again, depending on the specific details of the incident.
Design incidents are those that require a design change to resolve the incident. No amount of restore, restart, or reset will get the customer back in service. Accountability for design incidents belongs to Engineering.
The idea is to get the incident assigned to the correct accountability group as quickly as possible so the incident can be resolved quickly. We're having no more of this transferring incidents from group to group to group like a hot potato. It's important that we learn how to do this well so that our customer's incidents can be resolved as quickly as possible.
On ITSMWatch.com I found the following quote that talks about the value of the Accountability Model:
"There are many jewels of IT service management (ITSM) guidance in the IT Infrastructure Library (ITIL), but of the most valuable is the inherent accountability model that is referenced throughout the framework. Utilizing this accountability model can make all the difference in changing “hard work” efforts to “smart work” efforts.
Having clearly defined accountability and responsibility allows for individuals to understand what service they provide; what their role is in the overall management of a given service, process, or function; and provides a mechanism for aligning their daily activities with business priorities."
See the whole article here ==> http://www.itsmwatch.com/itil/article.php/3794216
Even better, we think the Accountability Model helps us to understand and respect one another. Too often, it seemed that the old way of just pushing an incident along the path "up" the levels of IT led too many people to think that the "first level" Service Desk wasn't as smart or as capable as the "higher levels" of Operations or Engineering. We affectionately call that the "Dummy Model" and want nothing further to do with it. Our Accountability Model abolishes the levels and focuses instead on ares of suitable expertise.
It's kind of fun in the training sessions to see how this plays out. When we do the wrap-up at the end, it's always interesting to hear how eyes are opened and how respect is generated for each of the OIT groups and how the Accountability Model helps people to 'get it'.
Wednesday, July 29, 2009
If you haven't yet heard, a 'power bump' hit much of Utah and in the aftermath, somehow all of our redundant power systems didn't switch over as expected and the Data Center suffered a partial power outage. This, of course, caused system outages on both sides of the Data Center, resulting in lots of downed systems, web pages, etc.
While the recovery from this event actually went pretty smoothly, we quickly found that without collaboration, chaos would reign. We ended up having a 'scribe' attached to each of the core recovery teams, BYU OIT, CHQ ICS, and Electric Shop, taking notes and running messages around. A phone bridge was formed to recover the CHQ systems and it didn't take long to learn that one single person had to be 'in charge'. Initially, when everyone was saying what they knew and thought, the result was a cacaphony of sound that required lots of repeating. Once order was established, things began to flow - but that's really more about Major Incident Coordination, a topic for a later blog.
OK, so I know that everyone is going, "well duh! Of course when you have a major outage you need collaboration, but those don't really happen all that often, how on earth does it apply to daily stuff?" Well, I think it does.
While the scale is smaller, I know we daily run into situations, large and small, while working to resolve incidents, where more than one mind working on it helps to resolve the issue better and faster. Sometimes, however, there seems to be a hesitation to engage others. Perhaps it's just that it doesn't come to mind. Maybe it's that we don't want to be seen as less than adequate by asking for help. It could even be that the challenge of finding the resolution is so engaging that we want to keep it just for ourselves. Whatever the reason we may not do it now, we should try to remember that our focus with Incident Management is to restore service as quickly as possible, which should override any hesitation we have to bring someone else in to help.
With that said, however, we also want to remember that whenever we collaborate with others in resolving incidents, the learnings found and solutions determined should be a point for us to make sure gets documented and shared via the Knowledgebase. That way, next time the same situation occurs, we or others can take advantage of the previous collaboration and resolve the incident even more quickly. It's something we did last night for sure.
Sometime between 1:30 and 2:00 am, when it became clear that the power was stable and system recovery was complete for some systems and welll underway for others, we sat down and focused on creating a list of things that we learned and things that needed follow-up. We found that things like call-tree lists needed refreshing, procedures updated, and system configurations that need followup. Certainly there will be formal reporting on the situation and the outcome. Probably the first non-email round will happen in Production Council tomorrow.
Perhaps the nicest thing about the effort last night was the chance to serve with others and build feelings of teamwork. Despite a considerably stressed situation, I never saw one single instance of short temper and I did see lots of consideration for others and thankfulness for that consideration. And isn't that really what's most important in the long run?
Thursday, July 9, 2009
• 2 people from ESPM, Leadership Council, or Account Management
• 6 people from Development
• 16 people from Production Services
It is vital that each person in OIT is an expert at knowing and executing our Incident Management process. Unless your Supervisor specifically asks you not to attend this training, please sign up and attend one of the scheduled sessions.
Sessions are scheduled as follows:
• Fridays 10-Noon, 7/10 thru 8/28
• Tuesdays 8-10, 7/14 thru 9/1
• Tuesdays 1:30-3:30, 7/14 thru 9/1
• Every other Wed 2-4, 7/15 thru 8/26
All sessions are in MB270/276
Thursday, July 2, 2009
It isn't that we haven't been making progress, it's simply that we haven't done a good job of keeping communication going out. Previously, all of our blogs were simultaneously written for and published in a hardcopy newsletter. Quite frankly, that was JUST TOO MUCH WORK!
So now, we are going to just blog here and we think we'll be able to post at least once per week.
Now, to get everyone up-to-date - - -
Previously at PIM Central (PIM=Process Improvement Management), we had developed the core PIM process and were testing it out with an Incident Management effort. What's happened since then and what is happening now - - -
- Incident PIM has completed the process design and it is officially production. The documentation is on BYU's eRoom here https://eroom.byu.edu/eRoom/OIT/OITPolicies/0_3096
- The introductory round of training was completed for 230+ people in OIT
- The second round of training starts July 10 - it will be very different from the first. We're going to be doing a very hands-on simulation that will have people working through the process and learning about the key concepts through experience. 28 sessions are scheduled from July 10 through Sept 1
- Key concepts to focus on for Incident PIM are: Teamsork, Accountability Model, Collaboration, New Statuses, New Priority Matrix
- We're really excited about the Accountability Model - with it, each OIT group has 100% accountability for certain types of incidents. Service Desk for incidents that affect an individual, Operations for incidents that affect systems, and Engineering for incidents that require a Design Change. The old 'dummy' escalation model is hereby banished from our world (you know, escalate all incidents to the next group 'up' if you can't solve it) We're still learning how to make it work, but it sure feels like the right thing to do!
- Some of the updates haven't yet been implemented because of tool constraints
- The Process Advisory Team (PAT) charter has been approved and they will start to meet monthly
- The PAT will focus on getting the metrics in place that are documented in the Continuous Improvement Plan
- Change PIM is far into the design process after doing a lot of learning about ITIL Change recommendations and looking into what gaps we have at BYU
- The new design accounts for Change from the large perspective, starting with University IT Objectives down through detailed change plans - the information flow and communication channels will greatly increase OIT's ability to eliminate surprises and increase the effectiveness of our changes
- A comprehensive Risk Analysis model has been developed and extensively tested - this will allow us to size change models so that the process is scalable without adding excess bureauacracy (we hope!!!)
- We've been able to capitalize on Leadership Council's directives and models including the 5-box work model and the system container panels concepts to build and tie-together the Change process
- Problem PIM is also into the design process
- The new design is really starting to clarify how Problem Management fits into our work and is clearly going to be the link between Design Incidents (Engineering accountable) and Change Management (implementing the design change into production)
Best of all - EVERY ONE of these PIM efforts have led to great collaborative conversations between all OIT groups. Relationships have been built and strengthened. It has extended the conversation into other efforts and smoothed the way for coming to agreement. It's a good thing.
Friday, October 3, 2008
- dictionary.com defines map as follows: Noun: a representation of items showing them in their respective forms, sizes, and relationships according to some convention of representation
- Idiom: put on the map, to bring into the public eye; make known, famous, or prominent
- An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set.
- The Process responsible for managing the Lifecycle of all Incidents. The primary Objective of Incident Management is to return the IT Service to Users as quickly as possible.
- Christine Oakes (Process Steward), Marty Garn, Matt Wilkinson, Mark Andersen, Nyla Miller, Deborah Tibbens, Jared Harward, Troy Gundersen, Darin Stephens, Troy Martin, Relia Smith, and Sorrel Jakins (Process Navigator).
- Kelly McDonald, Brad Stone, Richard Maughan, and Ernie Nielsen
- Step 1.1 Initiate a Process Innovation Effort – OIT Leadership Council was approached with a proposal to formalize the PIM process as a means of implementing the “customer-centric, supported by process” strategy that Kelly and Kelly introduced at February’s OIT All-Hands Meeting.
- Step 1.2 Establish Organizational Sponsorship – OIT Leadership Council selected and chartered a cross-functional team (now known as the Process Navigators) to develop and implement PIM throughout OIT.
- Step 1.3 Gather Process Documentation – Process Navigators collected and gleaned from process-based activities that had been previously done in OIT as well as drawing from proven practices in the industry. This provided a view of the current process and ideas for the vision and scope for the Process Improvement Management effort.
- Step 1.4 Select Areas of Focus and Step 1.5 Determine Strategic Priority – OIT Leadership Council granted priority support to members of the Navigation team to allow focus on this important effort. The area of focus is to establish the baseline PIM process, design and validate an improved process, and implement the process in OIT.
- Step 2.1 Plan Analysis Phase – A simple project plan was created that outlined the activities that needed to be accomplished in order to analyze the current process. This step included activities such as training the team on process improvement, establishing a communication plan, and validating the project plan.
- Step 2.2 Analyze Current Process – In this step, we took a more detailed look at best practices and current practices and identified gaps.
- Step 2.3 Select Improvement Opportunities – The Process Navigators outlined the gaps that needed to be focused on in order for the process to best meet the needs of OIT.
- Step 2.4 Obtain Confirmation and Support (Return and Report) – We briefed OIT Leadership Council on what we were doing and obtained their feedback and support for continuing the process improvement exercise.
- Step 3.1 Plan the Design Phase - Process Navigators outlined next steps and set target dates for the preliminary process design to be accomplished.
- Step 3.2 Create the Preliminary Process Design – Process Navigators developed a set of templates based on best practices, and then documented the target PIM process using these formal templates. This resulted in the Process Package, introduced in last month’s newsletter. The Process Package for PIM is based on the reconciliation of industry proven practices and OIT’s strategic direction. It consists of the following documents: Process Policy, Process Overview, Process Map, Detail Process Steps, Roles and Responsibilities, and Continuous Improvement Plan.
- Step 3.3 Simulate the Process – The purpose of this step is to walk through the process and validate that the process design fills the gaps and meets the organizational requirements. OIT Leadership Council approved Incident Management as the first process to pilot through PIM. This is indicated on OIT’s Process Roadmap. A formal project request was approved in PMC (Portfolio Management Council) to run through the PIM process for Incident Management.
Friday, August 15, 2008
What is PIM? It’s another acronym–just what we need. It’s a life cycle for managing processes. Huh? Why do we need that? Are you trying to tell me we have a process to manage processes? Yup! Now before your eyes roll to the back of your head, give it a chance. How can we formalize processes in OIT unless we have guidelines for standardization? How can we ensure processes don’t get documented and then put on the shelf to gather dust—often before they’re even communicated or made available to the broader organization? How can we ensure a common readability and understanding of processes throughout OIT? Well, I suppose we can’t ensure anything by simply introducing a new process, but we can certainly provide a mechanism, sanctioned by OIT Leadership Council, by which processes can be documented, trained, communicated, made available to all OIT employees, and continually improved.
PIM, or Process Innovation Management, includes the following life cycle phases: Evaluate, Analyze, Design, Implement, and Manage. The first four phases are used when a process needs some significant level of attention resulting in changes to the process. The final phase, Manage, is ongoing work delineated by the acronym MITAR. MITAR breaks down the component steps of the “Manage” process as follows: Monitor, Investigate, Take Action, and Report.A few of the deliverables of the PIM process include:
- OIT Process Roadmap – An inventory of all processes that need to be Formally Managed along with timing and prioritization. Not unlike a technology roadmap or a product/service roadmap, this document contains a list of OIT processes and when they are slated for standardization, formalization, and/or innovation. OIT Leadership provides guidance to the process by validating which processes will be focused on when.
- Published PIM Process – A collection of process documents for Process Innovation Management that describe such things as the goal of the process, policies, expectations, process flow, stakeholders, key process steps, critical success factors, key performance indicators, roles and responsibilities. Once published, this process is available for use throughout the organization to guide process innovation activities.
- Process Package Templates – A collection of templates that support the PIM process. Representative templates include:
- Process Overview
- Roles and Responsibilities
- High level process map
- Detail process map
- Detail process steps
“We succeed individually. We prosper as a community.”1 This simple statement, penned by the CEO of Miller Freeman Company, was in grateful response to the Salt Lake community’s overwhelming support after an employee was killed in downtown’s freak tornado of August 1999.
Prosperity, “a successful, flourishing, or thriving condition,”2 moves forward our OIT community, and the greater BYU community, when there is appropriate attention to all four aspects of an organization’s culture; namely, attention to our customers (collaboration), our employees (cultivation), the quality of our services (competence), and the way we get things done (controls).
Under the direction of the OIT Leadership Council, the Navigator Team has been tasked with facilitating the finalization of the development of integrated processes. We are consciously dedicating significant employee time and attention to this effort. As we do so, there could be a false perception created that “process” has become our OIT focus. In fact, the attention we are giving to process development and integration is in an effort to mature our processes to the appropriate level, with a focused eye on providing world class customer service in the higher education arena. Process becomes a contributor to our collaboration focus–the means to the end.
Some examples of processes supporting excellence in customer service:
- Stakeholder Reviews – in the Development Lifecycle – ensure that all stakeholders, including the customer, have frequent and formal inspection of the output of development. Starting with requirements review, continuing through design review and user acceptance, the customer is invited into the development process frequently to ensure that we are on the right track, and to capture their changing needs, in a timely manner, as their environment changes.
- Requirements Management – in the Product and Service Management Process – ensures that there is a customer-focused means for gathering and understanding requirements, with an eye towards managing all requirements through the development, project, and support processes.
- Project Team Development – in the Project Planning and Management Process – ensures customer participation in all projects by first asking the question, “Which functions are most affected by the success of this project?” when developing the Project Team.
- Release Readiness – in the Production Services Process – ensures that we incorporate the customer acceptance and support requirements before we place a service into production.
1Deseret News, August 15 1999
2Dictionary.com unabridged v1.1
By Sorrel Jakins
When Harry Potter went to Diagon Alley to get his wand, he was first measured and fitted for the right wand by Mr. Ollivander. Mr. Ollivander had many good wands available, but not just any wand would do. Once Harry was matched with his wand, he still wasn’t done. Harry now faced years of schooling, practice and hard work to learn how to use his wand properly and how to get the most out of it. Process work is similar.
Process takes time, and not all problems can be solved by a new or improved process. People, Process, and Technology can be considered three legs of the same milking stool, all equally important. A balanced approach is necessary to avoid a wobble or a crash. For a good process to work well, there are certain pre- and post-requisites.
The benefit of having a common process model lies in the ability to adopt complex and commodity systems using a lingua franca for IT services. Even though we may all be speaking the same language, it is not a replacement for experience. The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it. Process improvement will increase product and service quality as we apply it to achieve business objectives. This, like repentance, is a continuously improving process and not a point-in-time event. As we grow towards a unity of process, we will move to a unity of purpose and a closer alignment of our objectives with BYU and OIT business objectives.
So an improved process model can “help eliminate confusion in terminology and provide a foundation for understanding”—how cool is that? Isn’t that what OIT and BYU needs? So why isn’t process management ubiquitous within OIT? Standards are difficult to implement, people fear that process brings bureaucracy and red tape, and inertia—we believe strongly in doing things the way we always have.
Formal processes provide a foundation for predictable and reliable IT service design and delivery. Just as Harry Potter and his friends learned to put their wands to use for their benefit and the benefit of others, so will we learn to do the same with our processes as we continuously work to improve them.
Back to the three-legged milking stool—do you know why it has only three legs? Because the cow has the udder.
What do our customers say about us? What do we think they are saying about us? What is the value of OIT to the business? How is that measured? I have an experience I remember every time I think about these questions.
My journey into IT was indirect. I first started working for the Financial Controller of an Aerospace manufacturing company in Park City many years ago. The company was in the process of bringing a new plant online in Utah. I was the third non-management employee hired and I was assigned to process job applications as they came in and to handle any other HR or Payroll paperwork that needed to be done. Up to that point in my life, I had some limited exposure to an early model PC we had at home – yes the screen was only one color and there were two floppy drives and no hard drive—but we’re not going to talk about how old I am, now are we?!
Part of my job required that I do some data entry work to input data from the timecards of the shop employees. When I sat down to learn how to do this, I was facing an old IBM terminal. You know, the kind with the really clacky keyboard and the monster monitor. I remember the first time I tried to get into the timecard entry program by myself. As I looked at that giganto monitor and waited for the screen to turn from black to flickering green, I felt as if I were staring into a huge, unknown black-hole. I had no idea how the technology worked and I was terrified that somehow I would mess up and push the wrong button which would then result in the entire main-frame melting down! I had no idea that sort of thing could not happen.
Once I got logged into the program and entered my data, I would always anxiously wait for the screen to come back and confirm the data was accepted. Every time it came back with an error that forced me to start over, I grumbled and moaned about the stupid ‘system’ and I nearly always included disparaging thoughts about the IT department in my complaining. Little did I know that one day, I would be one of “THEM!”
I guess my point is that within OIT, we need to always be aware of our customers and their experience. We need to be especially cognizant of the fact that many of our customers feel like I did that first day—at the very least, frustrated and at the worst, terrified of technology. Sometimes, we who are so comfortable with technology that a blue-screen-of-death is simply an opportunity to re-image and try out the latest, greatest OS, forget that not everybody is as comfortable with technology as we are. Sometimes we think that the sophistication or ‘coolness’ of the technology we deliver is all that is needed for our customers to be totally satisfied with us.
When the Savior said, “Come follow me,” he could do that because he first walked where we walk. He gave us the ultimate example of customer service. His love and compassion for the least among us should be the model for us to use as we work to meet our customers’ needs.
The process work that we are doing is important work and we need to make sure that we are always keeping our customer foremost in our minds as we mature our processes. It isn’t good enough for us to simply say we are thinking about them, we really need to be engaged with them and working to understand their point of view in everything we do. If we create our processes properly, this focus will be built in and we will ensure that customer needs are being met.
You too can have your thoughts heard and published as part of the process work we’re doing. You can use any of the following ways to be heard:
- Email us – firstname.lastname@example.org
- “Navigate” to our blog – http://navigator.byu.edu
- Add comments by clicking on the comments link below the article you want to address.
- Enter your comment in the box and then select the radio button that says “Name/URL” (see the picture below!).
- You don’t need to worry about entering anything in the URL field, but we do want to know by whom the comments are being made. Please add your name to your comments.
- Elaine Lauritzen 422-1232 email@example.com
- Jared Harward 422-8852 firstname.lastname@example.org
- Valinda Rose 422-1494 email@example.com
- Sorrel Jakins 422-7128 firstname.lastname@example.org
- Vince Rackliffe 420-1746 email@example.com
Thursday, July 10, 2008
Vince Rackliff has joined the Process Navigators!
If you don’t know Vince, you should. Vince comes from the OIT Architects Team. He is charged with learning how OIT processes function so reference architectures can be built in a complimentary manner. He just joined us this week and has already contributed to the team. Vince can be contacted at 420-1746, or firstname.lastname@example.org.
Don’t forget that you are always welcome to contact any of the process navigators should you have questions or suggestions for how this process work proceeds.
On another note – we’re busy finishing up the content for our first formal process, Process Innovation Management (PIM). The process package will be delivered to Leadership Council on the 18th. Immediately following that, we expect other process teams to be formed and the work begin to formally document and manage additional processes. Watch for more information coming up on that.
And finally, we want to send a great big THANKS! to Relia Smith’s team, especially Scott Bowen. This team has been helping us with editing, formatting, and publishing. They have been AWESOME! Scott has been thrown into the deep end and has really surfaced and learned to swim quickly. We sure appreciate what they are doing for us.
BTW – next newsletter will be out sometime around July 18th – keep an eye out for it!
Tuesday, July 1, 2008
At the same time, the Process Navigators have been very busy documenting the Process Innovation Management process. This is the process that will help us manage all processes. We will present this process package to Leadership Council on July 18. We hope they like what they see and that we'll be able to move pretty quickly to get the process put into production. That means that we will begin publishing the package and holding training sessions to get everyone familiar with it. We'll also start working other processes through the steps towards getting them documented and published.
We're using as much material as we can from work that has been done previously in OIT. That should make it so that things look familiar and so that there aren't too many jarringly different surprises for anyone. We firmly believe that good process management in the organization means no unpleasant surprises.
Look for the second newsletter soon with more information about what we are doing and more ways for you to participate!!
Have a happy and safe 4th everyone!!!
Friday, June 20, 2008
The first newsletter is printing as we speak and will come out either today or Monday. All of the articles from that newsletter are the first entries in this blog. We're really focusing on finding lots of good interactive ways for everyone to participate in this effort.
The first process we're working on, Process Innovation Management (PIM) is coming along really nicely and we plan to have something to start showing everyone at the end of June, first of July. We're getting pretty excited to pilot the first few processes through their formal PIM review in July.
Lots of good stuff happening!!!
Wednesday, June 18, 2008
- Log into the site regularly.
- Use the "subscribe via email" box at the right to have new posts sent to you each morning.
- Subscribe to the RSS feed using a feed reader such as those built in to Safari, Firefox, and Internet Explorer. The feed is a special file that lists the current posts on this site. A feed reader automatically downloads that file and displays the posts, along with any feeds you have chosen from other sites. View this video for help getting started.