Author’s note: I’m not sure if this should be a longer or shorter “post” (“article”?) because the core intent could either be stated as briefly as a tweet or as long as a book. I’m sure there could be a full semester college course on this subject, but I’m not that good. I’m throwing a dart at the best guess board to see how it works in the end. This article emphasizes intranet portal projects, but it applies to anything that incurs a choice between buying versus building your own. I hope it helps (or at least entertains) – Enjoy!
One of my main interests, and sources of work, is herding cats. Actually it’s information aggregation, or process automation. Most often this boils down to using the “web” as the hub or focal point for tying it all together. Intranets are my biggest customer. The discussion usually circles around concerns over costs and time when choosing between a retail or “COTS” solution versus a “custom” developed solution. It usually starts with a short discussion that goes like this:
Customer: “We really need to pull our information together and link things up. We have separate databases for HR, work scheduling, customer lists, project status, Active Directory and security roles, financial projections, contract bid data mining, compensation modeling, and so on. We’d like to connect all those things as well as add some sort of employee “self-service” features. Should we buy something like SharePoint or have you build it for us from scratch?”
Me: “It depends” (don’t you LOVE that classic consultant responses!)
Seriously though, it really does depend. I have a matrix of criteria to help evaluate which is the “way to go” towards arriving at the desired result. But first, the cheesy diagram below illustrates that no matter which “way you go” you’re likely going to incur time and cost with making it “fit” into your environment, and “fit” in between what you currently have and you wish to have. The question is then which direction incurs the least burden.
So, just what exactly is this “matrix of criteria”?
| Criteria | COTS | Custom |
| Budget “hard limit” | ? | ? |
| In-House Talent (developers, admins) | ? | ? |
| Features Gap | ? | ? |
| Interfaces | ? | ? |
Pretty simple, right? Well, not really. Each of these criteria potentially involves a ton of digression and drilling down. How much so depends upon the scale of the business, the scope and scale of the “things” being integrated, and tangible and intangible constraints.
Whoa! (record scratch sound here…) - Did you just say “tangible and INtangible constraints”?! WTF?
Tangible constraints are pretty familiar to us all: budgets, time, staffing, physical and logical space, and so on. Intangible constraints are usually human-based: emotional aspects, protectiveness, skill levels and expertise, and secondary distractions like, oh, for example: Joe is on the team to discuss this whole project. But Joe manages the HR database systems. He was forced to sit on this team by his boss, whom he doesn’t like, but who insists that it might be time to consider moving the HR system into something more accessible and flexible for interfacing with other systems. Joe sees this as a threat to his control, and thereby a threat to his existence and job security.
Yeah. Something like that.
If you’ve ever sat in a planning meeting that involved discussion about changing something major, or something that’s been relied upon for years and years, you absolutely KNOW what I’m talking about. It’s more prevalent in larger corporate environments than within small businesses, but it can show its ugly head anywhere really. I will go ahead and say this, even if it causes some of you to shake your head in disagreement:
The single biggest obstacle, and cost inflation factor, in any technology-oriented project is human emotion.
Yep. If we just acted like logical robots and implemented technology without pausing to argue over rationale and subjective value, we could get those tasks done in less than half the time it typically requires.
But let’s get back to the focus of this post, which is how to rationalize a “buy versus build” decision, primarily with respect to intranet portal projects…
You’re probably thinking that I usually knee-jerk to making a “build it” recommendation. You would be correct. But if you assume that my decision scoring is something like 10:1, you’d be very wrong. My average is roughly 60:40. That’s not because I’m trying to capture new work and income, no. It’s because it just happens to be a function of the nature of the evaluation of criteria within the clients environments I deal with most often.
Some of the typical factors that lead me to recommend a COTS solution however are (or should be) pretty obvious:
- Do they already have complimentary systems in place that would make it easier to add the propose intranet solution? For example, all data is currently in a single (or clustered) database, or other information management systems by the same vendor have been in place for a long time. It’s usually best to add a matching brick to an existing wall, than to tear down the wall to change the brick color.
- Do they have existing development and admin talent to match the proposed solution? Do they have .NET and SQL developers, or do they have Oracle and PHP developers? Will they be available for this project full-time or part-time?
- Is the customer list of desired features an exact match with out-of-box features of the product? Is it “close”? How close? How many of the desired features are typically the most difficult to develop from scratch, but which are already provided by the proposed COTS product?
- Are there existing instances of the proposed product in use elsewhere in the company?
When these factors evaluate in one direction, I usually recommend going with the COTS solution and then work to help them plan for, and implement it in the test and production environments. SharePoint, Drupal, Joomla, etc. are all good products and very much tested and proven in their own rite.
But when evaluation of the criteria leans the other way, it then opens up another discussion and round of evaluation to vett (God, I hate the word “vett”! But I have to use it here because I have a gun to my head) the issues related to custom development:
- Time and Budget constraints
- Degree of Access to interface resources (cooperation)
- Variety of interface technologies (spread)
- Hand-off Issues
Most of these should be easy to understand, but I’m going to dig a little deeper into them anyway (why not?).
Cooperation is huge. If the team, or the delegated staff you’re going to be working with, are going to open up and provide access and information to help you interface with their systems and data stores, great. That makes life so much better. But when they circle the wagons to protect their turf, or simply don’t put forth any real effort to keep the ball moving, then it becomes a huge detriment. This falls into a semi-intangible aspect of the project scoping and assessment. Ultimately this boils down to TRUST. You have to trust them and they have to trust you. You can’t scope or predict anything that’s human-oriented without familiarity and that is based on trust.
Variety of technologies, or “spread”, represents more of a metric nature. If all of the data stores share a common technology, like Windows or Linux servers, MS SQL Server, Oracle, or XML structure, or whatever, then it helps you narrow your ingredients for baking the solution. If there are a dozen systems you need to tie into which each does their own platform, vendor and technology dance, you’re going to have a tougher time herding the cats. Even if all of those systems support an XML-based interface, there’s going to be additional work with planning, testing, and validating each custom interface, separate from building the actual end state.
Hand-off issues involve how the solution will be managed and maintained going forward. You know: after you complete the delivery. Make sure this is spelled out! So many times I’ve walked into a project proposal meeting and this is never mentioned. Who is going to keep this machine running after you deliver it? You? Them? A mix of both you and them? If it’s a mix, that’s the most important to spell out in terms of what, when and why. If they expect YOU to keep it running, what is your backup plan? Are you the only person? That’s great if you only care about a paycheck. It’s extremely bad for the customer if you drop dead or have surgery, as well as bad for you for instilling TRUST in the eyes of your clients. I always try to shift the role to them and offer as much knowledge transfer as possible. This is the only possible and practical “win-win” situation.
Conclusion
If you were expecting me to stand up and shout “always do this!” or “always do that!”, I’m sorry to let you down. But this falls into my firm belief that most knee-jerk recommendations are bullshit. There is no “one size fits all” in the business world. Because (and this repeats another mantra of mine): a business is a name for a group of people. People are not stamped from a machine. People vary. Business varies. Problems vary. Solutions vary. Be adaptable and listen. Take notes and analyze them before proposing a solution or recommendation. Don’t be in a rush to give an answer in the same meeting where the questions were asked. No worthy business will hate you for saying you’ll get back to them after reviewing the facts and factors.
No comments:
Post a Comment