Category Archives: Implementation

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.

Taking a Step Back

Normally in business when we mention the phrase “taking a step back” people immediately think of accepting a position or assignment with a perceived lower title or lower set of responsibilities. That may well be the case, but that is not the step back that I want to discuss here.

In business we all have our areas of responsibility. These normally come in the form of job descriptions and objectives. Simply put these are the things we do and the targets we are supposed to achieve. We are provided directives and incentives associated with them. We are incited to focus only on our specific pieces and parts of the business. With all that focus it is very easy to become somewhat myopic with respect to the overall business or organizational picture.

Sometimes all of us need to take time out of our ever more hectic days, take a step back and look at the overall business picture and what our specific part or role in it is, to see if what we are doing or have done is still fully aligned with the greater good.

As an ever more refined and specific business process is viewed as the clear path to greater efficiency and more profits, the incentive for each participant in that process is the ever refine and narrow their focus to their specific role in that process. As this structure evolves, organizations end up trying to create integrated end to end customer solutions out of ever more discrete and individualized work components. As the number of hand-offs in the process increases, the disconnection between the solution components increases as well.

In the extreme you can end up with a number of disconnected groups performing discrete unrelated activities (all while following a “process”) that results in a final work product that may not meet any of the requirements that were initially assigned to it. Everyone may have done everything that they were responsible for doing, but the final result doesn’t meet the need.

I think that much of today’s process orientation has originated in the Project Management discipline. (I have gone through the Project Management Institute PMP (Project Management Professional) training and certification process and do have a PMP accreditation.)

Part of the process of managing a project is to create what is called a Work Breakdown Structure (WBS). Creating a WBS is the process of subdividing project deliverables and project work into smaller, more manageable components (A Guide to the Project Management Body of Knowledge (PMBOK Guide) 4th Ed., pg. 103). It is described as the decomposition of the work to be executed by the project team to accomplish the project objectives.

But isn’t that essentially what every process is? Isn’t every process a series of work components that at the end of the process are supposed to deliver a finished work product or solution?

So enough of the esoteric discussion of the similarities of projects and processes. Where does this all get us and what does it have to do with the position I have put forth about taking a step back?

In a project there is a project manager. That person is vested with the responsibility of managing that project from end to end. As Harry Truman would say: “The buck stops there”. It is the project manager’s responsibility to make sure that all work components are aligned and additive in the direction required to complete the project.

In today’s organizations where parts are globalized, parts are regionalized and other parts are verticalized, all in the name of greater efficiency, it is almost impossible for someone to call themselves the “owner” of a process that spans multiple organizational structures. Organizations and people within those organizations may own pieces of the process, but there are precious few with the purview of a project manager who can review the process from end to end.

Once the process has been decomposed into its smaller work components, and those components are distributed to different organizations and groups, it seems the overall end to end view of things gets lost. Responsible parties seem to focus only on their specific work component. They perform their task and pass it along to the next responsible group.

It has been shown that when dealing with a uniform process all tolerances or margins for error are more or less normalized out. What that means is that in a uniform environment there will normally be additive and subtractive variances. Estimates will normally be either a little high or a little low, but on the average they will cancel each other out. This is the model that is used when the process is created.

When the process is decomposed into its component functions and then distributed into different and somewhat unrelated organizations, it can no longer be looked upon as a uniform process. It is probably more accurately defined as a “Random Variable” process. This is a process that is not uniform and where the variation in one group performing a work component has no effect on the performance of another group performing a different work component.

Okay, so what does this mean?

What is means is that when a process is no longer uniform the variances associated with the various work components no longer have the tendency to cancel each other out. They have a tendency to add together to create ever larger variances.

The net result is the creation of a process that by its very nature will not deliver a desired solution. Each group that is responsible for a work component can and will provide an acceptable output, but the sum of these outputs will invariably not be an acceptable solution.

A good example of this phenomenon can be seen in the creation of cost structures. In a project that is controlled by a single project manager, some costs will be estimated high, and some will be estimated low, but on the whole the costs will balance out. In a cost process where there is no single owner and multiple groups and disciplines involved, all costs will be estimated high (in an effort to make sure that all individual contingencies are covered) with the final cost estimate being unacceptable to the customer.

As I noted, in a project environment the project manager has oversight and control of the costs and processes associated with the project. Costs and activities must all fit within the overall envelop associated with the project and the project’s profitability. Variances within any specific group are then viewed from the point of the overall project. This ownership and oversight does not usually exist within the decomposed process. It is due to this comparative lack of oversight that a uniform process can devolve into a random variable process over time.

It is due to this sort of inertial force associated with process decomposition that we all need to periodically (read “frequently”) take a step back and review our roles and deliverables. In a greater scheme of things all that we do can be viewed as part of the ongoing business process. There are pieces that we can control and pieces that we must rely on others for. We need to make sure that we are in fact maintaining our alignment with the overall organizational goals and not just maximizing our specific work products.

It may sound a little counter intuitive. The idea should be that if we all maximize our work products, then the final deliverable should be maximized. In theory it should work. However when the goal is to minimize, or reduce or drive greater efficiency, sometimes maximizing does not work as well or drive the desired solution.

Take a step back and think about it.

From Anything to Something Specific

I really tried to take a break from putting out anything this week. The problem was that the closer I got to the end of the week the guiltier I began to feel at not writing anything. I tried to convince myself that my public would be disappointed at missing their weekly fix of my views on business and sales, and indeed I actually did get a question from a reader as to where was my post. However, the truth be told, it seems I am a creature of habit, and I am in the habit of providing my views on things, regardless of whether they are appreciated, or even requested, or not.

Oh well.

It was interesting that I wrote about golf last week, and then Tiger Woods announced his return from injury to play in this week’s tournament. This is a little bit interesting on several levels. First it is always interesting to have Tiger Woods in the field at a golf tournament. Love him or hate him he does draw interest. For me it’s a little bit more than that. Tiger Woods has always had a game plan whenever and wherever he plays. His preparation is the stuff of legend. In essence he plans his work and then works his plan. And he seems to do it better than just about anyone else. He has set the standard, whether it is on his recoveries or in standard execution.

Except this time. He acknowledged that he was not in optimal playing condition and has not prepared and practiced as he has before on previous recoveries, and that he was going to “play himself into shape”.

Many attribute this decision to the proximity of the next major golf tournament and Tiger’s pursuit of the record for the most major wins in a career. If this is truly the case then his latest move in returning to golf in a relatively unprepared state has a certain air of desperation around it and desperation in any endeavor, be it golf or business, is a cause for some amount of speculation and concern.

The same type of speculation and concern applies for businesses that are attempting a comeback from issues of their own. Businesses very seldom find themselves in any sort of difficulty as the result of a single event. Tiger hurt his back and had surgery. I am hard pressed to mention a similar type of singular event where as the result of it a business finds its ability to perform to be fully in question. Businesses don’t hurt their backs and have surgery which then require them to execute an immediate comeback plan.

The more usual reason that businesses find themselves in trouble is due to an inattention to the fundamentals of the business or the trends in the market. These types of issues tend to compound themselves over time and culminate with a “sudden” realization that there is a problem. With the realization that there is an issue comes the first reaction to desperately seek a quick solution.

I think it is fair to say that since most business issues did not result from an abrupt sort of event, quick solutions to the problem are not going to be easily implemented or particularly successful in resolving the issue. But that doesn’t seem to stop many businesses from at least trying them.

The two quickest solutions to business issues normally boil down to two simple approaches: Sell more, and Cut costs. Sometimes both solutions are attempted at the same time. Surprisingly enough, I think that these are probably the correct approaches, but that trying to apply them too quickly may only make the problems worse.

Just as many people are concerned that Tiger Woods’ trying to make a comeback from surgery so quickly might cause further injury to his back, making things worse.

There is an old saying in business: “You cannot cut your way to prosperity”. I think this is true. You may have to cut your way to survival, but you can’t cut your way to growth. With that in mind I am going to focus more on the “Sell more” aspect of businesses’ desperate responses to issues.

Too many times a business that finds itself in a recovery mode institutes a “Sell more” sales drive in order to drive incremental revenue, and hopefully incremental margin from it. Unfortunately under these types of circumstances “sell more” many times gets translated into “sell anything”. This usually results in the acquisition of many sales opportunities that do not adequately fit the proper deal profile for the business.

A proper deal profile for a business includes consistent, attainable deliverables; repeatable business products and functions that do not drain or strain business resources, pricing that enables contributory margins and profitability, and contract conditions that do not present onerous hurdles to the success of the engagement. These are the specifics associated with a healthy approach to sales.

Too often a business can get too anxious to rapidly try and recover from an issue that occurred over time. This can result in the “sell anything” approach to business in an attempt to generate revenue to help turn things around. All too often this approach results in lower margin deals and one-off opportunities that in the end not only do not add to efficiencies, but actually detract from them in the longer run. The sell anything approach is a scatter-shot pursuit of a specific solution, and as with most scatter-shot applications it results in far more “misses” than hits.

When a business is in any sort of difficulty, or is experiencing issues, incrementing in a number (large or small) of sales misses to the solution mix does not help. It only detracts from the situation, both in the resources spent ineffectively and the resulting number of sales deals that do not generate the desired or expected returns.

If it is deemed that the issue is sales or market related, and that a new sales direction or approach is required as part of the overall business recover solution, then a specific strategy and approach to new sales is called for. This will help minimize the number of extraneous or non-contributory deals that will be added to the business mix. When there are business issues, everything must be aligned and additive to the business solution. This includes the types and values of the sales opportunities that are pursued.

A business cannot allow the “Sell More” solution to become the “Sell Anything” solution. It will only  prolong the business’s recovery, or potentially even make things worse.

Will Rogers is quoted as saying “When in a hole, stop digging.” We also have the much older and unattributed quote “Don’t just stand there. Do something.” In business it would seem that the equivalent of the first quote might be “When in a hole, start selling”, with the equivalent rejoinder to the second being “Don’t just sell. Sell something specific.”

The idea of focus and discipline never goes out of style in business, even when times are tough, or recoveries are being attempted. Maintaining a focus on selling something specific and resisting the temptation of selling anything available will result in a better solution and stronger business over the longer run, and that is the focus that business needs to maintain.

Tiger Woods is a unique talent. We shall see if the departure from his proven successful preparation process pays off in his recovery attempt. It might pay off for him, but he did miss the cut in his first tournament back, and that is news in and of itself, since he so rarely fails to make the cut. Most of the time it does not pay off for a business to try for a quick recovery that departs from their specific processes either.

Drivers Wanted

An opportunity is recognized in the market place. An issue has occurred in supporting a customer. An idea has generated a new product or solution. What do we do now?

 

It seems more often than not we call a meeting. Then we call another meeting to make sure that we understood what we heard. Then we call a meeting to plan our next steps. Then we start the process of looking for “Buy In” from everyone else. Pretty soon the focus on what could have been a “game changer” has been swallowed up by the safety and security of the process.

 

There is a difference between “Driving” the process and “Working” the process. Driving is when as a leader you have the conviction that what you are doing is right. You have looked at the issue, worked with the team and have made the commitment to move. There is a process in place for situations like this but it generates its own resistance and impedance. When you are driving you will take input but you will not accept delay.

 

Businesses today seem to be more content to work the process. This is a situation where we seem to be more content to accept delay and modification to the decision or solution. While the conviction may still be strong, the risk of being wrong seems to outweigh the benefits of being right. We allow the delays and changes in order to get a “Consensus” as to what should be done. This consensus enables the risk associated with the action to be mitigated across all those that participate. The idea seems to be that if it succeeds everyone can take a bow, but if it does not, no one individual will take a fall.

 

There is value to getting buy-in. It helps the team internalize an external goal. The problems with consensus are that it can take a while to achieve, can water down the solution, and requires everyone to say “yes” and can be stopped when anyone says “no”.

 

Great leaders know how to drive the process, while they work it. They set the goal, provide the resources and do not allow any reasons or excuses. A key here is making sure that the resources are made available. President John F. Kennedy set the goal of sending a man to the moon and back, and drove NASA to do it. He also made sure that NASA had the people and money to accomplish the task.

 

He drove the process (he made sure the goal, objective and measurement were known – get a man to the moon and back before 1970) and he worked the process (he made sure that the funding was provided and the responsibilities were clear), and it worked. If it had failed NASA may have taken some of the blame, but by and large it would have been Kennedy’s failure.

 

I don’t know if it is a reflection of the times, be they economic, political, or other, but we seem to have lost this “Driver” type attitude in doing business. I think we need to get back to it if we want to see the types of growth and performance that are wanted and needed to move forward. Its at times like this that I think of that car commercial – the one with the catch phase “Drivers Wanted”.