This two-part series first covers identifying and avoiding the most common risks we see in business technology projects. In the next post, we outline some of the most important aspects of getting started.
Understanding the major risks and how to navigate them
After working with many different companies across industries, we’ve identified what we think are the most important aspects to avoid project failure and unexpected cost. By no means is the list comprehensive, but it encapsulates what we see time and time again, and the areas described are those that we dedicate the most effort toward. You can see a common theme is preparation – clear, well-documented. Without attention in the following areas, projects are quickly derailed.
Start with process
Software is made to assist or improve processes, not replace them. If a process isn’t in place, or if it’s deeply flawed, the software you build around it will fail. Consequently, you need to analyze the current state of processes and determine what’s needed from them in the future before taking on software projects around them.
[bctt tweet=”If a process isn’t in place, or if it’s deeply flawed, the software you build around it will fail.” username=”gointerject”]
Current-state analysis is a critical requirement. Developing and documenting standard operating procedures (SOP) is a fundamental aspect of this analysis. Without SOPs, the plan for developing, testing, and implementing software around a process is ambiguous, at best. Document what the process looks like now (try to keep it brief and easy), and what the vision is for its future.
Also, keep in mind that the squeakiest wheel doesn’t always need the grease. A process can be extremely painful but so infrequent that the cost of automating it outweighs the cost of doing it the old-fashioned way. Beware of emotional (knee-jerk) reactions to processes. They can make a lot of noise and little impact.
Consider culture fit and culture shock
Culture shock happens when you change too fast. So, for example, if you have an Excel shop, going quickly to a visualization tool might upset the team. You can get there, but it has to be iterative, folding in change at the right time so that you’re not climbing the second hill before you get over the first. And there’s a balance between growing and updating practices and listening to your team, understanding how they work best. How do your analysts get their data? What are the exceptions that keep things manual? And what sorts of process empowers them? Taking account of those cultural leanings and avoiding culture shock is incredibly important. Finding solutions that fit and grow well into the existing culture will improve your chances of success, and it’s a major aspect of change management that demands attention.
Think early about transitioning
Among the fastest routes to project failure is the one that pushes a new project out to too many users. There’s often a well-intentioned urgency to get new software into every user’s hands quickly or complete the implementation by a certain deadline. For obvious reasons, simple full implementations sound desirable. But pushing too wide and too quickly can sacrifice key results for making your deadline. Even worse, when the details and testing don’t indicate a good implementation, doing it anyway can cause irrevocable damage to clients from quality issues, and can harm employees by making them work late hours to cover what was missed. Moreover, failures on a wide scale are more costly than failures on a smaller scale. Before even starting your project, pick a vertical slice or specific business unit and implement the project only in that slice. An iterative implementation with early testing is key to driving early successes.
Invest in training
Related to transitioning, early, thorough training will smooth an otherwise rough transition into new software. Get your teams involved in the software as early as possible and begin phasing in training as soon as you can, preferably well before a project even gets started. And know that your team’s training is multi-layered: there is training to explore functionality, training for (and as) a proof-of-concept, training for implementation. But, beware of training too far in advance of actually using the software, as knowledge can become stale and the users will struggle to remember if the implementation is too far out.
Training is not a one-time deal; it’s continual. You want the path to new software projects well worn, comfortable—old news—before a project even goes live. If you’ve instilled training into your team’s culture, you’ve done the right thing.
The Interject Financials Team is dedicated to building smart, simple technology solutions from a business-first perspective. Our years of combined experience translate to quicker implementations, wider adoption, and more efficiency in your business processes.
For more info on Interject’s solutions, email communications@gointerject.com
