Objectivity in IT

ccipeggy (Pixabay)

Within IT we constantly talk about how people are supposed to bring us their problems and we will work with them to come up with solutions.  We don’t want people to come up with their own solutions and ask us to implement them, we want to know the problem, understand the problem, embrace the problem, make the problem our own and then solve it for them.

This has a lot of advantages.  Because we have an understanding of their business and other related businesses we can look at areas of re-use, we can look at areas where we can literally copy/paste code and get a leg up on development, we can look at the problem from a holistic perspective and perhaps come up with a different solution that meets the needs but gives them additional capability.

So why is it that we don’t do this ourselves.  Too often applications internal to IT are not brought to IT for a solution but are brought to IT with a solution in hand.  Instead of trusting the cumulative experience within IT we come up with a solution, regardless of whether or not it is the proper solution, and then rapidly build something with that solution in mind.  We don’t review it as we would a solution brought to us by a business client and we don’t ask for the problem so that we can determine the best way to resolve the issue, we jump to a solution that may or may not be appropriate.

We also need to understand where our biases lie and work to mitigate those biases when trying to resolve problems or evaluate solutions.  For instance, I have a bias against COTS packages that you can modify.  I’m thinking primarily of things like PeopleSoft and SAP and Oracle Financials, but it applies to other COTS packages as well.  I have experienced too often, actually, the IT industry, in general, has experienced this, that people buy a COTS package and then highly customize it.  Then another release comes out and that needs to be highly customized.  Ad nauseum in perpetuity.

When I first started in this business over thirty years ago I worked for a company that had modified their payroll system so much that it took them almost a year to make updates.   The company that produced the payroll system came out with bug fixes and updates every six months.  We were always behind.  PeopleSoft?  The same way.  Months and months of changes, sometimes extensive changes before anything could go in.  And when it did get into production?  Bug fixes that were fixed by the next release that came out six months prior but we were too busy working on the previous release.

I understand that bias.  I know about it.  I try to make sure that it doesn’t impact my assessment as to whether or not a solution is appropriate.  Sometimes COTS products are such a good fit that it would be silly to try something else.  Sometimes it is close, but the remaining twenty percent?  That’s really the meat of the application so while it looks good on paper, it is not worth it pursuing.

A number of years ago there was a bias that SharePoint was the development platform of the future.  Everything would go into SharePoint.  I mean, why not?  A data connector here, a simple form there and *bam* a new app in hours.  As we have seen, not everything that can go into SharePoint should go into SharePoint, but for SharePoint adherents SharePoint was nirvana.

Every so often a technology comes along that people become enamored with and think “Wow, this will solve all of my problems.”  It won’t, it will just cause more problems down the road.  You need to pick the right tool, the right solution, for the appropriate problem.

You don’t ask a CMS adherent if the solution to your problem is a CMS, because the answer is “Of course!”.  You don’t ask a SharePoint aficionado if the solution to your problem is a SharePoint site because the answer is “Of course!”.  You don’t ask a PeopleSoft person if your problem can be fixed by PeopleSoft because the answer is “Of course!”.  You don’t ask a CRM fan if the solution you’re looking for is built with CRM because the answer is “Of course!”.

Our job is to be objective.  Our job is to look at all solutions dispassionately and come up with the best solution given the parameters that we need to consider.  So why is it that for solutions that IT builds for itself we rarely do that?

Leave a Reply