# 28 Let technology do the (dumb) job If you work on a complex project or complex technology, try to make the machine do the dumb jobs. There are many things that can easily be automated, trained to tools and applications. The more of the simple tasks you transfer to these little help-ers, the more time you have for the complex things. It’s like always a fully unscripted recording ! Happy to get your feedbacks! If you liked .. spread the news ! If you can’t wait for next w...

# 27 Multi sources for messaging create confusion If you use reminders / messages generated by workflow or systems, try to keep them to a needed minimum as they will sooner or later be ignored. Try also to avoid to have these mes-saged from multiple sources / different communication ways. They all look different, requesting different actions. The more you have different ones, the more likely is that a user oversees them or interpret them as a possibly unwanted message. This applies especially...

# 26 Be careful with workflows and remindersWorkflows can be a great tool to steer and control the execution of a business process where multiple people are involved. One great thing about workflows is, that the workflow engine can send messages to the persons who are in charge of the execution of the next step. Just like the „be careful with standard messages“, be careful with these. If the workflow sends a reminder to the whole finance department, maybe 10 people, to execute an invoic...

# 25 Be careful with standard messages popping up We all love to make sure that we did all correct. So often, we have the desire to have a reminder popping up asking us, “Are you sure that XXX is correct?” The intention is good, keeping the user awake and potentially reduce errors, but on the other hand, the more we have these questions and we answer them with “yes/click ok,” the less we look at them. So, they lose their meaning as we just click to continue! It’s like always a fully ...

# 24 Don’t over guide Typically “assistants” or user guided processes are needed in early phases of a project. Just like a step-by-step workflow, asking you questions, guiding you or offer pre-filled values. Most of these guided processes then include drop down lists to select something and then “click ok” go to next screen. In most cases, these assistants will have a lot of explanatory infor-mation. All this is good, if a process is either executed very few times or generally, the user is no...

# 23 Digital s**t does not smell… That’s all What is the difference between analog s**t and digital s**t? The analog one sticks at your shoes and smells... on the other hand, the digital one sticks on you but doesn’t smell. If you don’t do your homework and check what goes wrong in your old way of working and seek to understand why it’s going wrong, you will just implement the old/analog way. This ap-proach is not going to solve your problem. Generations of ERPs have been implemented to impro...

# 22 Don‘t make all your processes bullet proof Don’t try to make all your processes and exceptions bullet-proof. This will only increase the complexity of the implemen-tation and complexity is the enemy of stability, budget and success. Make your few core processes tank-cannon proof! If your employees can rely that a defined standard process is working stable and predictable, they can handle the exceptions. If you also try to make your exception process bulletproof, be sure to have the resou...

# 21 Don’t try to reach everything in one run When you start your project, the ambitions and motivation to change and go for the best are high. Even if aiming for the stars is needed to achieve best results, you need to be realistic enough to focus on what is needed. You will not reach any perfect result in one shot! Create something that is working. Give the team a success. Start with a minimum viable prod-uct/project. This makes failure less likely. Be sure some people will be disappo...

# 20 Don’t change / widen your scope Even though you should be open to increase the functionality, integration or usability of a solution, don’t change the scope once the project is started! Everybody tends to change or in-crease the project scope during the implementation phase as we all are learning and seeing that what we originally defined is not sufficient. Changing / adjusting the scope should only be done if there is an immediate and massive business value in-crease which over rules t...

# 19 Aim for the stars As your business vision is a vision and may never be achieved, your project vision must be open and wide. Don’t exclude ideas or solutions at the beginning. Think about all the integra-tion possibilities or features that would be great to use. As long as you stay realistic and know that aiming for the stars may result in landing on the moon, all is good. If you block yourself too early, you may even not reach a lift off. It’s like always a fully unscripted recor...

#18Coca Cola is not Pepsi One difficult thing for people is to imagine similarity or mak-ing abstractions. A Cola beverage is mainly water, sugar (or substitute), color, flavor, CO2. (Some details missing ... don’t hate me for that). If you now discuss at Pepsi a software im-plementation where you use the (perfect) slides you made for a Coca Cola project, the audience will in 90 % of the cases complain that „We are not Coca Cola and all is different“. They can’t abstract that maki...

# 17 A partner is a partner If you choose to implement a larger software project, you should consider the role of external persons / your implementa-tion partner. Complex software implementations need a deep understanding in your business and a deep trust from you in your partners. You should consider your implementation part-ner as partner not as a vendor/contractor! Same applies for other involved persons like freelancers, developers, sub-contractors. If you integrate them in your tea...

#16 Stay with your methods Once you start implementing a major software solution you will choose an implementation method, agile, scrum, waterfall, a special method from your partner, data first, logic first or what else is on the market and you think suits your business case best. All of these methods have shown that they work, at least for the business case they were developed. Make sure you have a suitable method and approach for your project. You should avoid mixing methods because ...

# 15 If a plan will fail, why should I plan? Good question. Like a famous quote in military lessons „No plan will survive the first contact with the enemy“ (attributed as quote to many historical military persons). This has been proven by many battle plans in history, but military does not stop making plans. Are they stupid? Wasting time with plans? No they are highly intelligent! (However you can generally question if any kind of military action is intelligent). By play-ing / making the plan...

# 14 If plan “A” fails, the alphabet has 25 other letters As mentioned in „A Plan is a Plan“, things can go wrong and will go wrong. (Remember Murphy’s laws) Most likely failure will happen the moment where it’s either completely unex-pected or most critical. A good thing to anticipate that, is to have a draft version of a backup / failure plan. This does not mean to have a detailed version of it, but having this in mind or drafted will help you to focus again if there is a major change...

#13 A plan is a plan When you handle complex projects, making a plan how to execute the different steps, identifying the critical path, defin-ing the resources and working on different scenarios is crucial-ly important. But life / your project will not follow your plan! The moment you signed off the plan, started to work on it, things will diverge from the plan. Now comes the situation everyone fears, the plan does not match the reality anymore and needs to be adjusted. The magic is about, ho...

#12 Don’t do too much parallel During project execution we will face challenges that things don’t go like they were planned. We then tend to find ways to optimize the progress.. These include strategies like adding more resources, but be careful, typical elementary school math question: if one musician plays a song in 5 min, how long does it take if you add 4 more, not 1 min.. it still remains 5 min and if they want to play it proper they need some preparation time! Beginnin...

#11 What is said, is said This goes with „People hear what they want to hear “, once a message is out, it's out! If you speak about budget and say any number, the moment you said it, this is the target budget, at least if it is less than the audience expected, even mentioning that it needs to be confirmed will not help in future discus-sions. The figures are in the head of the audience. Same goes with a solution promise. If you confirm that this or that can be done, and the audience wanted to...

#10 People hear what they want to hear You can have PowerPoints or Excel-sheets as many as you want. You can hold meeting and explain facts and details. In many cases the audience goes the easy way and „hears what is comfortable “. If you are on a tight budget, the finance team most likely will pay attention on any comment and information about staying in budget/reduced costs, but not hear the risks associate with it. Be careful what you say! It’s like always a fully unscripted record...

#09This system even does not have an invoice layout One of the comments I often had about IT systems is their ability to generate a desired output /print/file format. Most of the time it is either about finance, KPI reporting or any „need to look nice“ output like sales invoices or purchase orders. This goes back to the „standard topic “, even though there is a general expectation about the outcome of a „item on stock list “: something like item name, item number, quantity on stock , va...