 |
| Bob The Builder by HiT Entertainment |
When my kids were growing up they loved a show called Bob The Builder. The show always focused on a challenge and sometime during the show the Bob would ask "Can we build it?" and the entire team would respond "Yes we can!"
This mentality permeates not only early morning kid's shows but apparently businesses too. I've worked with several companies that while working a massive software implementation (typically an Enterprise Resource Planning or ERP solution like Oracle or Microsoft Dynamics AX) decided to use in-house IT assets to build new code for the system and/or custom code a solution to a problem. The typical thought process goes something like this:
COO: "We want to implement (Insert ERP here) for the company, but it doesn't quite do what we need it to do. How do we get around that?"
CIO: "I'm sure we can find a solution on the market. We can't be the only company with that need."
CFO: "Ooh, that sounds expensive..."
COO: "Hey, don't you have coders in your IT Team?"
CIO: "Yes, but..."
CEO: "Perfect, we can use them to do the work. We pay them already anyway and we know it will meet our needs because these guys work for us."
CIO: "Yes BUT..."
CFO: "Perfect, they're already accounted for in the budget so it's no additional expense."
CEO: "Great, it's decided. CIO, can you get back to us with a timeline to complete the software by Friday? What's the next item on the agenda?"
Would it surprise you to learn I've sat in on several conversations very similar to this? The names and titles may change but the conversation remains the same.
The problem is that the team is answering the wrong question. The question isn't an enthusiastic "Can We Build It?" Followed by the programmed "Yes We Can!" but more "Should We Build It?" Before answering that question, there are three things to consider:
1. The initial time and cost estimates to build in-house are ALWAYS wrong!
Every time I've seen a solution approached from this angle, the initial estimates are wrong. Take whatever anybody quoted you as a time frame to complete and add 20% to it. That is the best case scenario estimate you can expect. The more realistic scenario is to double it and then add the 20%.
The reason for this is that software solutions are infinitely more complicated than people want to give them credit for, and finding a way to build a solution into an existing piece of software that the company didn't create is a nightmare. The coders you are asking to do the work will have to learn the logic, language, and table formats of the existing software package, as well as hundreds of other things in order to correctly integrate the solution into the system, and the integration never works properly the first 10+ times.
It gets worse if the project takes a long time. Then you increase the likelihood that the coders who started the project are not the same ones who finish it. On one example I had 4 different coders migrate in and out of the company before I even arrived as the Project Manager. Some of the coders were contractors, others full-time employees. When somebody left, almost all the work they did was either deeply investigated or scrapped because the person taking over couldn't tell what was going on and why the previous coder made the changes. And of course, no documentation was kept.
Sadly, this isn't the exception but more likely the rule. So before you even start, double your estimate then add a 20% contingency and you might be in the ballpark.
2. You will not be the first one to experience the problem, so there is probably a COTS (Commercial Off The Shelf) solution made for your platform.
Before dismissing out of hand a solution from the marketplace consider that most problems are not unique to a single company (no matter how much you want to believe it). That means that there are probably not just one solution on the market but multiple solutions designed to solve your problem on the platform you selected.
If you go through an RFP (Request for Proposal) process with these vendors you should be able to find multiple companies that will work with your team to define the requirements and provide a solution for you to use (perhaps even customized!). I would recommend finding someone who is partnered or authorized by the parent software company. This doesn't take the IT department off the hook because typically they are the ones evaluating the feasibility of the solution as well as consolidating the requirements from the business for the RFP.
In the end, when done right, you have a solution for your problem and (with the right contract) a partner that should help you implement the solution. In the above example, between myself and a very talented Functional Lead (mostly the Functional Lead) we managed to convince the company to scrap 4 years worth of IT development (that was slated to take only 6 months) on a solution that didn't integrate properly at Phase 1 Go-Live for a package from a lead supplier who partnered with the ERP provider. The supplier not only supplied a ready-made solution but helped us customize it with our company's branding and marketing material and worked with the implementation team to have it up and running in 4 months. Afterwards, the contract was worded such that they were partnered with our implementation for another 2 years in case of changes in requirements or system updates. Which brings us to number 3!
3. Who is responsible when the system updates?
Software today is not stagnant. It is not "set and forget." Everything is connected and interconnected and software suppliers push out updates and patches regularly (if not consistently). This can be a massive problem for companies. For an ERP system, it is a good idea (actually I would call it a necessity) to have a test environment where the updates are migrated to first then (hopefully automated) end-to-end testing is run in that environment before an update is moved to Production.
What happens when the update causes a problem? If you bought a system/solution (COTS) then the provider of the software is responsible for making sure the upgrade doesn't break your add-on (contract dependent). If you are working with a company that is partnered or authorized with the software parent company then it is possible, even likely, that your supplier received an early version of the patch and already adjusted their solution to compensate for any code changes. You could potentially receive both updates at the same time and you limit the problems for your team and possibly the company because everything still works well together.
But what about if you built it in-house? Your coders now need to scrutinize the update for what changed, digging into the details and possibly testing different scenarios one by one until finding the change that impacted your add-on. Believe me, some of those changes can be subtle or in areas that aren't even related to the created solution (at least upon first, second, and even third look) and will still impact your system!
 |
| From Pixabay |
Then the team will need to go back through their own code and rewrite portions of it to compensate for the change. This all happens after the update is released by the parent company, meaning that your system may be missing a critical update for an extended period of time as a solution is found for what broke your custom, in-house add-on.
What to do?
My recommendation is to look for solutions in the marketplace first, before assuming your in-house coders can do the job. They most likely can do the job, but I direct you back to numbers 1 and 3. At the begining you may think you are saving money but by the end you've created a world of headaches for your IT team and your company. And this gets worse the more you customize the system!
Is there an exception?
There are always exceptions. If you are a software company and can build a solution that you want to take to market may be one reason to pursue an update in-house. I know many implementation firms who have crafted solutions used as unique selling propositions to sway companies to use their teams rather than a competitor.
Another exception would be if your entire system was created in-house in the first place. This means you control the updates and you probably have the experience in-house because your team was the ones who crafted the original solution. This answer is one of the less likely ones today because most companies are moving to marketplace solutions that are considered faster, more complete, and often as a status symbol that the company is moving to bigger and better things.
Will I always recommend a COTS solution?
No, not every time. But the vast majority of the time I will. COTS will typically be up quicker, cost less (in the long run) and provide fewer headaches to the company when updates are pushed through the system. Take the time to fully flush out your priorities and requirements, work through a full RFP process, and quote from multiple vendors and you may be surprised at the efficiency and effectiveness of the solution the marketplace can provide!
No comments:
Post a Comment