Businesses can face sticker shock when implementing software or building enterprise applications. Even highly configurable and server-free applications like Salesforce can cost more to rollout than is commonly believed. The driver of costs has little to do with the number of users, but with complexity. For example, a project for 1,000 users doing one business process, in one language and one currency may cost the same as 100 users in a complicated business. Given the costs, it’s natural for managers implementing software to look to cut corners. But skimping on some aspects of a project may result in delays and bad rollouts, which in the end will add even more cost. The following list are four items managers are often tempted to cut, but shouldn’t.
Define and Design Time
Giving a cloud implementation partner a list of requirements and expecting it to start building is a bad idea. The “measure twice, cut once” cliche works in software as well as it does in woodworking. We recommend clients spend about 30% of the timeline defining and designing their solution. For example, on a ten-week project, a team should dedicate about three weeks for defining and designing the solution. The good news is that cloud platforms and crowdsourcing have made it easier to create prototypes and wireframes by making the process faster. Putting visual examples in front of users can save a lot of headache down the road. The define and design phase is also used to create and rank user stories, so that the valuable processes bubble to the top.
Data quality/cleansing and migration
Data migration is a key factor to user adoption. This is especially true when organizations migrate from a legacy tool to something new. The first question most users ask is “where’s my data?” It’s important that the team identifies those who will care for data and move it into the new system. Data cleanliness, accuracy of mapping to business processes, and completeness of data is critical. This is accomplished by spending time defining the tools to clean data and allowing people time to work on the problems.
User adoption or change enablement is an important and often overlooked aspect of any project. This process is about transitioning users and teams to a desired future state. Change enablement starts with asking questions. Asking and answering questions like the following early in the process will pay off:
- Do you expect a significant change in current processes? How significant (% difference)? Which processes will change?
- How many people are in each group of users? Are they all in the same location or set of locations, or are they distributed? In what regions or countries?
- Will everyone be using the technology in English? Will they all receive communication and training in English?
- What is each group’s general level of knowledge and acceptance of the upcoming change? Who are the key influencers for change?
From here, the team needs to task experienced people with building and executing a change management plan. Even when an organization is moving to a better tool, change is hard. It takes an intentional and sustained effort to make it happen.
User Acceptance Testing (UAT)
The first time key users see a solution should not be when they are getting trained on it. UAT is the process of validating and verifying the implemented solution by the actual users to make sure the system works as expected for all user stories planned for the release. UAT is often seen as something that happens at the end of a project, but planning for it needs to start at the beginning. A system for creating test scripts, training users, capturing feedback, and planning for fixes is essential. Granted, having users take time out of their day-to-day job for UAT is a burden, but well worth it. Testing a live application in production is a recipe for disaster.
When faced with a cloud implementation beyond a group’s budget, managers will always be tempted to cut one of these four areas. Our experience shows, though, that these are good investments of time and money. So if something does need to get cut, what should it be? The short answer: scope. Having the discipline to phase in functionality gives organizations balance to keep users happy while staying on budget.