Ingredients 

• A solid business case
• Top-level management support
• A motivated team
• A competent consulting company
• A sandbox system
• A good cross-industry business network
• A lot of organizational change management
• Legal & auditor advisory
• Braveness, power, endurance, speed, humor, respect, and no fear at all

Getting Ready

First, inspect the business case. It should have a good, and hard TCO reduction. Watch out for hidden costs and add a good portion for the transformation project. Do not rely too much on soft or hidden benefits. Second, prepare a one-pager. Give your transformation a really cool and catchy name. Harden it by presenting it to colleagues, consultants, friends, and enemies. Give it the final polish by presenting to selected stakeholders and influencers. Finally, get the buy in and the support of the top-level management. Walk in their shoes - what will they say about it in their next C-level dinner? Bring the name and this short story across. Take special care about their short attention span. 

How to do it 

Now that you got the approval to do it, the work starts. Preparation is key. IT projects contain four major ingredients: the IT system, the function, the people, and the documentation. It is like baking a cake. While preparing the dough there is plenty of time and chance to taste, adjust, remix, and season. While baking, there is only limited influence on the taste and consistence. Your cake will be as good as the preparations and the experience in execution.  To follow the picture of baking a cake the project is done in four steps: 

• Preparing: Mixing the four components in a save non-productive environment such as a sandbox, inspect and adopt until you get ready.
• Get ready: Transfer the prepared components into the live environment with live production system stream (D/Q/P), procedures for production system ready tested functions and data, prepared live company organization structures developers, product owners, stakeholders, and end users. Prepare templates for audit-proof documentation, among others.
• Get it done: Create the basics by creating the standard customization. Add all the typical non-basic functions as interfaces and printouts. Be stingy when it comes to custom code. Test, migrate, train, and start.
• Under any circumstances: Don’t change the now running system! Correct errors? Yes! Add changes? No! Inspect and later adapt with the whole picture of experiences.

Like every project, you win or lose in the first quarter of the total expected duration, so create reusability! Build a system with functionalities that can be felt by the people. Document the ‘Why?’ you created and tested these functions, and the ‘How?’ one can see in the system.  Avoid the technical depth under any circumstances! It is not like investment and depreciation. It is like lending from the future at usurious interest rates. 

How it works 

Prepare  Assemble your core team. Find the motivated drivers in your company you can trust. This will be the skeleton of the whole project. Choose wisely. Now, to bring them at your side, fill the project into the lists of the company’s project organization, inform the quality, risk, auditor, and legal department and get the buy in of the union council. Find a good consulting company and lay out the project master plan. Draft major use-cases into a sandbox. Focus on the FIT. Strain the GAPs: Check how peers in your industry have proceeded. Learn the SAP best practice solution and force the organization to use it. Do it on paper and pencil outside the system. Invent a bridge for this GAP worth selling to others. Iterate with the sandbox until you are happy with the designated function. The answer to the “Why?” on every customizing in your sandbox is your business requirement or user story. Now that we have documented this pilot installation, we can prepare to execute the project. Get ready This may be the hardest part: You must take full load on your change train. Until now the visionaries and drivers have worked on the transformation. Now you take the supporters, passives, slowdowns, and even saboteurs on board. Use all means of communication and top-level announcement. Make it your “Fridays for Future” movement and at the same time a Navy SEALs squad operation.  Get it done Execute your master plan in six steps:

1. Get everything with standard customizing running: Bridge interfaces, use standard printouts, simulate enhancements, and work with predefined authorizations. Prepare the environment for developments to be ready for Phase 2.
2. Divide and conquer: Start in cross business-functional sub-streams for each; the interfaces, printouts, and enhancements. Use the same principle for authorization. Develop the organizational change, test, training, and migration concepts to be ready for Phase 3.
3. Assemble the pieces: Test cross functionality in several rounds, finalize the tests including documentation as draft versions, develop training documentation, do test migrations, and communicate. In this phase follow the simple rule: One cannot over-test and over-communicate. This phase is the rehearsal for Phase 4.
4. Take off: Migrate, train, test, go live. Repeat in a documented and audit bulletproof way the ramp-up of the productive systems. Create master data, users, authorizations, and the relevant transactional data. Test with two eyes principle and written evidence. Train the users according to their future roles and so authorizations. Ramp up interfaces, inform clients, suppliers and anyone else might concern. Enter the runway and launch.
5. Avoid any risk while reaching travel speed: Don’t change what works. If there are mistakes, performance issues, or wrong authorizations, fix it. Don’t change functionalities! In Germany there is a word for it: “verschlimmbessern”, literally "worsen it while attempting to improve." Get experience with the system. Provide workarounds and collect new function requests. Will it be hectic? Yes! Will it be boring? Yes! During this phase, avoid changing a running system at all costs. This is part of Phase 6.
6. Evolution: Enhance the system continuously in sprint cycles and minor and major releases. Plan at least once a year to give it a synchronized drum beat for all applications. Sprint, sprint, sprint, release…

Each phase should be done in eight weeks with three sprints, two weeks each, and one sprint to inspect and adapt your milestone plan for the next sprint cycle. Don’t forget vacations. Velocity is key or your project will be overtaken by the speed of change and other priorities.  Maintain and Retire Whatever you do, think about the disposal of the data created. Revisit the code basis frequently; delete unused code to avoid security breaches types that are unknown today. Delete data you don’t need. Retire the unused parts of the system with every release. Make it lightweight, flexible, and fast by maintenance design.

See also

This recipe is an opening to a series of articles. For the business case, refer to this article. In preparation:

• RISE with SAP in a nutshell: To whom “RISE with SAP” is attractive and what should you watch out for when dealing with this way into the cloud.
• Pitfalls and hacks in cloud project budgeting and accounting: New IFRS rules shake up the way projects are being capitalized and depreciated, if even possible. What are the risks and how to gain benefits from it?

What do you think interests you?

• Clean documentation for an SAP project
• Organizational change management

Please give me your wishes for the additional knowledge you are interested in.