Just the other night I was told of yet another horrid experience where a company, at the direction of the CEO, had bought a new technology (in this case Salesforce.com) and then spent a massive amount of money creating a tool the sales people couldn't use.
Not just wouldn't -- but couldn't -- because the consultants brought in to do the job never really bothered to engage sales during the design or deployment process. They then had to spend a massive amount of additional, unplanned funds to patch the result and create a solution that had at least some value.
It wasn't the product's fault. It was the complete lack of focus on the folks who would have to use this product. In the post-mortem analysis, it was found that the consulting company used a 17-year-old employee (perhaps someone's child or an intern?) to go around and ask some questions of the sales team, with the answers to be used to develop the tool. Clearly, this 17-year-old lacked both experience and context, and seems a blindingly poor choice to serve as a liaison to the end users.
Earlier this week, I participated in BMC's cloud workshop (PDF available here), which is uniquely designed to eliminate this kind of mistake. I think these workshops should be part of any major deployment and be driven by the company buying the solution. There are a lot of lessons here. BMC Cloud Workshop
BMC developed this rare offering after it recognized that the failures it was observing, both in product and in deployment, were coming from a lack of user involvement in the early phases of a project. The user engagement didn't seem to happen until the product was deployed and the users started complaining about it. This resulted in project failures and massive cost overruns, which, in turn, led to poor customer satisfaction and weak loyalty.
BMC's cloud workshop is a five-day process where the folks designing the solution and the folks who are going to use it sit down and jointly craft the overall architecture. This goes to the basic concept of measure twice and cut once. Put another way: Spend the time up front to work out what is going to be built, and only then move ahead to craft the solution.
I spent only a couple of hours in an abbreviated segment, but I feel that we probably demonstrated the mutual animosity that exists between line management and IT. But with BMC's help, we also found paths to common ground, and it is clear that working through this process before the solution is architected rather than during deployment is both far cheaper and much more likely to hit critical timelines. Secondary Benefits: Job Security
I also found through the workshop that this exercise was a great way to discover why both sides did things that annoyed the other. For instance, in this scenario, we learned why R&D was violating company policy by using Amazon for hosted resources, and why IT required audited processes.
I shared a story that I had heard some months ago about an engineering team in the pharmaceutical industry that had won an award for cost savings, only to get terminated the next day. They had initially gone to IT and been told that their project would cost more than $100,000 and take nearly a year to provision. They then took their credit cards and, using Eastern European resources, got it done in nine weeks.
Their manager submitted their project for a cost savings award and they received a hefty check for saving the company so much money. However, this award brought them to the attention of security, and when security discovered that very critical and highly valuable technology was drifting someplace unknown in Eastern Europe, they were terminated for cause.
On their records, that cause likely reads the same as if they'd sent their project to WikiLeaks, which means they likely will not be employable in any security-conscious industry ever again. In short, not only did they get fired, but their actions probably killed their careers in this industry.
In short, the secondary benefit to this sort of boot-camp-like exercise is the potential elimination of job- and career-killing mistakes by people using credit cards for outside services.
BMC allowed me to talk to an actual customer, from which I learned that this process has changed BMC significantly, as the feedback from these workshops gets translated into product as well as process. As a result, BMC is both more agile and better focused on what the end user wants in new offerings because it is talking to these users in the context of a deployment.
Unlike surveys, which can ask questions that aren't of great interest to the respondents, this process assures that BCM receives high-quality, relevant feedback, which in turn translates into higher satisfaction with its offerings.
Unlike surveys, which can ask questions in areas that the population aren't interested in or thinking about this process assures the quality of the answers BMC gets are extraordinarily high and this has been contributing both to higher satisfaction with their offerings better ideas for who to buy or what to build.
In the end, I'm kind of surprised we didn't figure this out sooner -- that in a world of social networking, creating pre-design working groups to bring together IT, the vendor and the end users would result in products that were better, faster and cheaper. Go figure.
Rob is president and principal analyst of the Enderle Group. Previously, he was the Senior Research Fellow for Forrester Research and the Giga Information Group. Prior to that he worked for IBM and held positions in Internal Audit, Competitive Analysis, Marketing, Finance, and Security. Currently, Rob writes on emerging technology, security, and Linux for a wide variety of publications and appears on national news TV shows that include CNBC, FOX, Bloomberg and NPR.
Read more about cloud computing in CIO's Cloud Computing Drilldown.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.