If you’re looking at automating a new system, here’s a cheat sheet to help you avoid common pitfalls.
Here at QueBIT, we have developed hundreds of solutions for our clients. That’s as expected, it’s our 
business! We strive to get input from business users prior to implementing their new systems. Standing up a new, automated solution (planning, sales forecasting, or operational) is exciting, and can be transformative for an organization and its employees. We don’t want you to have to re-create the wheel, when implementing a project.
Note: Some of the examples in each of the pitfalls listed below are Planning Analytics and TM1-focused, but the pitfalls themselves apply to almost any planning, analytics, or predictive implementation.
1. Too much focus on the software feature/functionality, not enough focus on the business skills of the consultants delivering
I’ve been involved in dozens of sales cycles, where a client is evaluating alternatives for a planning model, a sales forecast, or an operations dashboard. One thing I’ve noticed is that people put a significant amount of time into evaluating the software options, comparing features, pricing, and technical requirements. That is as expected, after all, you want to get the best product money can buy!
After carefully analyzing the system costs and features, most people don’t put much (or any) time into evaluating the team that will actually implement their solution. This is equally, if not more, important, than the product decision. After all, what good does it do you to have the best product on the market, if it is implemented poorly?
How to Avoid this Pitfall:
- Look for consultants with business acumen
- Make sure you’re talking with developers, in addition to sales people
- Ask yourself: “Do I think this team can deliver?”
2. Not dedicating enough business resources to a project to ensure it will meet your needs
Even out-of-the-box solutions need care and feeding to be successful. Change is hard, we all know that, and organizational change, involving many people and processes, is even harder. Getting a new system in place is change, and it is much more likely to succeed if someone is passionate about making it happen.
It is difficult to have business users engage during a development cycle, because they already have full-time jobs! But, without critical input from the business, the solution is likely to fall short and not meet their needs.
How to Avoid this Pitfall:
- Assign key business users to the project, with the expectation they will engage for a few hours a week directly with the developers
- Increase this commitment during critical stages of the project (design, data validation, report building, training)
- Get executive sponsorship to ensure your business team can prioritize the implementation effort
- Be realistic about the timeline—you may need to stretch the work out over a longer timetable to get the level of participation you need from your business users
3. Letting the data drive the design, rather than the business needs
It is a common mistake to design a solution around the source data—especially if the developers do not have business backgrounds. This is backwards. Data can, and should, be integrated on the back-end so that end-users have a common, seamless experience on the front-end. This applies to everything from the conceptual framework of a model to something as mundane as naming conventions.
Look to the business processes being served, and the desired end result, to drive your approach. For example, make metrics data like headcount, square footage, and units sold readily available alongside financial data, in order to streamline KPI calculations, and to more easily integrate driver-based data directly into your models.
How to Avoid this Pitfall:
- When designing, start at the end: look at the reports and modeling output you are striving for, and use that as your guide
- Use natural language for naming conventions: “Expense Account” is much easier for end-users to grasp than “GL_ACCT_EXP”, for example
- Make sure your solution fits in with the business processes it serves – there are interdependencies between technology and business process, and often, these interdependencies are not taken into account in the solution
4. Over - automation (a.k.a. “too much, too soon”)
So you’re finally getting that new planning system, and you’ll be able to retire your convoluted spreadsheets—kudos! Sometimes, people are so excited about centralizing a process that has been cumbersome and manual, they just want to automate everything about it right away. Keep in mind that making any business process more streamlined and centralized also generally means making some hard choices about calculation methods, naming conventions, and data definitions. Ease your co-workers into this by keeping some flexibility in your model. A model that is overly boxed-in with calculations, for example, could frustrate the forecasters who need to override a particular calculation as business needs evolve.
If you have a well-planned process that is accepted and understood, then go for it! Otherwise, take it slow.
How to Avoid this Pitfall:
- Start slowly with calculations – build in key calculations that are stable, but don’t be afraid to keep some supporting calculations/modeling in Excel, at least in the short term, so you can determine if it’s ready for automation
- If you’re new to approval-style workflow, keep it simple at first
5. Lack of attention to roll-out
People are not computers. Even if your new planning (or sales forecasting or operations analysis) system is the cleanest, simplest, easiest to use web-based application, your adoption will flounder if you don’t pay attention to roll-out. This falls under the same “change is hard” heading as #2, above. The best timing for a system is to roll it out at least a quarter before you really need it, to give users a chance to simply consume reports and perhaps start doing some small things, like entering variance commentary, before they are using the system to generate their plan.
A strongly supported roll-out not only increases adoption significantly, but it helps your organization start to grow your own internal resources, such as power users, that will fuel further growth for your solution.
How to Avoid this Pitfall:
- Rollout a few months before your next business cycle
- If you’re doing a large rollout, start with a small pilot group and get feedback as you go
- Offer lots of support and hand-holding during launch
- Continue supporting your solution with monthly “brown bag” lunches (virtual is fine!) to offer tips and tricks, and answer users questions
A closing note: Celebrate your victories along the way! Post-project, your new implementation may be live in production, with many happy users, but it will still likely be a work in progress. A healthy implementation is one where change is controlled, but frequent, to ensure that the system stays relevant to the organization’s changing needs. So take the time to pause and recognize how far you’ve come from time to time. It will pay dividends for ongoing usage, and adoption.
