The Three Perceptions of Implementation

Contrary To Popular Belief Semantics Do Matter! In this article I am going to explore three very different perceptions / definitions about the word "Implement" that are critical in regards to any IT related project but also have a great deal to do with the success of an ITSM program. The source of this article comes from a great book titled "Change & Effect" ISBN 978-87-993289-0-1 on Managing Organizational Change from our Partners in Denmark aptly called Implement Now before the ITIL/ITSM purists protest vehemently that you don't implement ITIL practices, preferring to use the word adopt or adapt let me but this in context. What we are discussing in this article is the fact that you are going to implement a change of some sort into your management system that will impact the processes, policies, ITSM tools, job descriptions, measurements, etc. of your current organization. Also by Implement I am assuming you hope the change to stick and benefits come of all the work and money your organization has invested in your project. The primary point of this article is to reflect on your personal or organizational understanding of this very important word! I may have already tipped my hand in the previous paragraph but consider that in the last decade or so I have seen many organizations fail at their ITSM projects due to the fact that they have greatly underestimated the work effort of their initiative. (Adopting, Adapting, Implementing) ITSM practices is not about simply documenting a process or purchasing and implementing and ITSM software solution. In fact these are only enabler's to the goal of achieving a change of behaviour. More on this subject in the Article. "Establishing Or Assessing An ITSM Program"

However, on a more narrow scope of discussion lets apply the three definitions found in this excellent book. Note: I have taken some literary liberty with the Headings but remain true to the concept's of the three definitions. Install The Software And Let Them Figure Out How To Use It In this definition of the concept of Implement, the focus is typically centred on the software and little to no effort or thought is given to process, policy documentation outside those basic things needed to configure the tool such as the rudimentary classification structures. Any training sessions that are provided are strictly focused on tool functionality. Phrases you often hear from people who hold this perception of the word Implement are: "These folks are IT professionals they should be able to figure this out for themselves" "We don't need to define processes since the tool will provide all the process we need. We will simply adopt the process in the tool" "The tool is very intuitive we don't need to develop much if any kind of training strategy" Book Quote: "Implementation is to install a change, You focus on commissioning the change initiative and handing it off to line managers, expecting them to accept responsibility for it."
The good folks who hold to this perception of the word Implement largely focus on the Tool as the primary element that needs to be considered and managed. Unfortunately they are also the folks that will be accused of another IT project being thrown over the fence for someone to catch without any knowledge of what to do other than login and open a screen or two. Define, Automate The Process and Train Users On How To Do Their Jobs
In this definition of the concept of Implement the focus goes beyond the tool to also having some definition around the job skills, policies, process and automation elements of the new working methods. Focus is given to creating what we often refer to as "Deployment Workshops" where the users of the new process and tool are required to go through a training session that covers both the newly defined process elements and provides exercise / use case based tool training in a lab or online environment before they are asked to begin using the new process. Phrases you often hear from this perspective are: "We need to train process users how to do their new or modified Jobs" "We need to measure how the process is being executed for compliance" "We need to make sure people understand the policies related to the new way of working" Book Quote: "Implementation is to install a change and secure stability of the new state. You launch the change and make it stick by training the users and helping them develop procedures to support and reinforce the change." This approach is typically help by organizations that look at the process and tool holistically and are focused on making sure that that Joe and Jan process user knows how to perform their daily tasks. Establish A Process Governance Structure To Build And Improve On The New Process and ITSM Tool Deployment This perception starts interestingly enough with the understanding that perfection is not the goal. Rather the goal is to create an overall organizational capability relative to the governance, process and tool structures that will target the realization of value from day one but that also focuses on establishing the structures needed to take what is initially deployed and to improve and further refine it over time. In essence the focus of the project is on creating a platform for continual improvement that will take the initial project and hand it over to an organization that will immediately begin to personalize and improve it based on Continual Service Improvement principles. Phrases you often hear from this perspective are: "ITSM is not a project or a short term diet, its the rest of your life" "The goal is not perfection but just good enough for now so we can build on what is first deployed" "The ITSM project is a transformational program needing serious management of change, not just a tool or process documentation exercise" Book Quote: "Implementation is to install a change and build capacity for the organization to develop by itself. You work to integrate the change into current practice while leaving things open for further change. The new elements are not considered an end-state in themselves." Based on my personal experience this third perception of the word Implement most accurately describes the appropriate perspective of an ITSM program. Unfortunately the first two understandings of the word are all too common and often lead to very disappointing and unexpected results. Success with your ITSM/ITIL project is ultimately determined by what foundations and structures you have put in place to take your initial project deliverables beyond the proverbial "Toss Over The Fence" to a more integrated approach to establishing the elements required to realize positive change that endures the test of time. Troy's Thoughts What Are Yours? Things alter for the worse spontaneously, if they be not altered for the better designedly." ~Francis Bacon


Troy ...this posting was focused on ITIL implementations, with emphasis on tools, processes, etc that are used by IT staff. That is good for the "IT as a business" imperatives.

What is your opinion of the tools, processes that are "implemented" by IT on the behalf of the business community? Are there parallels re: how IT handles their own shop (internal customers using ITIL) versus how they accommodate their (external) business unit customers? How are IT (internal) implementations reflective of a culture or attitude towards business process automation? Should we accept IT norms that allow IT to exhibit one behavior internally within IT and another behavior externally for the business end user? ...or are we simply referencing the syndrome of the "cobbler's children" who go without shoes?

Hello Bill

Excellent Comment

There are absolutely many parallels between this article and how IT may or may not support services and applications they supply to the business customer. Much of this has to do with the maturity of their Project Management and Software Lifecycle Methodology. Unfortunately in both cases many organizations are very reactive and have limited maturity.

For this type of organization they often still fall under the first definition of the article. They focus their role and responsibility on the feature / functions of the software or project they are delivering and very literally toss it over the fence in the same way they treat their own internal projects.

For more complex projects such as the implementation of a major ERP system IT will manage the end user training sessions from a business process perspective. However, even the more seasoned IT shop will rarely make it past the 2nd definition for fear of treading on what they see as their customer's prerogative.

This third level is where the Business Service Management component finally kicks in and the IT function acts in partnership with the business unit counterpart. They not only establish the deliverables based functional and non functional requirements but also works with the business function to establish the process and technical governance structures to own and improve the service solution.

Thanks for answering the questions ...for me, you reinforced the strength of the three levels when you identified how IT applies business-oriented concepts to implementing software. The objective seems so straightforward in this context, but that rule of thumb to never "confuse selling with installing" is definitely applicable. It's easier to see what we should be doing than actually doing the task.

It seems to me at this time that the three perceptions you note relate to the gestalt (or culture) of the organization.

I've been responsible now for over 400 implementations of Service and Asset Management. I have no doubt that the Product Management, or what you refer to as Governance, approach is most likely to deliver the greatest success.

But, if the "culture" of the organization is to believe that just installing the software will work - and they are a majority - then that's what one is left with.

As Peter Drucker wrote, "Company cultures are like country cultures. Never try to change one. Try, instead, to work with what you've got."

In the end, management gets the system they want.

Leave a comment


Type the characters you see in the picture above.

About this Entry

This page contains a single entry by Troy DuMoulin published on May 25, 2010 12:14 PM.

Business Service Management: What's the problem? was the previous entry in this blog.

Does SOA + Agile Programming = Crappy Business Agility? is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.