www.itminddesign.com

Background

Last year, in collaboration with my leader and teammates, we set out on a mission to replace some existing end of life equipment while adding capacity and taking advantage of the progression in technologies. So after some due diligence and data gathering of the current state in the environments, we documented the current state and poured out our requirements in what can only be described as an RFP - RFI combo document using the terms as defined in the Reference Terms page. The birthing of this document was arduous and focus on accuracy and unbiased toward any specific vendor or technologies. We documented the characteristics such as:

Availability

Scalability

Flexibility

Maintainability

Recoverability

Adaptability

Agility

Effectiveness

Simplification

Tuneability

Cost Reductions

Strategic alignment with business processes and standards

Value add

Supportability

Prioritization

Securable

We gave guidance as to what categories/areas of information (including the minimal amount of data deemed acceptable) would need to be provided about the proposed solutions. Evaluation criteria was indicated. However, in retrospect, we did not provide which areas where more of a priority than others and what weight was given to the evaluation criteria - not to say that information is needed, expected, any of the respondent’s business, or commonly provided the vendors.

Vendors - OEMs v. VAR

The request was sent to both OEMs vendors and VARs. We were accepting of a total solution from one OEM, but a multi-vendor solution was more likely. Very few vendors have the top-notch equipment in all the technology spaces we covered in the request. Either way, would be satisfied if the solution was a fit for the company’s needs. We have relationships with multiple VARs and I believe they provide value in “the gap” between vendor and customer. In this specific instance, there were so many common OEMs that received the request than many of them contacted the VARs to be “partners” in responding to this request that the VARs became indifferent and didn’t want to “choose sides” in responding. So, if your keeping score at home, that’s 0 VARs to respond. Our familiar and trusty weapon to deploy proper multi-vendor solutions has been inept and removed from this equation.

Follow-ups and Responses

We had the standard follow questions; conference calls and meetings. Then weeks later, those who had chosen to respond, began to respond. Meeting mania occurred, vendor after vendor. Documents, CDROMs, Power Points, websites, business cards, and killing trees while burning up the printers. (Sidebar: I wonder how many carbon credits it would take to replace the paper used for all the printouts of all the versions of these documents). After we wiped up the blood that had oozed out from our ears we began the data absorption. Continuing to cull through the minutiae and finding viable candidates.

The proposed solutions

I have to say that the responses were wide. Some vendors inculcated the requirements and the current state of things. However, some did not. I almost think that some of these guys just did not read and listen. Not to question their competence, as being an elder statesman I would not do such a thing, but I expect more from them. Sure I knew that 99.9% of them were going to have a total solution to provide with their logos on every piece. Some of the solution being their equipment and some were rebranded from other companies. The individual creators of each solution should be leveraging their vast knowledge and experience with so many customers in how they ascertain the best solution for our company. However, with the majority of the respondents, we got mostly marketing and very little substance. The kicker was, all of the solutions had some validity, what they couldn’t articulate was how the information we provided plus their industry knowledge and experience lead them to this solution. So I don’t know what factors they did include, did they see the potential dollar signs and get tunnel vision? Was it multiple teams working on this response, and the team that made the technical decisions wasn’t the same as the pre-sales folks who comes to present the response? If this is common for most vendors responses, how are these company’s making money? I’m sure the margin for reselling for a VAR isn’t enough to retire on, so it’s not the hardware/software sales brining in the dough. Professional services is what makes a VAR big money and from my experiences with some quality VARs, they are worth it.

Lessons Learned

• I think the next request we do, we should start with the VARs first and get through them before we engage the OEMs directly. Doing this might keep the VARs in play and not force them into an awkward position.

• Allow for more time for discovery and communication of data and requirements to VARs and vendors. As will all impending needs, we usually don’t get to them until they are really needed and some shortcuts have to made in the interests of time and money.

• Keep up contact and meaningful conversations with quality vendors. They seem to do better when they understand more of how the customer’s company works and what’s generally going on with all involved. I know personally that time is always at a premium and investing it in vendors when you don’t really need something is hard. These lower priority items always fall to the wayside.

• Stay connected with the quality sales people and engineers. Even if they change vendors or jobs, with all the business social networking sites (LinkedIn, Plaxo, etc) it should be somewhat easy to keep in touch. Good salespeople and engineers are hard to find and even harder to keep around, so the investment is worth it.

Dave Hitz, who is the founder and EVP of NetApp, imparted some interesting information in one of his blog posts. This specific post breaks out some functional differences in roles in different size companies for CIOs and CTOs which was an enlightening experience for me. What Dave did impart that I most found of value where the five stages of technology adoption.  Dave went on to further describe these stages as monitor, evaluate, standardize, proliferate, and retire.

‘I asked for details about these different stages. He described monitor as a casual awareness of a technology, maybe from reading occasional articles or white papers, and keeping an eye on it to determine when to investigate more deeply. Evaluate is when you seriously consider whether a technology is valuable enough and mature enough for you to deploy. To make a technology manageable in a large enterprise environment, you standardize on a particular set of configurations and management processes. At that point, you can proliferate the technology broadly, until a replacement technology is ready, at which point you retire this one.’

Though these categories do apply for CIOs and CTOs, I believe they are useful to others down the ranks. Part of the function of the group in which I am a member is to stay up with technologies and continue to drive innovations and newer technologies where they can best help the company succeed and improve the environment the people who work at the company must support. I think that if we inculcate these categories into our processes it will help define a ‘lifecycle of technology’ that give some meat and measurability to one of the most hard to quantify part of our job descriptions.

I wonder how other companies handle the processes of new technology. My company is fairly global and large and groans due to the weight of red tap. I am curious how others see this and how other companies, both big and small, approach this process.

I find Dave’s blog often filled with interesting views and information. Should you desire to read his blog, it can be found at blogs.netapp.com/dave.