Beginning an RFP process driven purely by business requirements is like being in the market for a new car knowing no more about what you are looking for beyond “I want a new car”. You could be car-shopping for a very long time and be deeply disillusioned by your purchase when you do end up making it (if ever)
Doing functional requirements is like specifying the features you want in this imaginary car. It will pare down the list of options some but chances are most automakers provide the same set of standard equipment give or take a few in the same price range. So you are down from 10,000 to about a 100 possible options.
It’s still too large a pool to make an intelligent and timely purchase decision. Analogously, you float the RFP out with "implementation agnostic" business requirements, get a bunch of bids with every vendor claiming to be the very silver bullet your organization seeks. You spend hours stacking them every which way to make sense of what you are dealing with, do feature to feature compares, cost to feature ratios and other equally mind numbing exercises but come no closer to conclusion.
You bring them (product vendors) in to test drive what they have to offer. While the pres-sales techs are busy pulping your brains with information overload, the smooth talking sales types are schmoozing with your business partner who by the way will be writing the check. So bang in the middle of this product/vendor evaluation hell, your customer walks over and solemnizes a shotgun wedding that hooks the screaming and protesting IT crew up with a vendor they(the business) think is the best fit for their needs.
It would be too simplistic to blame the business for doing what they so routinely do. Needless to say these coerced unions are generally expensive and very short-lived. Soon we are all back shopping for “a new car”. If only people would bring their car shopping lessons to bear upon the technology business. Back in the Web –3.0 days it behooved the geeks to keep the innards the technology under wraps from the business customers and get to understand what they wanted done. It was just not realistic to bring them up to speed on such arcana as the best CORBA implementation in the market.
Once their need was known (like it is even possible) the IT team would retire to the dungeons, scheme and plot with uber-geek types who never meet the customer because there was not a language that both sides understood. At the end of all this IT would come up with a summary of implementation options. It was a long drawn out and painful process.
Business grew impatient (and who can blame them), changed their minds many times over and finally there was the aforementioned shotgun wedding. This is an antiquated engagement model that is completely unsuited for today's world. We live in the time of Web 2.0 where it is finally possible to let the non-geeks drive the bus to wherever it is they want to go.
The role of IT can be limited to making the ride comfortable and carry them over the speed bumps smoothly. To extend the car shopping analogy, get them excited about the possibilities that exist out there, be the subject matter expert who can weigh in authoritatively on why a Volvo may meet their needs better than a BMW, be their concierge but don’t tell them you will come back in a couple of months to let them know where they could go shop and charge them several hundred grand in consulting hours to do so. That is an insult to their intelligence.
Unfortunately this is just the kind of behavior I have seen repeated in most of my consulting engagements. I get all fired up about this marketing director who is very tech-savvy and can articulate his needs to the point where in the car shopping analogy he has said described the Mazda Miata he wants in the level of detail of an used car ad. It makes my job really simple and I love that. Now that I know my customer I could present an option that is just as compelling only far more scalable for a little bit extra. It could be an easy sell and the geeks would be chortling in glee at the opportunity to cut their teeth on sexy technology.
A win-win you might think but not really. My management does not share my enthusiasm for this technology-aware business partner. They impress upon me the importance of clear delineation of roles and responsibilities. "They" (the business) are in the problem space and all they need to do is define it. "We" (IT) are in the solution space and must figure out what will work best for them.
The way I look at it, the more responsibilities are shared without undermining final accountability the better it is for everyone immediately involved as well as the organization. One plus that comes to mind right away is you no longer have visions of being skewered like kebab when you see an invite to a "Stakeholder Review" in your inbox.
You(IT) and your business customer play different roles at different times of the project cycle with the common goal of getting to a stable, scalable cost effective solution. Not that I am a big fan of Microsoft, but I can’t wait for Popfly like products to invade every domain of enterprise technology – this has been long overdue. It's about time we let the owner drive their own car instead of being chauffeured to where they never asked to go in the first place.
Doing functional requirements is like specifying the features you want in this imaginary car. It will pare down the list of options some but chances are most automakers provide the same set of standard equipment give or take a few in the same price range. So you are down from 10,000 to about a 100 possible options.
It’s still too large a pool to make an intelligent and timely purchase decision. Analogously, you float the RFP out with "implementation agnostic" business requirements, get a bunch of bids with every vendor claiming to be the very silver bullet your organization seeks. You spend hours stacking them every which way to make sense of what you are dealing with, do feature to feature compares, cost to feature ratios and other equally mind numbing exercises but come no closer to conclusion.
You bring them (product vendors) in to test drive what they have to offer. While the pres-sales techs are busy pulping your brains with information overload, the smooth talking sales types are schmoozing with your business partner who by the way will be writing the check. So bang in the middle of this product/vendor evaluation hell, your customer walks over and solemnizes a shotgun wedding that hooks the screaming and protesting IT crew up with a vendor they(the business) think is the best fit for their needs.
It would be too simplistic to blame the business for doing what they so routinely do. Needless to say these coerced unions are generally expensive and very short-lived. Soon we are all back shopping for “a new car”. If only people would bring their car shopping lessons to bear upon the technology business. Back in the Web –3.0 days it behooved the geeks to keep the innards the technology under wraps from the business customers and get to understand what they wanted done. It was just not realistic to bring them up to speed on such arcana as the best CORBA implementation in the market.
Once their need was known (like it is even possible) the IT team would retire to the dungeons, scheme and plot with uber-geek types who never meet the customer because there was not a language that both sides understood. At the end of all this IT would come up with a summary of implementation options. It was a long drawn out and painful process.
Business grew impatient (and who can blame them), changed their minds many times over and finally there was the aforementioned shotgun wedding. This is an antiquated engagement model that is completely unsuited for today's world. We live in the time of Web 2.0 where it is finally possible to let the non-geeks drive the bus to wherever it is they want to go.
The role of IT can be limited to making the ride comfortable and carry them over the speed bumps smoothly. To extend the car shopping analogy, get them excited about the possibilities that exist out there, be the subject matter expert who can weigh in authoritatively on why a Volvo may meet their needs better than a BMW, be their concierge but don’t tell them you will come back in a couple of months to let them know where they could go shop and charge them several hundred grand in consulting hours to do so. That is an insult to their intelligence.
Unfortunately this is just the kind of behavior I have seen repeated in most of my consulting engagements. I get all fired up about this marketing director who is very tech-savvy and can articulate his needs to the point where in the car shopping analogy he has said described the Mazda Miata he wants in the level of detail of an used car ad. It makes my job really simple and I love that. Now that I know my customer I could present an option that is just as compelling only far more scalable for a little bit extra. It could be an easy sell and the geeks would be chortling in glee at the opportunity to cut their teeth on sexy technology.
A win-win you might think but not really. My management does not share my enthusiasm for this technology-aware business partner. They impress upon me the importance of clear delineation of roles and responsibilities. "They" (the business) are in the problem space and all they need to do is define it. "We" (IT) are in the solution space and must figure out what will work best for them.
The way I look at it, the more responsibilities are shared without undermining final accountability the better it is for everyone immediately involved as well as the organization. One plus that comes to mind right away is you no longer have visions of being skewered like kebab when you see an invite to a "Stakeholder Review" in your inbox.
You(IT) and your business customer play different roles at different times of the project cycle with the common goal of getting to a stable, scalable cost effective solution. Not that I am a big fan of Microsoft, but I can’t wait for Popfly like products to invade every domain of enterprise technology – this has been long overdue. It's about time we let the owner drive their own car instead of being chauffeured to where they never asked to go in the first place.
Comments