Business Success is a Process Thirty years and hundreds of customers and projects later. Across multiple enterprise applications SAP, Oracle, JDE to Microsoft Dynamics. Businesses want successful outcomes. They use enterprise software to use as a tool to drive continuous business improvement, a process… But they buy software as a project, with a distinct start and end, an event. The disconnect between wanting “process” and buying an “event” is a primary reason why enterprise software projects fail to meet their objectives. Improving business process and business profitability occurs after the platform is implemented. DynamicsAMO transcends the gap between buying and using. We work with our customers to improve the way that they use Microsoft Dynamics to improve their business process and profitability. 1st get the transformation platform in-place, then you can begin the process of transformation.
It takes a different skillset, a different mindset, and a different business model to be great at supporting, improving, and transforming a company than it does to be great at selling and installing the software.
I started DynamicsAMO to help companies to get the REAL VALUE from their Microsoft Dynamics systems. I had been involved in selling and implementing more Dynamics software in more different countries than probably anyone else on earth, but I was bothered that in our role as consultants that we did a lot of the building blocks but were gone before the real value started happening. We did good at helping companies to buy the right package and we were good at working with our customers to implement the software and to get it “live”. But those two activities just set a foundation and tools for business improvement. Our business model worked for selling and implementing but would not work for supporting and for helping existing Dynamics customers efficiently.
THE NORM First SAP, then Oracle, JDE and now with Microsoft Dynamics. Over 30 years and hundreds of projects, I learned to accept that ERP or CRM projects, regardless of software or the expertise of the teams is able to deliver the vision or fulfill the expectations of the project’s sponsors. While disappointing, I also understood that ERP and CRM projects are worthwhile, deliver value, and improve process for their customers. The large gap between what the sponsors expect and what the customer gets has existed for decades. Our industry has learned to accept this gap as normal. I accepted it as normal.
EVENT But that began to change last year. I had invested in an early stage company that was having good success and was growing nicely. Mark, their CEO proposed Microsoft Dynamics 365 for Operations (ERP) for financials and project accounting. Mark explained the selection process and walked us through a presentation of why the selection committee recommended Microsoft Dynamics. Mark described how Dynamics would provide the company with better business insights, allow it to be more responsive to customers and how it would make people more productive. Mark described how Dynamics could help the company to execute its strategy today and how it could support the company’s vision for the future. Then Mark walked us through the vendor proposal and implementation project plan. The plan was clear and well-written. The scope was well-defined and seemed realistic within the timeline. The plan had clear milestones and timelines. The proposal documented project assumptions, interdependencies, contingencies, roles and responsibilities. It clarified governance and the role of the executive team in supporting the project including making decisions quickly, dedicating key resources, and keeping them focused. Then we reviewed the investment analysis (the costs). I don’t know that prior to the meeting that anyone had preconceived notions about what the total cost would be. But once we saw the total, we knew that it was too high. We asked Mark to find ways to reduce or defer cost by going through the proposal line-by-line looking for cost savings by eliminating or deferring certain items or shifting appropriate work from the vendor to the internal team.
RECOGNITION At the next board meeting Mark had good news. Mark and his executive team trimmed the vendor proposal by 20% without losing any major business functionality. The executive team agreed to take on some of the work that was proposed by the vendor, they made some small changes to licensing, and deferred some non-essential functionality in favor of manual workarounds that could wait for phase II. We were impressed by the willingness of the executive team to ‘work for their system’ and participate in reducing the costs. Suddenly, while we were congratulating Mark on his leadership and as we were about to approve the project that I was struck by a moment of clarity. I began to understand how and why large projects don’t meet the initial expectations of their sponsors.
CLARITY First, the cost went down, but our expectations of results didn’t change at all. We heard the words “executive team agreed”, “without losing any major functionality”, “take on work proposed by the vendor”, “defer functionality”, “use manual workarounds”, “phase II”. But we glazed over the implications of those words. All we thought about was operate the company better, achieve our long-term vision, executive commitment, and of course cost savings. We are diligent people but we didn’t ask questions like: what does “executive team agreed” mean, will they have their teams work Saturday and Sunday to do the work that the vendor had proposed? Is their time worth more or less to us than the consultants time? When there are orders waiting to ship that they will doing writing use-cases instead. What does will in not lose any major functionality mean? Clearly some functionality is lost. What does it mean to do manual workarounds, are they worse than what the users have today? How will the people feel about getting less than they have today? If there is a phase II, is this for phase I. Is there a phase III? How many phases are there? Will there always be a “next phase”? If so, how many people need to be involved in a next phase? Do we need consultants to do a next phase? I got over the nauseous feeling in my stomach, voted yes with everyone else and away we went. When I got home that night I looked closer at how the savings were achieved, particularly the items where the internal teams took over tasks that the vendor had proposed doing. Data Migration, reports and interfaces, end-user training, system testing, use-case writing, … then I looked at the interdependencies. It wasn’t horrible but there were a couple of items that the internal team is responsible for that are clearly in the critical path and are early in the project. Data migration and use-case writing are early and on the critical path. I looked to the contingencies section of the proposal for what would be done in the event that the internal team was not able to deliver. The matter would be escalated to the executive sponsor and together with the steering committee they would decide how to get more resource to keep the schedule, or they would move out the date and adjust the budget, or they would keep the data, keep the budget and reduce the scope.
PERSPECTIVE I thought back to the projects that I have worked on and to the Project Management Triangle. Time, Cost, and Scope. When one changes the others adjust. The essence of the problem: (1) During the buying process, cost and scope change but expectations of the sponsors doesn’t; (2) During the project, when tasks run late (time), to protect the cost, the scope is reduced; (3) During the buying process, future phases are considered but by the time the project is over, no one wants to think about phase II and beyond. How the problem manifests itself in practice.
-
Company decides it needs ERP or CRM to support its business ambitions, runs selection process and sees a dizzying array of dreamlike products and features. They select a vendor and work on a scope for phase I.
-
Company receives the proposal and trims it back reducing or deferring scope while taking on critical interdependent tasks
-
The project starts. During the project:
-
The company is unable to fulfill some of the tasks and the scope is reduced to protect the project budget.
-
The consultants lose people and critical project and organizational knowledge. The replacements have different ideas on how to implement the system.
-
The customer team is not able to dedicate sufficient time to the project because their regular jobs duties were not able to be passed on.
-
The customer takes on a new business initiative or business reorg or acquisition that requires their best people, some of them are on the project.
-
Periodic “show and tells” reveal a poor initial user experience until some of the scope is brought back and the cost increases while the timeline is extended.
-
-
There is plenty of blame to go around but the stress of exceeding the budget while decreasing scope hurts everyone’s feelings and the company gets as tired of the consultants and the consultants are tired of the company.
-
The project goes live with a fraction of its initial scope while exceeding its budget and creating a poor user experience. The project team is tired and they go back to their old jobs and the consultants roll-off.
-
When the company calls the consultant for support, they can’t get the original team back to help because they have moved on to another project.
-
There is no one to do Phase II and beyond. The project has lost all of its momentum and knowledge.