By: Alan Earls
The idea of “out of the box” enterprise software can be a double-edged sword for firms that sell and deploy it. Customers are drawn to the promise of low-risk and low-cost implementations, but the reality of deploying software like ERP or CRM means that implementation projects remain complex and carry risk.
Consultants offer a range of proprietary implementation methods for packaged solutions like Dynamics 365, with the aim of both differentiating themselves relative to other firms and improving the chances of a successful deployment. But are the bells and whistles of a proprietary methodology worthwhile? What do companies in the business of implementing solutions say about what they and their competitors do?
“Rather than methodology, I prefer the word approach,” says Elliot Fishman, CEO of Catapult ERP Systems in Vancouver, BC. Whether for ERP or CRM, virtually all types of system integrators like to follow an approach that starts with some kind of visioning or planning, then gets into design, development, and configuration, followed by testing, deployment, training, and, ultimately, stabilization. Those phases span activities from forming of ideas to a live solution.
“I haven’t come across a methodology that is vastly different except in a few cases, particularly on the CRM side, where you are building more robust relationship management capability based on a CRM platform,” says Fishman. In those instances, he notes, you might take a more agile approach or a sprint-driven prototype model. But, he adds, the agile approach is often difficult for a client to follow in ERP or CRM-focused projects when there are budget constraints. “They need to know what they are getting into,” he says. In other words, an agile methodology is usually “a bit more free-flowing” and you are expected to simply move ahead and then see what you get at the end.
As principal consultant, at Tampa-based Tribridge Consulting, Jessica Noble believes the number-one value of a proprietary methodology is that it is refined over time. The experience and lessons learned from hundreds of projects and customers in different industries and different types of implementations add up. “When you do this over and over, you become better and smarter about how to handle certain requirements in design, how to test, and so on,” she says.
For example, on the financial side of a project, she and her team have learned it is vital to understand the chart of accounts over and above other elements. “If you were to use a generic methodology, you would treat all the requirements equally and then design for all of them at the same time. We try to nail down a chart of accounts and find out what senior leaders, front line staff, partners, and customers need in relation to that,” she says.
Tribridge also focuses on knowing where the key customer data is (sometimes in a CRM rather than in ERP, for example), and how it is being used. “Often, we find it is helpful to go through a ‘day in the life’ with different functions, such as people in sales, to see how systems affect them and what information they use,” she says. This can be costly and labor intensive, but you can really glean the true requirements and hone your design accordingly, she adds.
The built-in divides of classic methodologies
To look at the issue of methodologies another way, could following a generic methodology, like one supplied by a software vendor, detract from a solution’s value?
According to Peter Maloof, vice president for digital experience and disruption at Capgemini, what is missing in a generic approach is taking the time to speak both the language of IT and the language of business. Project post-mortems on what went wrong often reveal different or conflicting goals within the client organization, notes Maloof. And a generic methodology is unlikely to help bridge those differences.
“Often the CIO organization is focused on delivering on-time and on-budget, so that factors into their decision-making process, meaning they are often happy to take something right out of the box,” says Maloof. “They think everyone will be happier if they don’t have to spend money to customize.”
Using software right out of the box is cheaper, but often means forcing a process change onto the business. “With our methodology, we create a decision framework that includes a weighted score card where we ask the client about business value and sustainability,” Maloof explains. Often the business side wants something more customized, but IT “freaks out and tells them they have champagne tastes but have to live with a beer budget,” he says.
Another issue identified by Noble is that a one-size-fits-all generic methodology is usually closely aligned with the perspective of the actual software vendor, making it unrealistic to many individual circumstances. “Proprietary methods will take into account the real capability of certain types of solutions because the provider is steeped in experience and knows both the benefits and the robust areas and capabilities,” as well as weaker areas, she says. “You can help a customer explore and concentrate on the areas that will be most helpful,” she says. Thus, she argues, the proprietary approach is more representative of a firm’s philosophy and its approach to providing value.
“In our case it says we are independent and willing to make recommendations that are in your best interest,” says Noble.
Prove it
But with so many partners offering a proprietary approach, how does a customer choose?
Noble says the best thing to do is to ask a vendor is, why? “You want to know what led to their methodology and approach. Can they give you an example of how they got their bacon burned doing it a more generic way, so you know whether what they are proposing offers something better?”
Likewise, the vendor should be able to explain the risks or rewards of any potential shortcuts they propose. The answers they provide, and their ability to respond to further questions in detail, can indicate whether they have the required competence and the right skills for your business.
The key, in Fishman’s view, is to be predictable for the client, and get to value fast. “We have a concept we call lean deployment, and that means making an implementation project as simple and straightforward as possible, and making it lean and effective. That way, whatever gets deployed is at least the minimum viable feature set that the customer needs in order to be operating,” he says. That step will also be targeted to replace any existing capability that is out of date or deficient, and deliver some operational improvement with the initial deployment.
Without that kind of disciplined approach – the kind that services firms develop to improve repeatable, reliable outcomes – custom development projects can end up running 8-12 months or more, which leads to exhaustion of budgets and emotional exhaustion, Fishman says.
“We prefer to achieve results in three-to-six months. It is still a plan, design, configure process, but what we try to do is narrow the scope down to that minimum capability set,” he says. At that point, you can get users on board and start to shift the emphasis to operational improvement and an ongoing iterative mindset, he explains.
Next time: Project management approaches and tools for Microsoft Dynamics
—