Many reasons can throw your project or solution off the rails, and most of them are not technology related. How can you tell if your chosen technology is actually the reason? There are several warning signs, and this quick list will help you identify them.
© iQoncept – Fotolia.com
Too Much Assembly Required
There is a distinct difference between customization and extension. If you use very little “out of the box” you might have chosen the wrong technology. Customizing requires you to build entirely new or changing core principles of the software you’re using, or customizing may mean you’re using hardware for different purposes than it was designed for. Extending the technology means you’re using its core functionality as intended, but you’re giving it the means to reach further. It’s fine to extend the technology, but customizing every aspect can make it become unstable. Customizing the technology from its original intended purpose can also be very expensive. Choose technology that can accomplish 80% of what you’re wanting to do at a minimum.
No Internal Knowledge
If you don’t have anyone in your organization who knows the software or hardware you’re in trouble. Long term, extensive support can be more expensive than a full-time employee dedicated to the survival of your application. This holds especially true when you’re introducing something new to an existing system or process. You want to have someone in-house that can answer questions or lead projects which include the software and hardware you’ve chosen. If you haven’t started your project, begin the search for someone who can take it on internally or hire someone who can bring that knowledge for you.
High Maintenance = High Attention
If your solution is draining your budget faster than you can recoup you’re in for a rough ride. Similarly to when you don’t have an internal employee running the project, some projects may require many institutional decisions on the fly. If you find yourself discovering something new about the technology which may require many changes to the original scope or requirements you may need to reconsider your technological path. It’s safe to assume in any technology project there will be changes to scope and requirements, but it should not be a daily discussion. The changes should be subtle which should still lead to the institutional goals. If you find your goals are shifting because the software “just doesn’t do that” then reevaluate your current trajectory.
Save Yourself. More Due Diligence
Budgets are usually set before or shortly after the discovery process begins, but be sure you include time and money in your discovery when choosing a product. You won’t find out all the answers to every possible scenario before you begin, but if you have a clear goal to attain you will be better prepared for the questions you need to ask. Put some space in your budget for changes in requirements which often require an adjustment in time and fiscal responsibility. The preparation and due diligence will eliminate surprises in the long term which can cause projects to spin out of control.
Talk to me: Have you ever made a bad technology decision? Share your story.
