You decided to build. A custom enterprise software solution in-house seemed like the best means of solving your technical challenges. Perhaps engineering required that your software requests be managed in-house. Or maybe you just didn’t read Part 1 or Part 2 of our series…;)
However you got there, and no matter the technical challenge you seek to resolve, the decision to build is regularly met with challenges in implementation, maintenance, upkeep, and sheer know-how. We often get a call for our services when in-house software management problems rear their ugly heads. And with my years of experience working with our customers and building software, I’ve gotten to know just as much about the challenges organizations face in building their own solutions as I know about the advantages they’ll see from buying one.
If you’re not sure if your build is headed down the right path or want to avoid the signs that indicate things might go awry, this blog is for you. Read on for the top three scenarios where, in our experience, a self-made build isn’t likely to work out.
1. The “We’re Getting to It” Build
For some organizations, planning is as far as you get in building your software solution. Your IT team seems eager and willing to develop a tool, and the organization’s leadership is enthusiastic about planning… but then, **crickets**.
Perhaps executive approvals slow down, or ultimately hold up development. Or IT’s ironclad processes require additional specifications for implementation that you don’t understand or that require a lot of back and forth between teams to deliver. Or maybe a special committee takes over and adds the task to the organization’s project plan and development cycle, but there’s little movement as the committee contemplates how to move forward.
In each of these instances, members of your organization are just trying to do their jobs well. But in the process, your solution sees little progress. In the off-chance that building does eventually commence, your requirements and resources may have completely changed after so much time has passed.
2. The “That’s Not What I Wanted” Build
For other organizations, incomplete planning, rather than overplanning, impedes the progress of building a solution. For example, your marketing team requests a software solution that can seamlessly deliver sales data reports daily, and your eager and agile IT department delivers. But when marketing realizes they need timestamps paired with the sales numbers, IT issues a revision. And when marketing decides that incorporating user data would be helpful as well, a third revision is made. In the end, not only does the solution never totally meet marketing’s satisfaction, but by revision 10, resources are exhausted, and the organization’s once responsive and flexible (and now, probably frustrated) IT team is forced to back off of the project.
3. The “Ask Jimmy” Build
Finally, let’s consider a scenario where your software solution is up and running, and it works! But, it was built by resident expert “Jimmy,” a member of your engineering team. The solution operates from one local desktop computer – it functions, but it’s fragile. Jimmy is passionate, has great vision and is in tune with organizational needs. And while it’s great to have a software solution that delivers exactly what you need – one glitch, one software update or the one off-the-grid vacation Jimmy takes could lead to its failure. Not to mention the limitations Jimmy’s solo solution poses if your organization seeks a multi-user system so others throughout the organization can be involved in the processes.
Start from the beginning of the blog series
The Build Has Gone Awry…So Now What?
Whether I’ve described your current build or you fear one of these scenarios is on the horizon, now’s the time to fully assess your options. Are improvements needed, or is it time to pull the cord? If you keep hearing “we’re getting to it,” take a look at how long it’s really been. Waiting a few months or even quarters for implementation isn’t unlikely. But if you’ve been waiting years, as is (unfortunately) often the case, it might be time to call it quits and look into other options for making your solution a reality.
If your solution is in place, but it’s fragile or you aren’t getting the deliverables you hoped for, review the processes needed to maintain it. Ensure you’re clear about your ongoing requirements and be accountable for the role you play in making the solution a reality. Incomplete planning will only put more strain on your relationship with IT, and slow down or end the process completely. Also, know how flexible and available your engineers are if any changes are needed. Do adjustments only happen in a black box that you have no access to? Has your project champion on the IT side moved on from the company, along with the related institutional knowledge of the homegrown platform? If so, consider having a conversation about open lines of communication, or discuss the option to buy software that offers you and your full organization transparency and an opportunity to access all of its intricacies.
Finally, if you know your build is broken, consider taking the opportunity to hit the reset button and buy a software solution this time around. And choose wisely. Seek a vendor that has a strong service-oriented architecture, so that you can be an active participant in how your software solution is implemented. Finding a vendor committed to understanding your current internal state and even willing to learn from the failed project can only improve and benefit your new solution. And it won’t hurt in helping internal members of the team save face and know their hard work up to this point wasn’t wasted, either.
At Minitab, we’ve had great success with software implementations for our customers and, at the same time, we’ve seen countless organizations’ self-made software struggles, so we have plenty of advice to share about the decision to build or buy your enterprise-level software solutions. We know the choice between two seemingly simple options can be the difference between finding answers, improving processes and keeping your business up and running – or not. So be sure to take the time to know your organization, know your needs and know the full extent of your options, so you’ll have the highest likelihood of achieving your goals.
Ready to learn more?
