Editor’s Note: This is the first installment in a series designed to highlight the products and services of the Navy IT Service Management Office relating their capabilities in a business case story format spread over succeeding chapters of an IT Service Management novella.
“Process Owner? Who were they kidding?”
With the declaration of his name among others at the enterprise role assignments meeting still ringing in his ear, he remembered vividly the day not long ago when he passed the ITIL v3 Foundations test after sitting for the three-day course, confident that he’d never have to refer back to his notes. He remembered thinking that he had the jargon down, knew the ITIL lifecycle phases, and had some vague notion of configuration-something improvement… or was that continual service implementation… he couldn’t quite put it together. Bottom line — he could engage in an intelligent conversation about service management, ITIL, and maybe ITSM without being embarrassed. But now… “Oh Joy!…” it seems his Foundations certificate had put him in the hot-seat as the owner of one of the enterprise processes supporting request fulfillment. Request fulfillment. Right. Might as well be brain surgery.
Bob had always been a techie – someone who instinctively knew how things should be engineered and operated, but he’d never given much thought to how various parts of the enterprise were managed as a single unit, all pointing in the same direction toward a single purpose. “Great, now I’m a manager,” he thought, knowing that wasn’t going to be enough of a resume to bring to the table of process owners.
He knew he needed a better understanding of how his piece of the pie fit into the pie plate. Rummaging through his desk, he found the three-ring binder containing his student guide for the Foundations course. Briefly eyeing the table of contents he saw the ITIL lifecycle phases: Service Strategy, Service Design, Service Transition — ah, there it was — Service Operation. He thumbed to the section and looked at the processes that made up Service Operation: Access Management, Event Management, Incident Management, Problem Management, and good ‘ole Request Fulfillment. Turning to the page, he began to read:
“Request fulfilment is the process responsible for managing the lifecycle of all service requests from the users.”
“But I thought that was what the service desk was for,” he mumbled under his breath. He kept reading:
“Many of the calls to the service desk are typically requests for small changes that are low risk, frequently performed, low cost etc., for example, a request to change a password, a request to install an additional software application onto a particular workstation, a request to relocate some items of desktop equipment — or may be just a request for information. Their scale and frequent, low-risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal incident and change management processes.”
“I guess that makes sense,” he thought. He scanned the pages of the student guide and realized there was much more to this “simple” process of fulfilling requests than he haphazardly assumed. To be honest, he hadn’t really taken the time during the course to differentiate service requests from incidents. To him, they were just one and the same; some faceless academic’s way of segregating phone calls from trouble tickets. But now, as he began to review the process in more detail, he noticed that its purpose was to manage (there’s that word again) the lifecycle of all service requests from users. He found the scope of the process more interesting and illuminating; sure, some organizations use the incident management process to also handle requests, but there is a significant difference…
“…an incident is usually an unplanned event, whereas a service request is usually something that can and should be planned!”
He continued to thumb through the student guide for the remainder of the afternoon, reacquainting himself with the service management notions of business value, process principles, prioritization, categorization, escalation, coordination and the specific activities within the Request Fulfillment process. There was a lot to chew on. He knew he’d have to get up-to-speed, and in a hurry. He decided that a good part of his weekend would be devoted to reading the ITIL v3 Service Operation book to get the full industry best practice treatment of the Request Fulfillment process and hopefully start to appreciate and understand how it supports and/or depends on other processes within the Service Management lifecycle. He felt better. “The Process Owners Council won’t know what hit them.”
The following Monday morning was like any other, with the exception of a looming dread that had enveloped him as he had tried to make sense of the Service Operations book (or more to the point, the section that dealt with Request Fulfillment). Yes, some of the material made sense, but how was he going to generate all the organizationally-specific artifacts the framework said was necessary just to begin putting the process in place? He checked his calendar: “ITSM Process Owner’s Council Meeting, 10AM Wednesday.” That didn’t give him much time to come up with a plan of action, let alone any milestones for development and implementation.
He met Jim for lunch in the break room as usual following a morning of slogging through email, getting status updates from the weekend and planning for the week ahead. The upcoming Process Owners Council meeting was weighing on him and he had tried to adjust some of his weekly meetings and reports to later than normal in the week in order to give him more time to come up with a plan ahead of Wednesday’s meeting. He thought Jim would commiserate with him about the meeting since Jim too had been assigned as the Incident Management Process Owner in the same meeting last week and was a classmate in the ITIL Foundations course, so he casually brought up the subject as they were finishing up. “I’m guessing this whole process ownership thingy has got you tied up in knots too.” He tried to sound nonchalant. “To be honest, I don’t see how we can come up with a process implementation plan in such a short time frame.”
“We don’t have to,” Jim quipped. “It’s not like we’re the Christopher Columbus of IT Service Management trying to discover the new world. All the stuff we need to get started is out on the ITSMO portal.”
“ITSMO portal? What’s that?” Bob looked incredulous.
“You’re kidding, right? Don’t you remember the briefing we got during the Foundations course? Jim studied the quizzical look on Bob’s face for a moment, and then offered, “They gave us some slick sheets about all the templates, guides and framework stuff on their web portal and on their wiki site.”
Bob played along, “Sure, yeah, uh… now I remember.”
Zipping his lunch bag shut, Jim reached into his coat pocket and pulled out a creased informational slick sheet from the Foundations course. He handed it to Bob. “The URL is at the bottom. It’s got what you need. I’ve got to run, meeting in five.”
“Thanks!” Bob said, and both men headed back to their respective offices. Back at his desk, Bob riffled through the desk drawer into which he had stuffed all the information, booklets and other paraphernalia from the Foundations course and pulled out the colorful information sheets that had been handed out to the students. Sure enough, the ITSMO portal information was right there. He turned to his computer and typed the wiki URL into the browser window.
He “agreed” with the U.S. Government information systems warning page, but then the milSuite wiki portal required a one-time registration of his DoD CAC in order to log in. “Here. We. Go…,” he thought to himself, recalling how difficult it usually was to register and access most internal government websites. He stepped through the one-click registration process, watched his CAC reader’s blinking red and yellow lights as it scanned his card for the digital permission slip, and — bingo — the Navy IT Service Management Office wiki page popped up on his screen. “Not bad,” he said to an empty office and started reading through the main page of information.
The history of the ITSMO was nice and probably worth a good read at some point he supposed, but for now he was intently interested in getting at what he came for — templates and guidance. He noticed the ITSMO had divided its stuff into what it called “Practice Areas” labeled Process Architecture, Service Quality, IT Governance, Assessment and Audit, and Strategic Communications. There were also a couple of milTube videos embedded on the main General Information tab that apparently explained what the ITSMO was all about, and another one from the DoD Enterprise Service Management Framework (DESMF) Consortium. That would have to be for later. For now, he clicked on the Process Architecture Practice tab.
Inside the Process Architecture portal he found yet two more videos; one was an ITIL v3 overview brief and the other was an NPRM overview brief. According to the introduction text on the screen, NPRM stood for the Navy Process Reference Model. There were also links to the Process Architecture slick sheet he had been given previously, an overview brief of the practice and a redacted example of the NPRM. He was intrigued by the NPRM overview brief video, so he clicked and watched the slideshow presentation unfold as the presenter explained a bit about the ITSMO and then the NPRM itself.
Bob continued to run through each of the practice areas during the afternoon and began to appreciate the scope and depth of resources he could leverage as a process owner. The NPRM gave him guidance on the role of the process owner, and some industry-based skills that would be helpful in performing in that role. He also reviewed the role descriptions and recommended skills for the Request Fulfillment Process Manager, as well as a role he hadn’t considered — that of the Request Fulfillment Coordinator. He also began to understand and appreciate each of the process activities, each connected to the next, with explanations of what should be going on, and the RACI charts that suggest which roles should be Responsible, Accountable, Consulted or Informed in each activity.
He took note of the ITSM Lifecycle that was also available, but his head was swimming a bit from the discovery of this NPRM resource, so he jotted a note in his calendar to review that tomorrow. He thought for a second, and then added the IT Governance practice area to the note. He felt sure that as a process owner, he would be part of the governance mechanism that steered the enterprise toward policy objectives — and if it wasn’t mentioned, then he would bring it up. “That wouldn’t be a bad way to start off,” he mused.
He also noticed there was an ITSMO Newsletter online sign-up form so filled out the form and moments later received a confirmation email from the ITSMO Stakeholder Registry that he was registered as a Navy ITSMO stakeholder and would begin receiving newsletters and other information about new or updated products and services. Before he left for the day, he attempted to access the official ITSMO repository or portal where all of the artifacts are housed, but that would take a bit longer — that site, hosted by iNavy, required an NFO account, which he learned stood for Navy Forces Online. He went to the NFO registration page, filled out all the required information and submitted the form.
Until that process worked its way to a conclusion, he had enough information to digest and felt satisfied that he’d be able to put together a rough outline of how the Request Fulfillment process, and his role as a process owner, was going to be structured… not based on his very limited experience, but based on industry best practice.
Tuesday brought a fresh outlook on his impending role as a process owner. Now he began to imagine the trees as individual parts of the collective ITSM forest. And what do you know? Sitting in his email inbox was a notice that his NFO account had been approved and created. Time to jump online to the ITSMO repository and see what’s there.
The first thing he noticed, not that anyone could have missed it, was the large graphical representation of the Navy ITSMO Service Management System — SMS for short. The SMS showed each of the practice areas he had seen and reviewed on the milSuite wiki, with more information about what artifacts and services were available. He clicked on the Process Architecture link. “This is a SharePoint portal,” he again said to an empty office. He was very familiar with SharePoint and quickly located the document type drop-down button for Template.
“…and then boom, there it all was! RACI templates, process guide templates, workshop checklists, tools guide template, and on and on!” Bob could hardly contain his enthusiasm for having discovered a treasure trove of ready-made material that he could tailor to his situation as a process owner. Jim stopped chewing on his carrot stick long enough to let a grin migrate across his bearded face.
“So you like this ITSM stuff now?” Bob glanced down at his half-eaten sandwich, a bit embarrassed. Jim didn’t miss a beat, “I had that same reaction when I first went to Navy ITSMO website and wiki. I just had a month or two head start on you, which is why I’ve already put together my POA&M for implementing the Incident Management Process. After last week’s meeting, I knew exactly where to go and what tools to download.”
Bob’s enthusiasm returned, “Can I take a peek at what you’ve already done?”
“Sure,” Jim replied. “In fact, at this rather nascent stage of development, all you’ll really need to do is globally search for ‘Incident Management’ and replace it with ‘Request Fulfillment.’ Then do a read-through and come prepared to talk about the high-level plan to start implementing your process. For our next meeting, I’d recommend we take a hard look at a governance construct that will enable us as process owners to give direction and get a handle on how things are progressing. But this is going to take time, so we’ll both grow into our roles.”
“That sounds great,” Bob said, “and I remember there was an entire practice area on the Navy ITSMO website devoted to IT Governance. Maybe we can hold a workshop slash planning session to go over how we should implement it.”
Tapping his brow with his index finger, Jim almost blurted, “I’m way ahead of you — I’ve already submitted a Service Request on the Navy ITSMO portal requesting SME support and a Q&A brief for IT Governance. I’d be glad to add you to the invite for later this week.”
“Okay.” Bob had to grin. He realized Jim was on top of his game and had a vision for how he wanted to proceed, and using the assets of the Navy ITSMO was at the top of his list. He was convinced Jim would be an irrepressible champion for the Incident Management process and he wanted to capture that enthusiasm for his own process, and being in lock-step with Jim on his implementation plan just made a whole lot of sense — especially since Incident Management and Request Fulfillment had so many touch points.
As they finished lunch, Jim began to confide to Bob about his plan for implementing IT Governance over his process.
Stay tuned for Part 2 — “The Stairway to Success” in the October-December 2014 edition of CHIPS.
About the Navy ITSMO
Chartered in April 2012, the ITSMO provides IT Service Management thought leadership and assistance by creating usable products and services for the Navy ITSM community. The Navy ITSMO strives for alignment of enterprise IT architecture through discreet but interlocking practice areas to help define and support organizational IT governance and management requirements. The Navy ITSMO resume boasts industry-certified expertise in ITIL, COBIT, Program and Project Management, DoDAF, IT Risk Management and Control, IT Skills Framework, Service Quality, CMMI, ISO/IEC-20000, ISO/IEC-15504, Information Security, Enterprise IT Governance, and Assessment and Audit.