Microsoft Dynamics xrm Delivery Mitigation in a Changing Environment. An Oakton Perspective. Consulting Technology. October 2013

Transcription

1 Microsoft Dynamics xrm Delivery Mitigation in a Changing Environment An Oakton Perspective October 2013

2 Contents 1. Introduction Why do so many projects run into difficulty during deployment? Convoluted design and excessive system development Failures and Challenges to implementations How do we know this? Getting lost in the details? Lost in the detail Deliver tangible business value from the starting block Ensure your processes align with the software application The why of the process Applying thought in design Case Management Analysis A risk managed approach Control Conclusion Final Thoughts More Information... 11

3 1. Introduction. When Microsoft Dynamics CRM is combined with the Microsoft Dynamics CRM Software Development Kit (SDK), we have the Microsoft Dynamics xrm Framework or Microsoft Dynamics xrm Development Platform. With each new release of Microsoft Dynamics CRM, the SDK becomes ever more powerful, allowing the platform to be used for a wider array of application implementations. Delivery success is reliant upon a number of factors, each important in their own right. Comprehensive methodologies such as Surestep and PRINCE 2 help to mitigate risk in the delivery of a Microsoft Dynamics implementation, but it is not unusual, as you will see, for projects to fail to deliver the tangible benefits a customer requires when choosing a software system such as Microsoft Dynamics CRM. This paper describes how to reduce the risk of delivery when utilising the Microsoft Dynamics xrm framework within a program of work by focusing on the operational, customer and financial values of a solution, ensuring a high level of user adoption and project success. Author: Nathan Small Nathan is an experienced CRM Functional Architect with strong architectural process. He specialises in risk management, pre-sales, discovery and design, with a broad focus around enterprise, industry, platform and solutions. He is responsible for defining the solution blueprint: providing the engineering view of the users vision regarding the structure and function of a system, as well as the areas in which a system must be able to evolve.

4 2. Why do so many projects run into difficulty during deployment? 2.1 Convoluted design and excessive system development Let me get straight to the point. The majority of software implementations including Microsoft Dynamics xrm projects fail to deliver an experience to the end user owing to convoluted design and excess system development by aiming to provide low level activity automation to the customer. Like any other development platform, Microsoft Dynamics xrm can be ill-used; inviting low level development by exploiting the flexibility and power of the Software Development Kit (SDK). As a development platform, Microsoft xrm is unrivalled in its ability to be utilised for almost any application imaginable. What the customer wants is almost always possible, and we all want to give the customer what they want, right?... This is fundamentally wrong. What a customer wants is to be led and educated on how we, as the Microsoft Partner, can help them improve their business by implementing a solution which provides absolute value to them as a business and to the end users of the system in an operational capacity. Do not be afraid to lead the customer: we are the experts and they look to us for guidance. This invariably means a difficult conversation now and then, but the end result is a high likelihood of project success and the realisation of benefits.

5 3. Failures and Challenges to implementations. 3.1 How do we know this? Varying statistics have been published which show IT Project failures at 63 per cent, and generic CRM implementation failure rates between 50 and 80 per cent. These are project failures, i.e. projects which have been abandoned or have not been adopted by the organisation after completion. In addition to these are project challenges, i.e. projects which have either over-run by time or budget. Commonly, the reasons below are cited for failure: 1. Lack of ownership 2. Poor stakeholder engagement 3. Little or zero adoption 4. Getting lost in the details 5. Setting expectations too high The above list can go on and I am sure many of you reading this have had other issues which have made what should otherwise be a smooth implementation run into difficulty. However, the main points are here and I for one agree with them. The interesting one to me is point four, getting lost in the details. Let s discuss this a little more as this point has a very real impact on every other point in the list.

6 4. Getting lost in the details? 4.1 Lost in the detail Imagine a pyramid with five levels. At the top of the pyramid is your organisation, level 2 is a business area within your organisation, level 3 is a core process within that business area, at level 4 are the people within your organisation involved in the process, and finally, level 5 is a detailed layer of the activities and tasks which need to be carried out within that process. While it is important to understand the tasks and activities that are carried out within each process, it is worth noting that a software application is likely to track activities and tasks in its own way as part of its core design. Above this level, the process itself is more than likely able to be tracked using the application s built in functionality. Essentially this is one of the main selling points for the Microsoft Dynamics CRM product. Changing the built in functionality at the applications process layer or activity layer introduces an immense amount of risk to a system. It invites development over configuration, especially if the golden rule of 80/20 is not adhered to. Note: The 80/20 rule is the reverse of the Perato Principal in this case where 80 percent of your operational functions should be a vital component in the new system and the exceptional 20 percent should be impact assessed to see if a real need exists to have the exceptions handled within the solution. Focus on the process layer and ensure the workflow is sound, adaptable and solid. Use this as your basis for the application and work around it, and do not try and force an exception or detail into process automation.

7 5. Deliver tangible business value from the starting block. 5.1 Ensure your processes align with the software application Use the chosen application to drive your processes first, and your process activities second. Any activity not providing a measurable financial, customer or operational level of value should be considered surplus to the application barring legislative requirements, certainly in its first release. Take the example below: Complaints Client Notification Source Evidence Education Material IN Investigation Material Evidence Template No Action Close Investigate Recommendation Educate Educate Issue Infringement Prosecute Complaints Open Review Recommendation Changes Required Accepted Seek Legal Advice Legal Report No Each item in the diagram with a + contains a number of activities and tasks which are carried out as part of its operation. For example Educate contains activities to search a third party system for material, speak with another department to get advice, write a letter and so on. Every activity does not need to be drilled into, monitored and reported on by the solution. The application is helping to formalise the process giving the most business value, not to formalise the activity which is the most exposed to change.

8 6. The why of the process. 6.1 Applying thought in design "First of all,' he said, 'if you can learn a simple trick, Scout, you ll get along a lot better with all kinds of folks. You never really understand a person until you consider things from his point of view...'" - To Kill a Mockingbird: Harper Lee Current business situations are primarily, as the name suggests, current. Applying design thought to the current business process will not allow the adaptability an organisation needs to cope with future shifts in technology, business processes or legislative changes. Breaking down an organisation s processes into functional areas which are the least likely to undergo change and functional areas which are more likely to undergo change, allows you to design your system with the maximum level of flexibility, leading to a more adaptive system for the future. 6.2 Case Management As an example, Microsoft Dynamics xrm is now a highly regarded choice for Case Management, the Case being a something that needs to be tracked through a process from submission to completion. Submission Assessment Cycle Outcome Fig 2. Case Management If you break down a case management solution to its simplest terms you find that a case is opened via a submission of some kind, assessed, processed and subsequently closed. This structure is true for the majority of Case Management requirements, albeit in very simplistic terms. What defines the key differences are the Activities which are carried out through this process, which then ensures the closure of the case. For instance, activities in a university admission applications process will differ from the activities in a governments sporting grant application process but the core process is largely the same.

9 6.3 Analysis If you analyse at the activity level without understanding the why of the overarching process, you fall into the trap of focusing only on how the overarching process is currently carried out, logging each step by step activity, adding the required tasks within each step to the requirements register. This leads to a distinct replication of activities an organisation currently carries out to get from A to Z, with zero regard as whether or not each step provides the operational, customer or financial value propositions you should be looking for. When you have an understanding of the why of a process, can you then intelligently reengineer that process into a simpler, adaptive process fitting the capabilities of the xrm solution utilising the golden rule of configuration over customisation. Track and Trace Fig 3. Track and Trace Essentially what is left is a solid foundation for an application which provides a highly reportable track and trace Case Management System, with an adaptable skeletal structure of processes to provide the end user the ability to carry out their duties with visible benefits and minimal impact. Only when the client is fully educated with the platform should further low level automation be implemented beyond a legislative need and again, only then when it is clear what the business case is for doing so.

10 7. A risk managed approach. 7.1 Control Use a controlled approach to an implementation. While it is essential to map and understand the low level business processes, it is more often than not, unproductive to automate many low level activities within a proposed solution. Value starts at a high level and filters down. It is more important that the core foundation of an application provides the structure an organisation needs to adapt to the every changing landscapes of technology, environment and legislation. Low level tasks can be implemented at a later date when users have adopted the system and have an educated input into how the system can be of further benefit without adhering to any legacy systems they are familiar with. Org Area Process People Activities/Tasks Greater Compliance More Automation Higher Control Higher risk of Failure Higher risk of Delay Higher risk of user rejection Fig 4. The Right Balance As compliance, automation and control increase, so does the complexity and cost to design. Taking a managed approach to risk can drive down the cost of system development. Consideration needs to be made of other less tangible benefits such as increases in team motivation and morale when the level of process control increases.

11 8. Conclusion. 8.1 Final Thoughts Simplicity is the ultimate sophistication Leonardo da Vinci Designing an xrm application focusing on the low level, low value, and low regulatory compliant activities within a business process creates unnecessary risk of: Disengaging the project sponsor who cannot match the approved business case to the developing system. Stakeholders failing to engage with the project team who are simply implementing a system without delivering noticeable customer, operational or financial value. Users rejecting the system due to an overly complex design or interface, and is inconsistent and difficult to learn. Setting expectations too high as a result of building to a wish list of every low level action a system could perform to help a user complete their day to day tasks. 8.2 More Information If you would like more information, or would like to discuss what steps you could take to rectify any issues you are currently facing in your Dynamics xrm implementation, please contact me using the details below. Nathan Small nathan.small@oakton.com.au t f

12 ABOUT OAKTON Oakton is one of Australia s leading technology and business consulting services companies and is listed on the Australian Stock Exchange [ASX: OKN]. Oakton helps some of Australia s largest organisations across a range of industry sectors meet their technology and business needs through its flexible, cost-effective and results-driven approach to service delivery. With over 1,100 employees, Oakton has offices in Melbourne, Sydney, Canberra, Brisbane, Perth and Hyderabad (India). View more Thought Leadership from Oakton For general enquiries please contact: enquiry@oakton.com.au or visit For all media and PR enquiries please contact: Holly Corns holly.corns@oakton.com.au