Lessons Learned for Successful Request Projects – How to Scale the Heights of Success, not Plumb the Depths of Despair

It is rather surreal doing this blog post. I feel as if I am in a re-run of “Back to the Future.”

I am putting the finishing touches on this post before I present the session KEG, but because my internal clock is still set to Australian time, I am really doing it on the day after. These are some of the problems in living life “Down Under,” or as we Australians think of it, “Up Over.”

Australia- Up Over


Other problems include the “two nations separated by a common language”  that I encounter every time I visit. Please don’t ask me what team I “root” for or whether I would like to buy a Denver souvenir “fanny-pack.” Be careful asking me the way to the “bathroom” as it will get the response: “I’ve got a bath in my room, haven’t you?” We only have loos, dunnies, lavs, bogs or, if in polite company, toilets, and I take great delight in directing any American visitors to the room in my house that has only a hand-basin, shower and bath and not the other small room that has the toilet pedestal and watching their faces when they return with cleaner hands but a slightly more distressed look.

But enough of the cultural differences.

A little about myself and why you may be sitting in this presentation (if so, please put the iPad away and look at me) or reading this alone in your office or home (I assume because you have come to such a boring moment in your life when reading a blog entry of mine adds some excitement).

Well, I discovered the other day—through an automated message sent by our internal version of Facebook called Yammer (hopefully I get something for the plug—but not another bloody t-shirt please) that I have been with Kinetic Data (hereafter, KD) for over 8 years! That re-assured me, because I thought it had been forever…

I also have to admit that I am the oldest person in KD—but of course this does not mean that I am the wisest—as this blog post is proving!

Prior to KD—I can dimly recall that there was such a time—I have been with a number of IT companies working with BMC Remedy and other applications (they do exist), many of which have now melted away like the snow flakes which may be falling outside, when the sun warms them.

So, I hate to admit it, but I have been in this industry for over 40 years, so probably before most of you in this room or looking at this blog post were even in “project initiation phase” and probably before “requirements gathering” and putting out the “RFI or RFP.”

Since then I have worked as a Consultant, Analyst, Designer, Project Manager, Developer, Trainer and even once, on the “Dark Side,” as a Client in this industry of ours.

So, I think I have a right to have a few opinions on this whole “Requirements” business. Hopefully these opinions will inspire some thought, maybe even controversy, and hopefully someone might feel interested enough to have bought me a drink (Single Malt Scotch over 12 YO) to get me to share a little more of my “wisdom.”

OK—here we go.

I was told my Power Point did not have enough bullet points, so I added a second Agenda page. Apart from these two pages, there will be:


This achieves two things: 1) you might listen, and 2) I don’t have to think of another way to say the same things without using the words in the bullet points.

(For those reading this blog, who want to look at the pictures, someone will have posted my presentation somewhere on the KD website—so you could download it and enjoy the full experience of course, without the “gosh I like the way you Aussies speak” audio component.

Let me “share with you” my first EDP (look it up) job, programming a door opener. I got paid about $50 for it (in those days that would be USD25—now it would be USD60—how the weak become the strong). After the stunning success I had in fulfilling the requirements—door must open, door must stay open for a while, door must close—the requirements were expanded to encompass the concept of “small room – moving up and down in a controlled way,” so I programmed a bigger controller that incorporated all the great work I had done with the  “Project Door” and added moving a room up and down in a vertical shaft, stopping and then doing the door bit. We called this “Project Lift”—or in American—”Project Elevator.”

This was the first time I had been confronted with the idea of requirements analysis in the “real world.” I was obviously excited.

They were simple requirements. We did have a discussion as to whether the doors should open in an “organic, caring and cool way”—it was the 70’s—but we knew that person was a closet hippy, so we ignored this suggestion and just went for “slamming open and slamming shut.” A lot of people nearly lost limbs because of this —but I had the cheque (check) and had moved on to bigger and better things like the Traffic & Parking Infringement Notice system for my home state (Australians have the same urge to make an acronym of everything—that is, when they cannot add an “ie or y” to a name—and we called it the “Project Tin-Pins’.” Yes, there were nerds even in those days and we were they.)

So that brings me to the point of the is session.

How to achieve a successful Kinetic Request project—and—taking a leaf from the “Self Help and Actualisation Movement,” or as I like to call it, “SHAM”the path to success is:

Achieving Oneness with Request ManagementONENESS…

Normally the first interaction you have with any vendor is through the sales team.

Sometimes the interaction is like this…

Over-promise…Get the deal…Under-quote…Under-resource…Under-deliver

At Kinetic Data, we try to make sure that we do not do that.

At the heart of achieving this is ONENESS between the client and Kinetic Data.


Without clearly stated initial requirements everyone is working in a fog of doubt and uncertainty.

Vendors build-in large buffers for this uncertainty and often still under-quote for the project.

Once you have decided on a vendor for your project, work with the internal and vendor teams to:


Things to consider when doing this:

  • You may not have all the information; consult widely with ALL stake-holders.
  • There is only  piece of clothing where “ONE-SIZE-FITS-ALL”—a straight-jacket.
  • Trying to combine features of different offerings is rarely a success.
  • Just because it can be done, does not mean it should be done.
  • It may be a solution—but is it practical?

There is a reason why you are initiating this project, and it normally not just to:

  • Replicate the existing application
  • Change the appearance slightly
  • Bolt-on some new functionality
  • Get a more powerful application but restrict it to the old limitations

A successful project should deliver improvement. Not repackage the status quo!

To achieve this, all the parties have to be able to be flexible and willing to change expectations and requirements to deliver the BEST solution within budget and on time.


Be realistic. Rome was not built in a day.

If you have been set firm dates  and budget to deliver, then make sure that the requirements are aligned.


We are now in partnership with you to deliver SUCCESS.

It is not a battle between two sides—one trying to get more than agreed and the other trying to do less.

Remember that in a difference of approach, the consultant will advise on the best solution, but at the end of the day—if the client wants it, we will build it.


So we now have a project that has REAL, WELL DEFINED and ACHIEVABLE requirements.

So, let’s stick with them when we develop the SOW and during the delivery period.

Tacking on new requirements while development is going on does not work. It adds to costs and delays.

Importantly, it just shows that the requirements gathering was a failure.

Finally, remember the ultimate measure of success is the satisfaction of your users.




What is this “Level 0” thing? (Part 2): Knowledge, Self-Analysis and Feedback

Tools of the Trade (Part 2)

A Vision From Down Under
By Michael Poole

In my last blog, I mentioned a major client who is ‘shifting to the left’ and implementing ‘Level 0’ methods.

For those who missed my last blog, in short, ‘Level 0’ is the process of enabling users to resolve their own incidents and requests.

Obviously, one way of implementing ‘Level 0’ is to shut off the phone lines and email addresses of the Help Desk. A very effective way of getting users involved in the process, but not one I would recommend to anyone wanting a long future in an organisation. Of course, sometimes we implement this method by under-resourcing our support teams – but that is the subject for another blog.

To implement ‘Level 0’, users have to have the information available to them to resolve issues as they arise. So how do we give these to them.

There are a number of tools available.

The Knowledge

It has been famed around the world that London cabbies spend years “doing the knowledge” — learning every street, lane, theatre, hospital and pub in London — before they can sit for the exam to obtain a cab licence. Do we need to ensure that before any person joins the organisation they have an intimate knowledge of computer hardware, software, networking etc.?

No, because now, they can be like today’s Sydney cabbies who avoid “the knowledge” by having a SatNav or GPS system in the cab. Our users’ SatNav can be a Knowledge Base.

The move to implementing “KCS” or Knowledge Centred Support has been going for a number of years, but for many organisations, this has been limited to building knowledge bases directed at and only available to the support team — not the user. With the development of Web 2.0+, users are becoming more accustomed to “googling” for solutions and answers and also using self-help resources that are a part of the major social media sites. I admit, in doing these blogs, I have often consulted the blog site’s help pages and Support Forums.

So KCS is one of the tools that can be deployed as part of the “shift to the left.” But to do this, we have to make sure that we develop our KCS articles, not for computer engineers, or if we are deploying across an enterprise , HR experts or accountants etc, but for the average user and common issues.


No, I’m not becoming Tony Robbins — all “SHAMish” (Self Help and Actualisation Movement) — perish the thought — or bringing Freud onto the Help Desk — even though at times he might be useful in dealing with users, but more IKEA!

The results of some IKEA assembly projects might belie the concept — but I assume that they have more successes than failures through the step-by-step self-assembly process.

A few — well maybe many — years ago, I was involved in a project that required me to have what is called an “Assumed Rank” in the Australian Armed Services. I made Colonel for a month — the duration of the contract — but thankfully did not have to do the physical, wear a drab khaki uniform, bear arms or be saluted. But I did get into the Officers’ Mess and people had to answer my questions in a respectful way, but that is past. What I did get to find out was how the most complex maintenance and repair processes for a fighter jet could be broken down into simple steps and documented so that even I could have replaced, as an instance, the wiring loom on an F-111 or the laser-guidance system. The “repair manual” — and it was all hard-copy — was contained in a room-full of filing cabinets and needed a librarian to keep it in order and up-to-date. This of course was an extension of the production line methodology introduced by Henry Ford at his eponymous company to make the most complex consumer engineering  product of the day — the motor car — with relatively unskilled workers. Other car makers of the time were using skilled engineers and coach-makers to make one car at a time.

As the makers of the F-111 and Henry Ford knew, every process can be broken down to simple steps and delivered in an appropriate way to produce a complex result. For Ford this was a car; for General Dynamics it was the F-111 repair manual; for us this can be a fault-finding and resolution process.

In fact for the client mentioned above, we implemented such a system — a fault-finding process that enables staff with little or no technical knowledge to analyse and, in over 30% of cases, resolve issues with lap-tops ranging from OS to wireless network issues through a series of simple steps that relied on the answers to a number of questions and test activities that they could understand and carry out.

So another tool in the “Level 0” process, is intelligent and responsive self-analysis and resolution tools. What is sometimes called an “expert system.”

Information, Contribution, Monitoring & Feedback

Implementing “Level 0” also requires openness of information and a positive response to user feedback.

Users should be given every opportunity to be a part of the process.

Where KCS is implemented, users should be able to rate and suggest improvements to KCS articles and guides and also author and submit new KCS articles. As well as providing another source of input into the KCS system, users will develop a group ownership of the KCS system and its acceptance will be more easily gained.

This is also true of any self-analysis and resolution process. A network engineer may be able to define the step-by-step process for resetting a head-end switch, but it may take some input from an end-user to enunciate the process in easily understood vocabulary or point out areas that need better definition.

Users must also be contribute to the areas that need to be covered in the KCS or self-service system. What the experts think are trivial matters, may be a source of confusion to users.

Access to monitoring information in a easily understandable format can reduce calls on the Service Desk. If users know that a system is down for maintenance then they have no need to log a call.

And of course feedback to users is essential when they make a contribution or highlight an area that needs better coverage.

In part 3, I will look at ways to integrate these tools into web-based portals that can be deployed to users.





What is this ‘Level 0’ thing?

A Vision From Down Under
By Michael Poole

Last week I was a part of the Service Management Forum (SMF) that one of our larger clients in Australia has formed to bring all stakeholders in the IT area together to plan and implement the future of IT support and service delivery.

With a base of over 70,000 users geographically spread over an area of 809,444 km2 (312,528 sq mi—nearly 3 times the size of Nevada) it is a vital matter .

With a new leadership, they are now wanting to embracing ‘Shift to the Left’ or ‘Level 0.’

What is ‘Shift to the Left’? What is ‘Level 0’?

Let us look at the standard support model we all know and, perhaps, love.

It starts at Level 1 with the Help or Service Desk operator logging and hopefully resolving incidents or requests. If this is not possible, we move through Levels 2 and 3 etc. of the support and service layers. In this model, the user who contacts the Help Desk takes no active part in the correct resolution or fulfillment process. The support and service team use various tools to get to a resolution. These may include: Call Scripts, Knowledge Bases both formal and informal, automated fulfillment services/applications, interaction with other team members etc.

If we look at the support levels as a series running from left to right with the lowest—Level 1—on the left and then add Level 0 (the user) to the left of Level 1, then we have a ‘shift to the left’ with ‘Level 0’ as the first level of support.

Level 0 is all about creating an environment where the user can commence and, with the right tools, resolve an incident or fulfill a request WITHOUT having to involve the conventional support and fulfillment teams.

Let’s admit it, ‘Level 0’ can be a challenge to conventional support and fulfillment structures. The Help Desk is a well established and understood method of providing support to users. Users and support teams both can feel  uncomfortable with this model.

Done badly, it can result in frustration for the users, who feel that they are being abandoned and the support team feeling that they are being ‘put out of a job.’

Done well, the users will get a resolution faster and the support team—at all levels—will be engaged in the more challenging issues while not being overwhelmed by trivial issues that can be resolved easily.

In my next blog on this topic, we will look at the tools which enable Level 0 and, of course, how the Kinetic Suite of applications can be an integral part of addressing the challenges.

Lost in Translation


perdu dans la traduction

pierde en la traducción

потерял в переводе

No matter which way you say it, being lost in translation is not just the name of a Hollywood Romi-Com—it can be a nightmare for companies that need to support users in multiple languages.

Handling multiple languages is becoming a requirement for most companies. Globalization is one driver, but more and more, with a growth in the diversity of community languages within most countries, to provide the best and most cost-effective request management to our users, being able to present a user interface in a community language is becoming a necessity.

In Australia—one of the most diverse multi-cultural countries after the United States, most government departments and major corporations provide web-pages and pamphlets in a variety of community languages.

In Europe, while the EU has one currency, it most certainly does not have one language. Multilingual is an essential for business.

So how can make sure that we make sure that our users and business is not ‘Lost in Translation?’

Let’s first look at a what we are really talking about.

Internationalization, multilingualization and localization—Not the same thing!

Wikipedia has this to say about the topic:

The support of multiple languages by computer systems can be considered a continuum between localization (“L10n”), through multilingualization (or “m17n”), to internationalization (“i18n”).

  • localized system has been adapted or converted for use in a particular locale (other than the one it was originally developed for), including the language of the user interface (UI), input, display, and features such as time/date display and currency. Each instance of the system only supports a single locale and there is no explicit support for languages that are not part of that locale (although the character set may coincidentally be usable for other languages).
  • Multilingualized software supports multiple languages for display and input, but has a single UI language which cannot be changed after installation of the software. Multi-locale support for other features like date, time, number, and currency formats varies as the system tends towards full internationalization. … In general, a multilingualized system is intended for use in one specific locale, but is capable of handling multilingual content as data.
  • An internationalized system is equipped for use in a range of “locales” (or by users of multiple languages), by allowing the co-existence of several languages and character sets for input, display, and UI. In particular, a system may not be considered internationalized in the fullest sense unless the UI language is selectable by the user at runtime. Full internationalization may extend beyond support for multiple languages and orthography to compliance with jurisdiction-specific legislation (in respect of copyright, for instance) and other non-linguistic conventions.

While internationalization is the strategy that ensures that both local, legislative and language requirements are met for all possible environments and users, it is also the most complex and demanding and may not be the correct strategy—in fact it may be excessive in many circumstances.

So how can we decide whether we localize, multi-lingualize or internationalize?

As we deal extensively with user request forms and processes in our practice at Kinetic Data, here is a check-list—not comprehensive, but is a good starting point—for determining what approach we should take expressed with Service Requests in mind.


  • The request form will only be accessed and fulfilled by users in locations that share the same language, information formats, and process requirements
  • There are very few—less than 2 or 3—localized versions of a similar request type. More than that will make maintenance of multiple forms a time consuming process
  • The process is unique for that location and cannot be adapted for other locations or languages etc.


  • The only difference is the display language
  • Date/Time, currency etc formats are handled by the application environment
  • It is possible to determine or have the user select the language
  • The same form and process is to be used by all users in the all locales and languages
  • Users need to be able to see the same form displayed in a choice of languages not dependent on locale


  • There are differences in the form and processes requirements that are locale dependent
  • The maintenance of one set of forms and processes is preferable to the maintenance of multiple forms and processes to cater for locale and language variations
  • It is possible to determine or have the user select the locale and language
  • The same form and process needs to be used by all users in all locales and languages
  • The user may want to select a particular locale and language combination e.g. a user may be in Australia but want to view the request form in Vietnamese for a service that will be delivered in the United States and comply with that locale’s requirements

Kinetic Request has a number of features that make any of the strategies easier to implement.

As well, we have now developed a functionality in Kinetic Request that uses an industry standard Java language translation library to enable one Request Form to be displayed in multiple languages—including non-Roman script languages such as Japanese, Chinese, Arabic, and Hebrew. This functionality goes down to the level of selection field, menu labels and pop-up messages that may be in a Request Form or Catalog Portal.

Kinetic Strategies


  • Create forms and process for a base locale
  • Either use those forms and processes as templates for new forms and processes or use Kurl  to create new forms and processes which have been modified for the next locale. NOTE: localization may not involve a change in the language of the form—for instance a form used in the US  can be deployed in Australia using the same language (ignoring the slight differences in spelling of some words), but the process requirements and field checking will be different for some fields e.g. State is common to both locales but have different different formats.
  • Make the localised forms and processes available to each locale through a localized catalog or a specific URLs
  • Caters for large differences in form and processes requirements with a reduced effort in creating locale aware forms and processes
  • Large number locales and languages and processes changes can develop into  maintenance black-hole
  • Introducing new locales and languages requires creation and modification of new forms and processes
  • Reporting and auditing only on multiple forms and processes
  • Lacks flexibility for multiple languages in one locale and visa versa


  • Leverage the ability of Kinetic Request to use the industry standard Java translation libraries to translate forms to the required language
  • Create the forms and processes in a base language
  • Populate the translation tables with the equivalent labels, display values and text strings in each target language
  • Either scrape for or let the user select the language
  • Adding support for new language does not affect the form
  • New language requires only editing of the translation table
  • Changes in requirements only need to be applied to one form, process and translation table
  • Changes or corrections  in translation applied through translation table not the form
  • Reporting and auditing only on one form and process
  • Form or translation needs to cater for translation layout differences – size of resulting text or direction (e.g. Right To Left)
  • Create forms in a base language
  • Leverage Kinetic Request functionality to control fields and display layout – either at the server or client level – to cater for locale difference or requirements
  • Leverage the ability of Kinetic Request to use the industry standard Java translation libraries to translate forms to the required language
  • Create processes (e.g Kinetic Task trees) that are aware of locale requirements and differences
  • Populate the translation table with the equivalent labels, display values and text strings in each target language
  • Either scrape for or let the user select the locale and language
  • Adding support for new language does not affect the form
  • New language requires only editing of the translation table
  • Changes in requirements only need to be applied to one form, process and translation table
  • Changes or corrections  in translation applied through translation table not the form
  • Reporting and auditing only on one form and process
  • Form or translation needs to cater for translation layout differences—size of resulting text or direction (e.g. Right To Left)
  • More complex initial form and process development

As you can see, Kinetic Request and Kinetic Task give you the ability to deliver the correct solution to your users so they are not ‘Lost in Translation!’

Facebook Has Taken Over the World

A Vision from Down Under
By Michael Poole


We hear this, even in the antipodes, so often and it may be true, especially for anyone under 40.

Why? Well, obviously it provides a way to communicate with friends and acquaintances; but it’s unlikely it would have been as successful if it had followed the design methods that can be found in too many corporate intranets.

One of Facebook’s major features is “consistency.” Consistent styling; consistent behavior; consistent look-and-feel.

Consistency is paramount to the success of all successful social networking sites. In fact, consistency is such a hallmark of these sites that ANY change to the design makes headlines or at least millions of wall posts!

If Facebook was like most corporate intranets, I doubt if users would have returned again and again.

The “public” internet sites of companies are owned and controlled by the marketing department whose whole purpose is attract visitors and ensure that the site is friendly, usable and informative. They usually follow the same design philosophy that has produced Facebook – consistency and ease of use.

Intranets, on the other hand, are usually owned by IT departments and the content is produced and published by individual departments with differing design (or non-design) skills.

Each department will often have a different set of design parameters and styles. Without a set of design guidelines that stress consistency and ease of use, the intranet can easily look like a “mash-up” – or perhaps a “mess-up” – of isolated intranet sites with jarring and confusing inconsistencies from page to page and area to area.

We have all experienced the corporate intranet that changes themes, banners, fonts for each department area. Intranets that use different layouts, even within department areas – some departments may have text links to some forms, buttons for others; one part of the site may work with IE9 – other parts need will not work with IE7; one might use bold, bright colors, another subdued pastels. The variations can be as many as there are contributors to the intranet site.

Rule one for a successful intranet

The intranet should look and behave in a consistent way. Having an intranet that changes its appearance and behavior between sections disorientates users and can introduce doubts into their minds as to whether or not all sections are as reliable and current as each other.

Of course, I can hear some of my readers saying: “Yes, we tried to do that, we had a theme designed, set standards for user interaction, had a template for all pages. We did all that but then we had to integrate a web-based application into the intranet and it all went bad. We could not change the way that application looked or worked, so we just had to compromise and accept it.”

So, many people, though trying to build in consistency into the intranet, are brought to a crashing halt by having to incorporate inflexible and inconsistent applications.

Why has this happened?

Let’s face it, most corporate applications have been around for some time. Many pre-date the internet and most certainly Web 2.0. They have been developed for dedicated user clients – some were even developed for dumb terminals. And when they produced the “web” version they did try for consistency – but it was consistency with the old, pre-web version. As a result, they produced clones of the old client down to the colors, key-strokes, layout etc.

With this design philosophy – consistency with the past – when they developed “new” functionality, they repeated the design errors of the past. And because in the past they had prescribed the layout, theme and style of the application, they did it again with the new functionality. As a result, application portals came so they fitted in with the parent application and not easily, if at all, styled to be consistent with the intranet they would be integrated into.

If you want a graphic (no pun intended) proof of this, look at the majority of ITSM application vendor’s web offerings – nearly all clones of the dedicated client interfaces of the past.

Should this be the way?


The web is designed to be able to be styled and themed in very powerful ways giving developers the ability to produce interfaces and pages that can be easily integrated into any existing style or theme or to any device.

One way to do this is to use Cascading Style Sheets (CSS) to define the look and feel of an individual web page or a whole site.

This is the strategy that we have embraced when designing not just Kinetic Request forms but the whole Service Request Portal interface. We have empowered our clients to easily integrate both Kinetic Request forms and portals seamlessly into their existing intranets by leveraging the CSS definitions that they use for the rest of the intranet site. The result is CONSISTENCY – consistency of style, functionality and experience, and a reduction of confusion.

By putting the focus on enabling consistency of styling and functionality in the web interface to request management and fulfillment, our users have not had to compromise the consistency of the intranet. The payback is not only better customer satisfaction and better adoption by the users but also a reduction in costs of implementation, user support and training.

It is not the magic bullet – your intranet will never be as popular as Facebook and you will still have to battle to get HR to follow a design guideline – but having the power to enforce consistency is a major step along the way!

Are We Living in a One Horse Town?

A Vision from Down Under
By Michael Poole

Now, living as I do in Australia and being of a certain age, I can recall spending my holidays on a sheep and wheat farm in, what we Australians call, “the bush.” For those not acquainted with that expression, “the bush” is anywhere outside of a major city and typified by a lack of lights on the road and the possibility of a surprise meeting with a kangaroo on the same unlit road around dusk – which has a similar effect as our northern cousins meeting an elk.

So, in those days, there was a always a “country town” within one to six hours of most farms. The town near my uncle’s farm was pretty close, a one and a half hour drive along dirt roads, and consisted of one “pub,” Police Station (we are descended from convicts), Church and combination Petrol (Gas) Station/General Store/Post Office.

The next town was four hours away and about the same size except that it had an additional pub.

Now, going to town was an event. Usually undertaken on Saturday morning, we all dressed up in our nearly best clothes – not Sunday best, as it was a Saturday. The kids piled into the back of the “ute” (pick-up) and ate dust for an hour and a half. Brushing ourselves off after arriving in the town, the family split up to carry out each one’s appointed task.

Uncle, of course, had to fulfill his civic duties and always attended a meeting of the local farmer’s committee. Strangely these meeting were always held in the pub. They were thirsty work!

Aunt and the rest of us went to the General Store. There was an amazing range confectionery displayed on the counter-top, but surprisingly, other categories of items like food, hardware, etc. had little variety or choice. If you wanted flour, the choice was easy – there was just one brand and two types: plain and self-raising.

As there was only one General Store, of course whatever we needed had to chosen from what it supplied. There was little chance of getting a better deal by comparison shopping, and even if we knew that there was an alternative product that was better, if the store didn’t sell it, it was just too bad.

We sometimes suggested to Aunt that we could go to the other town and buy the better product, but she never did – she didn’t want to upset the store-keeper – and anyway, if he wasn’t supplying it, there must be something wrong with it.

I think back to those days when I go to the supermarket and have such an array of products to choose from. I even have a vast array of supermarkets and on-line stores to choose from.

So, what has this got to do with our real focus in this blog?

Well, I also remember those days when I talk to CIOs and IT Managers who are grimly holding to a Single Vendor “strategy.”

There has been a continued debate, not just in the IT community, on the topic of Single vs Multiple vendor implementations.

So what are the things that should be considered when deciding between these strategies?

Flexible to Innovation: When solutions are built upon open standards, enterprises have the ability to adopt new solutions, as their businesses grow and need change, or as new and improved solutions become available. Since a multi-vendor strategy is inherently an open-standards strategy, vendors must continue to innovate in order to create competitive advantage, driving new advances that result in higher performance solutions.

A single vendor with a broad portfolio of products will by its very nature always have products that lag behind others due to resource allocation, disparate product lifecycles, and shifting areas of focus. Furthermore, a single vendor strategy results in a lockout strategy for any competing vendors, even when they offer a superior solution. A multi-vendor network strategy based on open standards doesn’t demand you to sacrifice innovation or flexibility. In fact, innovation and flexibility are its byproducts inherently.

Who has the Advantage: Many organizations justify a single-vendor strategy because they feel they have the advantage when dealing just with one vendor. However, this is not the case as the figure below shows. In fact, by giving preference to a single-vendor, the advantage is shifted to that vendor. Strangely, this is one of the objectives of any vendor – to lock the client into a solution set and making it difficult if not impossible to to change vendors or introduce new technology that is not supported or supplied by the vendor.

The vendor Influencer Curve
Gartner’s Vendor Influencer Curve advocates a multivendor approach to based on clear business/IT objects,vs the single vendor trusted adviser approach favored


Single Vendor Myths
Limits Complexity: Many vendors, who claim to provide everything an enterprise needs to meet its technology requirements, have actually built solutions through acquisition with products that weren’t necessarily designed to work together. Superior Support: With diverse and varied products, support is provided by generalists with broad experience vs specialists with deep knowledge. Lower Operational Cost: In addition to often requiring increased support costs for aging technology, selecting a single vendor to provide products for all areas may actually increase costs due to the limited ability to negotiate pricing as well as support aging technology. Acceleration of Innovation Adoption: With a single vendor, enterprises are actually limited to innovations. Increased Operational Efficiencies: A vendor wouldn’t source all its materials from a single vendor due to the increased risk of relying upon a single source. Why should an enterprise customer be any different?

Reducing Risks and Costs: While relying upon a single vendor poses a significant risk for enterprises, a multi-vendor strategy actually mitigates this risk by reducing exposure to a single vendor’s decisions, from arbitrary product rationalization and service discontinuation to pricing increases. But the risk reduction benefits of a multi-vendor network strategy don’t end there. A single vendor strategy puts the enterprise at the mercy of a sole source that can increase costs through mandatory upgrades, compulsory support programs, and equipment packages that include products that don’t necessarily meet your needs. But, a multi-vendor strategy actually promotes cost reduction.

Leveraging Expertise: No vendor understands your business and network requirements as well as your technical staff. To move forward with a single-vendor strategy is to abdicate control over the decisions your technical staff is trained to make, and place the control of your network destiny directly into the hands of a third party. By giving you the ability to select solutions based on your business drivers, not your vendor’s, a multi-vendor strategy ensures that you are at the helm of your network.

Specialized Support: Today’s complexity requires that technical support be delivered by experts with deep knowledge in specific areas. Since single vendor strategies are designed around broad product portfolios and supported by generalists who sacrifice depth for breadth of knowledge, finding the right person with the right answer can take time. Multi-vendor strategies ensure that you have access to specialists with a focused expertise necessary to effectively resolve issues, minimizing the impact of interruption to your organization. When you develop your network requirements to support your business strategy, and not to support a single vendor’s point of view, the enterprise is positioned not only for the future – it is positioned also to win.

Self-Fulfillment—Not a SHAM

A Vision from Down Under
By Michael Poole

The other night, I made my usual stop at the supermarket to pick up a few things for dinner. I am doing this more often now that my son has moved in to be nearer his University. I also am finding that his 18-year-old’s appetite and eating habits are something akin to those of a herd of locusts passing over a particularly attractive stand of wheat!

So, with my laden basket, I approached the “checkout choice” moment. There’s choice #1, the normal queue, where you get the full human experience but have to wait behind the shopper who is buying for a family of 12 for the next 12 months; choice #2, the “12-items-or-fewer Express” queue, where I inevitably get behind the innumerate shopper who has 35 items stuffed into the basket; or choice #3, what I call the “Self-checkout” queue, where you get the chance to scan, weigh and bag and then swipe your card for payment. I, of course, went for “Self-checkout’.

Now I think I foolishly revealed a couple of blogs ago, that I recalled with some warmth the days of punch-cards and paper tape in the EDP (Electronic Data Processing) industry. I am also old enough to remember the transition—that should be called a revolution—of the grocery store, through “cash and carry” to “self-service.” Gone was the smiling grocer with his long grabbing implement to get items from the high shelves prior to bagging them and later delivering them to your door.

Self-service revolutionized the grocery industry and then went on the do the same for clothing, shoes, hardware, white and brown goods to ultimately end up in the supreme embodiment of self-service—IKEA—where you not only self-serve but self-construct the items you have purchased. The “flat-pack revolution” with the  “Allen-key” replacing the gun.

So, back to the self-checkout.

After self-scanning and self-weighing vegetables and selecting the appropriate ones from the screen (I can’t help but wonder how many people click on potatoes when they are really weighing an exotic and expensive imported fruit? Not me, but I have been tempted!), self-bagging my item, and finally self-swiping my credit card for payment, I took the receipt, picked up my shopping bag, and was free to go. As I left, I heard the plaintive sound of the scanner thanking me for visiting the store.

A little while ago, no matter what the amount of my purchase, I would have had to wait for a customer service representative or perhaps retail experience facilitator to check my signature and authorize the card transaction. But now it seems that they are either tracking my previous self-check-out experiences, have a face-recognition system that thinks I look honest, or have a minimum purchase level that is automatically approved. A sensible idea in any case and it reduces the cost to the chain yet again.

So, you may be wondering what my shopping experiences have to with Kinetic Data or the Self-Help and Actualization Movement (SHAM) catch-cry of self-fulfillment.

Well for the former—i.e., Kinetic Data—a great deal; for the latter—SHAM—nothing. So feel safe, I am not launching into an Anthony Robbins moment!

While in the meditative posture adopted by the neophyte scanner, I realized that I was not just involved in an advanced form of self-service, I was SELF-FULFILLING—completing the evolution that began when the local full-service grocer’s shop became the cash-and-carry store.

Just as social networking has been credited with major developments in the Internet, I believe that the supermarket sector has driven the way purchases of goods are fulfilled.

We are now really in the land of self-fulfillment every time we enter a supermarket, K-Mart, or Wal-Mart and their ilk.

How is this related to ITSM?

The push towards service request management (SRM) is, in my opinion, at the start of the revolution that has nearly completed in the retail sector. Whereas in IT we have implemented picking the stock off the shelves—initiating the “service request” in ITSM parlance, we are yet to embrace the idea that the customer can do scanning, bagging and payment transaction themselves—the complete fulfillment process in ITSM.

Why is this so? As a TV physicist of the ’60s used to say.

We have spent a lot of time and effort designing service request systems, service portfolios and catalogues, and service request portals, but they are still just delivering orders to a prerevolutionary fulfillment process that involves multiple tasks, approvals, and work-orders that are, in most cases, still handled by a person.

Think of the common “new starter” request. While we may have an intelligent web-based request form that allows all the necessary tasks and approvals to be started, at the end of the day, all that is produced are tasks yet to be performed—set up login, print security card, order lap-top, configure applications—by people.

The self-service process ends when the request is submitted and the old processes take over to do the fulfillment.

We should be designing not service request systems, but service fulfillment systems.

I don’t think I am alone in this. I may be the first to give it the name self-fulfillment, but at Kinetic Data, we have been involved with a number of thought-leading clients to develop end-to-end SRM processes that are really self-fulfillment systems.

What does a self-fulfillment system look like?

At the front end, the requester end, it looks very much like any SRM system. A portal with a catalogue of services available. It is when you select a service that the differences begin to show. Intelligent forms guide the user through ONLY the options and questions that are necessary for the version of the service he or she is requesting. Upon submission, all the approval rules are assessed and the request is either approved automatically or referred. Once approved, the same intelligent task engine will communicate with all the other applications and create the required records and tasks. Only when something cannot be done by the systems alone will a human be involved and, even then, when that task is completed, the task engine will be ready to take up the rest of the fulfillment process. All the while, the requester will be kept informed of each stage and step of the process.

The major result is the requester being the main actor and as much of the process as possible being triggered and completed by the requester’s action alone.

This is self-fulfillment—it is not a SHAM. It is the next era in the evolution of enterprise and IT management.


Business Service Management—Your Business Your Way

A Vision from Down Under
By Michael Poole

I don’t admit it to many people as it dates me (in the way carbon dates dinosaur bones), but I have been in the IT industry since before it was called IT. It was called EDP (Electronic Data Processing) before IT. Yes, the pre-historic days of punch-tape and punch-cards, real TTYs and mainframes that would heat a good sized stadium in the middle of a Russian winter.

Coding sheets, print-outs on continuous paper stacks our interface to the computer, Assembler, FORTRAN and COBOL were language options—not a wireless connected MacBook and Eclipse.

In those days, we were restricted, not just by the hardware and languages, but by the limited vision of what we were allowed to do.

Through the years, I have seen EDP evolve into IT. We’ve moved from mainframe and dumb terminals through client-server, PCs, workstations, GUI, Various flavours of windowing systems—yes there were alternatives to Microsoft once including X-windows, GEM, NeXTSTEP, OS2, networked PCs, proprietary eMail systems and now the internet and Web.

In all this time, functionality and user experience have improved; applications have become more intuitive and the web browser has become the main interface between users and applications.

At the same time, users have both become more computer literate yet simultaneously less accepting of applications and environments restricting them and delivering limited Web functionality.

Web 2.0 is here, Web 3.0 is around the corner, and users now expect that every site will be as slick, functional and active as Facebook or Twitter.

In IT, we are still happy to have a character based terminal access to some applications and clunky GUI interfaces. Why? Because we are used to them, and they still get things done.

I think that this acceptance by IT is the reason some leading ITSM vendors are able to get away with providing a bare-bones Web portals and a complex and time-consuming processes to expose IT Services to users. Anything that is not their way of doing something is discouraged. To do anything with a sophisticated, active, user-friendly Web interface requires moving away from the OOTB and developing what some vendors call “Advanced” (read: “costly, time-consuming and still restricted by our environment”) forms. What used to be “Your business your way” has now become “Your business our way.”

But users no longer accept that and, increasingly, neither do those in IT. And those in IT who don’t like that approach do like working with Kinetic Request. We at Kinetic Data still believe in “Your business your way!”

Take a close look at Kinetic Request if your business needs:

  • Multiple service catalogues with individual styling, look and feel.
  • To incorporate a mash-up of another site in a service item or portal.
  • A unique approval process.
  • To implement a service catalogue without upgrading.
  • To provide unique service catalogues feeding into one ITSM system.
  • To integrate with this bespoke application.
  • To include multi-page request forms.
  • Multiple ways to display requests based on role, location, language, division, group or user.
  • To trigger tasks outside of the ITSM system without having to integrate through the ITSM system.
  • To cater for non-IT functions.
  • To define every request as an ITSM object—an incident, change, work-order, problem etc.
  • To enable rapid change.

Kinetic Request is designed to be flexible and powerful enough to let me say, “Yes, we will do your business your way” and it won’t cost you an arm and a leg.

So if you want a SRM environment that you are proud of and deliver value to your users, then open a window, lean out and shout, “We need to do our business our way!”—and give us a call—we can only say, “Yes—let’s do it your way”.

Please excuse the spelling of “catalogue” in this blog—here at the top of the world, we spell like the English. 🙂