Category Archives: Information

C.O.T.S.

It has long been known that just about everyone thinks that they can build a better mouse trap. Indeed, several in fact have. That is where innovation comes from. By building something better than what currently exists, a competitive advantage is created. It is usually a short-lived advantage as there are many others that are always also trying to innovate as well, who will either copy, or actually improve on the new design.

Add to this, the question of whether you should actually make your own better mouse trap, or buy someone else’s better mouse trap, and you have the makings for a reasonably spirited discussion. Remember, not everyone is in the same mouse trap business. So, do you invest in developing your own, or do you just go out and buy somebody else’s, already complete? However, when it comes to your own business systems, processes and tools, the decision should be very simple.

Unless you are in the tool and system business, never, ever, ever make your own tools and systems.

The tools and systems within an organization usually fall under the purview of the Information Technologies (IT) group (or some derivative thereof). The IT group can be staffed with some of the finest and brightest people in the organization. But everyone must remember, that unless you are in the IT services, tools and application development business, that is not the business that the organization as a whole is in. IT is then not directly associated with the products and services that the company positions as best in class and sell to its customers. It doesn’t develop them. It doesn’t sell them.

If IT based tools and systems are not the organization’s prime business, then investing in their custom development should never make sense. IT should then be treated as an administrative expense that is required to be spent in order for the organization to maximally leverage the available technology in the pursuit of its business goals, not a tools and systems development organization.

With this definition and positioning of IT in mind, I’ll now delve into the issues that almost every organization now faces when it comes to leveraging available technologies and how to be more efficient at it.

Over (a long) time I have had the opportunity to witness several different businesses and organizations try to utilize their product development capabilities to develop what has come to be known a “Multi-Tool Product”. This is a product that is supposed to do everything. It is designed to be all things to all customers. Instead of buying four different devices to serve four different purposes, you can buy one device to do all four.

And every time I have witnessed this type of product development attempt, I have witnessed what can best be described as failure, and worst described as abject failure.

There are two primary reasons for this type of Development failure:
1. The time and expense associated with this type of development is always, always much longer, much more complicated and much more expensive than ever budgeted or even imagined.
2. The functionality of the multi-tool product is never, ever good enough, nor delivers enough value to unseat the individual discrete products that it is competing against.

I like to tell the story of attending a multi-tool product development review some many years ago. The review was opened by the product manager stating that it had been eight weeks since our last formal review, and that unfortunately due to unforeseen development complexities, product availability had slipped twelve weeks in that time.

I commented that since it seemed that we were now falling behind faster than time was passing, that the only logical thing to do was cease development now so as to fall no further behind.

I was never invited back to another one of those product reviews.

The product however, was never completed nor released. It was quietly shelved many months, and millions of dollars later.

As to multi-tool product functionality. It may be time for another Gobeli Postulate on Product Development. It goes:

1. A product that is purported to be able to do everything, will do nothing very well.

Individually developed products are each optimized for value and performance. They are targeted at being the “best in class”. Multi-tool products by their very structures cannot match this. Each individual capability in a multi-tool product must carry the product cost and functionality overhead of every other capability in the multi-tool product.

This is equivalent to the Swiss Army Knife example. It may have a knife, screw driver, spoon and scissors, but none of those attributes are as good in comparison to a separate standalone knife, screw driver, spoon and scissors. And you must pay the added expense of the housing and overhead that is required to combine them all into one device. Invariably the four different best of breed items can be bought for less than the single, less functionally capable multi-tool product.

Okay, so what has all this got to do with IT?

Part of the average IT group’s responsibility is to create / select tools that will enhance the systems and automation of the business organization, their customers. It must be remembered that IT is a support group. They exist to provide functionality to the business.

This is contrary to some IT departments I have witnessed who appeared to believe the business existed in order to fund them.

Most internal (not out-sourced) IT tools groups think that they can create tools, capabilities and applications that are far better than what can be purchased in the market. They believe this due to their increased knowledge and proximity to their very business specific support needs. It is their focus to create tools and systems that deliver ever greater functionality and capability to an ever-greater number of people.

In short, they believe they can create better Multi-tools.

This is not always the case, but I think we can all probably remember instances where a perfectly functional and eminently usable tool was replaced in the name of “integration” by a tool that had greater integration with other systems, but lower functionality than the tool it replaced.

So here is where we get to the Title of this article: C.O.T.S. – Commercial Off The Shelf.

“Commercial off-the-shelf or commercially available off-the-shelf (COTS) satisfy the needs of the purchasing organization, without the need to commission custom-made, … solutions … Although COTS products can be used out of the box, in practice the COTS product must be configured to achieve the needs of the business and integrated to existing organizational systems.” https://en.wikipedia.org/wiki/Commercial_off-the-shelf

Please take note of the word “configured” in the above definition. It does not say “customized”. IT provided tools and systems should be configurable to handle multiple applications across different business groups. They should not be customized into different discrete tools to address each group.

There are organizations in existence whose business model is to create tools for other companies and organizations. In order for them to grow and flourish they must create best in breed tools for their specific applications. They cannot create all the tools. Only those types of tools that they are experts in.

That means that in order to get a full suite of tools to address all the business needs of the organization that the IT group serves, they will need to deal with multiple tool supplying organizations.

IT is usually a technology oriented group. External tool providing companies will usually provide tools much faster, better, cheaper and with greater functionality than anything that an internal tools group could create. However, working and negotiating with external businesses is not very technical in nature, which is somewhat out of alignment with the desired direction of most IT Tools groups.

They want to create and develop. Not negotiate and buy.

Many companies have created their competitive advantage by developing their own “better mouse trap”. This self-reliant development mentality can easily bleed over into the IT group when it comes to the tools and systems. Senior management can also be receptive to the IT tool and system development siren song, since that is how they were able to achieve success as a business.

However, management needs to remember that regardless of what they may think, or be told by IT, their business systems and tools needs are probably not so unique as to require custom tool development, but more likely just need the proper configuration of a C.O.T.S., best in breed, already available tool or system. This solution direction will invariably lead to simpler and faster implementations, as well as a lower cost of ownership and sustainment across the commercial life time of the tool.

IT will almost always be the owner of the make / buy analysis when it comes to tools. Building your own multi-tools will almost always be a slower, more expensive and lower functionality alternative to buying C.O.T.S., regardless of what the IT tool development group may want or think. Especially if your business is not the tool and system business.

When Metrics Fail

It has long been known in business that you should “Inspect what you expect”. This basically means that if you want to achieve a certain goal, or engender a specific behavior, you need to establish metrics associated with that objective. Then you need to monitor and measure the progress toward that objective.

After all, it has also been known in business that “Data is your friend”. The idea of gathering unbiased information regarding the progress toward the business goals and objectives has also been acknowledged as a path to success.

So, if you have the metrics, and you have the data, everything should be great, right?

Not so fast.

In these days of quantifiable objectives and unbiased measurements, with customer service taking an ever-higher pedestal in the pantheon of business goals, why is it that service satisfaction seems to be taking a nose dive instead of soaring to new heights?

I think the answer is simple, and it directly relates to the first item above: Inspect what you expect. Unless businesses are very careful when they set their goals and objectives, they will incite an employee behavior to manage to the metrics, instead of the business objectives. To illustrate this behavior and resulting customer satisfaction failure, I will regale you with my own personal travails though the metrics mess.

Since the advent of mobile phones, I think it is safe to say that just about every business person has had a business mobile phone. Across this mobile communications time-scape I have had the bad fortune to break exactly one of my business phones, to the point of requiring a replacement phone.

Personally, I think this is a pretty good record. I know of several of my colleagues across this period that are well into double digits on the number of phones they have broken and replaced.

In any event once broken, I then started the process of trying to get a replacement phone.

As with most organizations, there was a corporate “Help” line available to call should there be a connectivity issue. I called it. They answered right away. I asked my questions regarding where to go to start the replacement phone process. They directed me to the appropriate organizational web site.

Up to this point, this has been a really good service experience.

Time passed and I then accessed the replacement program and filled out the then required information and submitted it. I got an error message. It didn’t tell me what was wrong with my phone replacement application, only that it was wrong. I searched the rest of the page and found a help number (different from the first help number) and called.

They took my information and opened a trouble ticket, and told me they would get back to me.

Fifteen minutes later I received an email providing another URL directing me to another tool for phone replacements, and that since they could not do anything else, they had closed my trouble ticket.

Time passed and I then went to the new location, filled out another form and requested a replacement phone. Now I received a different error message, but again, no information on how to resolve the error. I again searched the rest of the page and found a help number (different from the first help number, and the second help number) and called.

They too took my information and opened a trouble ticket, and told me they would get back to me.

Another short time later I received another email providing the URL of the original Help line directing me to talk with them since they were actually in mid-conversion of the on-line business phone procurement tool and that since they could not do anything else, they had closed my trouble ticket.

As you might guess, my opinion of the quality of the service experience was eroding quickly.

Time continued to pass and I then re-called the original Help number and informed them of the circular cycle I had just been through, and again asked for their help. They said that they would look into it and then opened yet another trouble ticket.

Again as you might guess, I soon received another email confirming that there was indeed a conversion going on within the systems and that I would have to wait until it was over to order a replacement telephone, and that since they could not do anything else, they had closed my trouble ticket.

Now, I will get to the resolution of this phone replacement story in a little bit, but I am using it here to illustrate the issue that metrics can create. It was quite obvious that the metric that mattered most to the “Help” entities was how quickly they closed the trouble ticket once it was opened.

This metric mattered so much in their requirement set that it was all they focused on. I had opened multiple trouble tickets for the exact same issue, with multiple entities, some of them multiple times. They had closed every one of the tickets that I had opened quickly and efficiently.

And after all that time and effort, I still didn’t have a replacement phone. They had not solved my problem. Their metrics probably looked great. Their customer satisfaction, at least in my particular instance was close to non-existent.

Someone had obviously associated rapid closure of trouble tickets with increased customer satisfaction. In light of this correlation, they created a set of objectives and accompanying metrics around this topic. Goals were set. And associated behaviors were adjusted to this new arrangement. The tickets were indeed closed quickly.

And it was obvious that they learned that “usually” closing a trouble ticket quickly resulted in increased customer satisfaction. Closing multiple trouble tickets for the same issue quickly, but not solving the underlying issue resulted in the exact opposite. I was not anywhere close to satisfied.

By the way, I could not make this story up. This actually did happen to me some time back. It is kind of humorous in retrospect, however at the time I was not especially amused.

Getting back the resolution about how I eventually got a replacement phone, when everyone thought that they had done their job, yet there was no method for me to get a phone.

Most companies when they think they have done a good job like to issue customer surveys, just to make sure that they have done a good job. This sort of customer feedback looks good when it comes time to report on the group’s performance at the end of the year.

They sent me a customer satisfaction survey.

They asked that since all my tickets were closed so quickly if I was nearly as delighted as they thought I should be.

I told them “no”, and graded them “Zero” out of five on every metric, and submitted it. I in effect told them they stunk.

I like to think that once my survey hit their inbox with such low scores, that something akin to the “red button” was hit (along the lines of the one in the movie “Ghostbusters” – the first one, not the sequel) where the alarm rings and everyone comes running.

Within a couple of hours of sending it in, I received a call from the help group manager. He asked if he could set up a call to understand what my issues were. I agreed, but only if he brought in the other two help groups I had unsuccessfully interfaced with as well. He said he would.

Believe it or not, weeks had passed since I started the process of trying to replace my phone. What should have been a relatively simple exercise had now stretched out to the point where I was have a conference call with more than a dozen people who were trying to understand how I could be so wrong about the quality of their support services.

During the call I did agree with all of them that they had indeed closed all the trouble tickets I had opened quite promptly. I commended them for this obviously herculean effort.

I then informed them that the objective here was for me to get a new mobile phone, not to get my trouble tickets closed so quickly. I wouldn’t have minded that they were closed so quickly, if I had in fact achieved my objective, which was to get a new phone. And at this point, as of this conference call, I still didn’t have one.

There was what I could only have described as stunned silence on the call.

The actual final solution to the issue was to have the director responsible for the company phone services, who was on the call trying to understand what went wrong with the process, to personally order a phone for me. He did, and I received it two days later.

I think I should have called him directly in the first place.

Aligning goals and the accompanying metrics can be a tricky business. Leaders need to understand that just because all of the so-called metrics have been met, doesn’t necessarily mean that all is well in the business. Metrics tend to replace the actual business goals and objectives, since it is the metrics that people usually get measured against.

Understanding the metric alignment with the organizational objectives will be crucial in avoiding those instances where the metrics indicate one thing, while reality demonstrates something entirely different. It is always good to remember that having data is good, but that metrics, if not properly understood, can fail.

What is a “Plug”?

For some reason, I have been reading and thinking about forecasting for the last little while. One of the words that seems to be popping up more and more frequently in the business literature with respect to forecasting is the word “plug”. I have actually heard this word in past forecasting meetings that I have attended. I thought I might delve in a level deeper than just understanding forecasting, and look into one of the more favored words in the forecasting vernacular: “plug”.

Plug is an interesting word. The dictionary defines it as both a noun (a thing) and a verb (an action). I’ve also talked about words like this before. You used to go to a party, and now you can also go and party. I think that plug is a much earlier iteration of this particular phenomena. Usually a word is used as either a noun or a verb. I am not so sure that this is the case with the word plug when it comes to its business usage. I think that when you hear the word “plug” in business, it is both a thing and an action at the same time.

As a noun plug can usually mean either:

“an obstruction blocking a hole, pipe, etc.” or “a device for making an electrical connection, especially between an appliance and a power supply…”.

As a verb Plug can usually mean either:

“block or fill in (a hole or cavity)” or “mention (a product, event, or establishment) publicly in order to promote it.”

For now, I think I’ll ignore the appliance power cord and product promotion definitions for obvious reasons, and focus on the other two.

As the ends of various months, quarters, and years come into view, forecasting takes on a role of increased importance. Depending on the business performance, as these end of period times roll around forecasting can take on both a greater frequency and intensity, especially if the numbers are not in management’s desired range. As I have noted, forecasting is essentially the comparing of what you think the numbers are going to be with what you want the numbers to be.

I have also noted the “volumetric force” associated with forecasts. This is the management drive and desire for all forecasts to be either at or exceeding the desired targets. This desire to respond to or please management has a tendency to render forecasts possibly slightly more optimistic than what they might normally be, so that management can smile. But what do you do when the forecast obviously does not meet the desired levels?

You insert what is called a plug into the forecast.

You find a way to provide the management desired levels in the forecast numbers. You forecast the performance that is defined, and then you add in an amount equal to the difference between the goal and the defined forecast, which is undefined. This undefined amount is known as the “plug”.

You are in effect using the verb definition of the word “plug” as a noun. You are essentially filling a hole (a verb) in the forecast with a plug (a thing). It is normally the noun function that is turned into a verb, but here we have the verb function that is turned into a noun.

I guess it is a little thing (a very little thing) but it amuses me, so I have included it.

I have also noted in the past that if a forecast is knowingly presented to management, and it does not at least meet the desired targets, that whoever submits such a lacking forecast could be subject to a significant amount of incremental management attention and assistance. As I also noted this attention and assistance will usually continue until the forecast realigns with the desired targets.

The quicker the plug is inserted into the forecast; the faster management can feel better about the forecast.

I think this may somehow be related to the genesis of the saying “The beatings will continue until morale improves.” This quote is attributed to Captain Bligh, or the HMS Bounty, when told of the forecast associated with how the crew felt about reaching Pitcairn’s Island. It is also apparently quite applicable to a multitude of other management groups.

Plugs were developed in forecasts as a way to create a real and accurate forecast (that potentially does not meet management expectations), yet also provide an acknowledgement of the expectations of management in order to avoid the incremental assistance of management. Plugs are the as yet unidentified portion of a forecast, that will (hopefully) be defined in the future, and will result in the meeting of the desired targets.

This results in the equation:

Actual Forecast + Unidentified Forecast (Plug) = Presented Forecast

Plugs are an acknowledgement that the actual forecast doesn’t meet the desired levels, but the miss to forecast has been identified and is being worked, so that extra management reviews of the forecast (or beatings, as the case may be) are not going to be necessary.

On the surface, this type of forecasting technique sounds great. The actual forecast can be presented to management, as well as the desired number that management wants to see. They get both reality and what they want.

However, if you are going to use the Plug Gambit in a forecast, you need to understand that it is a double-edged sword, and it has a limited shelf life. It is a double-edged sword in that a forecast is being presented to management that is in essence telling them that their desired number is going to be achieved. If it is not, then there will be significant, and now merited management attention visited upon those that delivered such a faulty forecast.

The plug in a forecast also has a limited shelf life in that it is expected to reduce as time passes, and the measurement period draws to a close. An example is that a plug in a forecast during the first month of a three-month quarter might be acceptable. However, the same plug in the third month of a quarter should definitely garner incremental management attention.

So, there you have it. A plug is an artifice, inserted into a forecast in order to avoid (at least temporarily) unwanted incremental management attention associated with the forecast. It is an identified amount, but from an unidentified source. It can be sales to unidentified customers, or cost reduction from unidentified actions.

Once a plug has been inserted into a forecast, it is almost impossible to improve the level of the forecast. This is because as new opportunities are identified, they reduce the amount of the plug, as opposed to actually improving the forecast.

With this in mind, it is my understanding that the latest management approach to limiting the use of plugs in forecast is to in fact request and drive for improvements to any forecast that does contain a plug. This has the effect of requiring double the desired growth as the plug must first be filled before the forecast can be increased. This move by management will no doubt engender some as yet unknown, new methodology for forecasting, as the ongoing escalation associated with business forecasting continues.

This is very similar to the idea that the fastest cheetahs only caught the slowest gazelles. This natural selection meant that only the fastest gazelles (and cheetahs) survived. The ongoing evolutionary race is forecasted to continue going forward on the African Savannah.

However, I think it is pretty obvious that in this example, gazelles do not get to insert plugs into their speed forecast.

Brevity

I’ll let everyone know up front that this article is going to be somewhat brief, or at least shorter than the average article that I usually post.

It is probably no secret that while I think I may understand and appreciate the concepts and the thought that goes into creating a project and process oriented business (I have a PMP certification to this point), I also recognize that there is the potential for significant overhead and non-productive work to be attracted to this type of business structure. It is easy to say that you have got to take the good with the bad (as the beginning of the famous anonymous quote goes), but I am not so sure that is the case. Project and process structures were created in order to generate efficiencies in business. But who, if not ourselves, is responsible for making sure our projects and processes remain as efficient as possible?

This brings me to my topic: Is it just me, or more accurately, is it just my imagination or have all of business’s documents and presentations been getting longer, more detailed, more complex, and less functionally useful or justifiable?

A process at is simplest is defined as: “a series of actions or steps that are taken to achieve a particular goal”. I couldn’t make that up. It came straight out of the dictionary that way. The idea here being that it is possible to break down a complex work requirement (goal) into a series of simpler tasks and functions. This breaking down process is called “work decomposition”. I didn’t make this one up either. Although somewhat paraphrased, it comes directly from the Project Management Body of Knowledge (PMBoK) handbook.

So the idea of taking the complex and breaking it down into a series of simpler, repeatable steps is the goal of a process. This is a good thing.

So what has this got to do with the burgeoning size of documents and presentations you might ask. I think it has a lot to do with it.

As we continue to try and bring finer and finer granularity to the work requirement, we find ourselves documenting and presenting on ever more specific and smaller topics associated with the overall process and goal. Instead of presenting on sales, we now are discussing the various sales and support team engagement processes and when they come into play in the overall sales process. We don’t necessarily look at orders, but all those functions associated with the order process. Now each team will create documentation and presentations on their specific roles, when they engage and who they hand off to when they are done.

I can remember being asked to review a thirty-one-page document (not presentation, an actual Word document) regarding one of these team’s engagement process. That is correct. Thirty-One pages.

I do not begrudge anyone their function or role, but I am concerned that if it is felt that thirty-one pages are required to try and define one’s role in the greater scheme of a sales process, then it may be just possible that we have reached the point of decreasing returns on the value of the incremental process documentation investment.

The add-on effect of this process granularity can now also be seen in volume of slides and presentations that are now also being generated.

There was a time (long, long ago, in a galaxy far, far away) when overhead slides and overhead projectors were somewhat expensive and cumbersome items. This had the knock-on effect of limiting the size of presentations. Now with the proliferation of personal computers, bandwidth to connect them and the sharing of desk-tops each new image now represents only a slightly greater utilization of an ever more abundant resource. If you think you need more slides, go for it. As the great Yogi Berra once said: “The limitations are limitless”.

It now seems that fifty slide presentations are no longer the exception, but instead have become the norm.

The net here is that we seem to be producing ever greater amounts of documentation, be it written word or image / presentation based, about ever smaller and more specific topics.

It is said that work will expand to fill available time (C. Northcote Parkinson, in one of my favorite books: “Parkinson’s Law”) and that demand will expand to meet available supply. It now seems that the expansion of our ability to share information has also come with the desire and ability to share ever more of that specific information. Now it appears that the volume of what we share has increased in accordance with our ability to share it. Technology has enabled us to share more, in finer and finer detail, to the point where it seems that we may have lost our bearings as to what level of detail represents a useful or appropriate content materiality.

In the African plain faster cheetahs are able to chase down the slower gazelles. That left only the faster gazelles to reproduce the next, faster generation of gazelles. This in turn meant that the slower cheetahs were then not be able to chase them down and did not survive. That left only the still faster cheetahs to reproduce the following even faster generation of cheetahs. On and on it has been going, with both species currently topping out at speeds of approximately seventy miles an hour during the chase. There is a question as to where this evolutionary cycle will lead.

Previous generations of business structures and communication technologies seemed to have had an effect on limiting the number, topic and volume of documents and presentations created and communicated. As the speed and capacity of each succeeding generation of business structure and its communications capability has increased, so it seems has the number, topics and volume of documents and presentations that it has created.

Who can be sure what the future holds for business organizational structures. It is however expected that our ability to connect, share and communicate will continue to expand. This would lead me to the somewhat gloomy supposition and expectation that with this expanded communication capability we should expect to continue to see an expansion in the number and volume of documents and presentations created and shared to fill it.

I think that sooner or later the limitations imposed by each individual’s available time will have to kick in and start to curtail their ability to read or process this information deluge. I would hope that we would then see the pendulum start to swing back toward brevity and the informational value associated with the document or presentation, not its volume.

I have always valued the clear and concise. Fifty-page presentations and thirty-page process guides are usually neither. We seem to be in an age where we create them because we can, not because we need them. We need to get back to sharing the information we need, not all the information we have.

I told you I would be brief, or at least shorter than usual.

The Power of Information


Information is power. We
have all heard this. It enables us to make intelligent decisions. It helps us
create strategies and chart courses. It is vital to the continued well being of
any business. That is why we continue to pursue it, search for it, and mine it.
However, the real power of information is not in just having it. The power of
information is in sharing it.

 

This idea sometimes runs
counter-intuitive to what we believe. As we progress through our assignments and
our careers, we acquire more experience, more responsibility, more power and
more information. It is part of what we believe makes us valuable to the
business. It is for these reasons that some managers try to “horde” their
information. It is an effort to become indispensible.

 

Information that is horded
and not shared is the same as no information at all. If you know something and
don’t tell anyone, it is no different in the eyes of the business than if you
did not know it. The more information you give to, and share with the
organization, the more valuable you are to the organization.

 

Most of the good things that
have occurred in my career were usually the result of my bringing the knowledge
that I had acquired to a larger group, without being asked. It helped others
make better decisions and create better strategies. It helped me bring value to
the organization.