Introducing Software? It’s Best Done Lean

Lean führt es sich am besten ein

You’ve just come out of a meeting, and after a successful evaluation, you’ve got the task of introducing new software into your company. Is this your first time doing so? Thoughts and questions may be gathering in your head. How can I best go about this? What pitfalls can I avoid? Which departments do I begin with? Will all staff accept it? Question after question.

Do it the agile way

More and more development projects are being operated under lean and agile management methods in the world today. These methods create incremental and iterative improvements in production and recognize the importance that cost efficiency, time-saving, and the ability to respond quickly to changing requirements hold for ever more companies and markets. Why, then, shouldn’t software be iteratively introduced? The integration of a cross-departmental tool into a company doesn’t need to be planned out to the minutest detail. It can be done step-by-step, steering clear of high financial expenditure and the headaches that come with it, and avoiding staff getting overwhelmed with unfamiliar, overarching process descriptions that take months to implement.

With nearly 40 years of experience in manufacturing integrated software for requirements engineering and project management, we can provide a roadmap for a lean and quick introduction of a new tool.

Lean software introduction

Start small

It’s often the case that high investment costs initially create an uneasy feeling. It’s only natural when you don’t know the software down to the last detail. You might also be unsure about what support and cooperation the manufacturer of the product may provide.

Our tip: rent the required licenses for a set period, such as one year. This way you avoid making the wrong purchase at an unnecessarily large expense. You also get the time needed to evaluate whether or not the software is the right fit for your project’s and process’ needs. Additionally, through the installation support or training, you can assess the quality of service provided and decide whether or not you can develop a long-term and trusted partnership.

Focus the pain

It takes countless weeks until the details of exactly how one works with new software are compiled into a comprehensive process description.

Our tip: We know from practical experience that a process description can undergo many changes along the way because a new tool can change or even eliminate the need for existing processes. Rather than trying to start by composing a full, all-inclusive process description that describes every little workflow, it’s better to create a list of prioritized subjects and focus on the biggest ‘pain’ that the new tool can help deal with.

Minimum Viable Product (MVP)

With its variety of functions, integrated software that covers most areas of a company can often be overwhelming. Attempts to ‘drill’ a new integrated software into a workforce through a week-long training session tend to have the opposite effect to what was intended and make the acceptance and adaption of the new tool even more difficult.

Our tip: Make it lean! In the context of lean management, the term ‘minimum viable product’ (MVP) is often used. When introducing a new tool, MVP limits functions to a minimum by making them group-specific or role-specific. Additionally, after a precise discussion of the tool with a coach, training should only last a few hours. Employees will get familiarized with the functions relevant for their respective roles and won’t be overloaded with information they can later learn step-by-step.

Let’s start the sprint

Companies often introduce everything with a ‘big bang’. Within a short period, employees are expected to map processes with a new tool whose functions they are not yet familiar with.

Our tip: The limited training and functionality create a focus for employees. Within the first days and weeks, experience shows that it is very easy for employees to get started with the tool. Eventually, questions begin arising over the tool’s further functional possibilities. Then it’s time for a retrospective.

Feedback needed

In many cases, after the software is bought and set up, the users are left alone after initial training. It’s assumed that they accept and adapt to what’s in front of them.

Our tip: It’s very important to receive and react to the feedback given by your staff. They should have the opportunity to describe their experiences with the tool, share criticism and make suggestions for improvement. This way, staff feel like their opinions are valued, and can also make potentially significant suggestions for improvement. This is also an important step for the acceptance of the tool.

Optimize and extend

After a retrospective, you’ll know what features of the software need changing or improving. This usually goes hand-in-hand with a request for the software manufacturer to make the necessary adjustments.

Our tip: Make sure you introduce a highly customizable tool. This way your customization requests will be easily implemented. Now you can expand the functional areas and offer more in the software interface. After their initial familiarization period, your staff will also be ready to learn the new functions.


It’s often the case that after the configuration of the tool, staff then explore and try out the new possibilities.

Our tip: Offer your staff a short and focused retraining session that teaches them the new functions and possibilities. These often prove fruitful, allowing employees to build on the knowledge already gained and pose questions that initially wouldn’t have occurred to them. This promotes curiosity and enthusiasm where uncertainty and overloading might have existed.

New areas of the software can then be explored by those not yet familiarized with them and implemented throughout all departments.

Introducing a new software is a large responsibility, however, it can be over-planned.

We recommend not to spend too much time in over-detailed preparation. Make a decision and just go for it – preferably with a cooperative software producer who has years of experience in tool implementation.

Stefanie Kuke received a doctorate in chemistry, but after university she immediately began working in communications. A certified tekom technical editor, she was previously active in the analytics sector. As part of the microTOOL public relations team, she contributes blog articles, gives webinars and publishes articles about other interesting topics in project management and software development.

EN Subscribe to our newsletter
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *