If introducing new project management software ends up requiring its own software then your organization is probably about to melt down. Let’s just assume that you have to choose from all sorts of solutions – from free open source tools for basic collaboration tasks to paid deluxe packages – and somehow you have managed to find your dream software. What do you do next? And can something still go wrong once you try to introduce the software? Of course it can! Fortunately we have some tips for you on how to go about introducing your software.
Running into a gun fight without cover
There are still some who proclaim that digitization is a topic reserved only for the top management (in German only). That does not have to be true. You need to plan the introduction of your software semi-independently from the management. Otherwise you or a different project leader will end up suffering the consequences of hasty decisions. And who would want that once the first unavoidable small or large problems in the project begin to emerge?
Change Management 0.5: Halfhearted software deployment
It should go without saying that the introduction of software is a project in its own right. It requires its own efficient project management system – solid planning, thorough preparation, substantiated knowledge and agility in the execution phase. That is what a smooth transition will require, as described here. This does happen, but most of the time companies tend to choose a more tumultuous approach – one which involves high overheads and a hard test of resolve on the part of customers.
That will be your destiny if you don’t take the project seriously enough. That will happen if you have not been able to concisely identify the process goals, if managers underestimate costs by casually assuming they’ll magically get it right.
But if that happens it may not be so bad. What’s the worst that can happen? The IT team will have to work crazy hours for a few months, eventually causing the project management to crumble, sooner or later the day-to-day business will suffer and all the users will become weary and start to search for alternative solutions.
Project organization: Take the role seriously
An almost inexhaustible source for errors can be found in human resources. If you can you should try to ignore the group’s morale – at the end of the day, you can’t really pay attention to every intern’s panic attacks. Besides, it’s common knowledge that staff members feverishly desire rapid change in companies. Acceptance is a foregone conclusion. Resistance is not an issue. Remember: software deplyoments have little to no effect on the political dynamics in a team, right?
The entire company is probably already supportive of the project. Would you like things to be more challenging? Then staff the project incorrectly and forget to include key stakeholders or bury the project lead in a massive workload – really, go nuts. Below you will find a few more classic pieces of advice guaranteed to make your project experience smooth and successful.
Forget the kids
Don’t waste unnecessary time integrating relevant professionals from the departments in the selection or deployment processes. Instead, placate them with vague platitudes – using the template for project management bullshit bingo – and then present them with immovable decisions while you shamelessly exaggerate the software’s performance capabilities. Repeat this approach with external groups. You will quickly find out that this will have an impact on the acceptance levels in the entire project.
Mix up the project roles
Found a project team! Then go ahead and put staff members in the team who have grudges against each other. Put someone in charge who is in-experienced and who has no talent for organization. Make sure the roles are not clearly defined – in this way the execution will be plagued by countless tweaks without the risk of ever approaching a solution. If things really start to go wrong then bring in an outside help to put out some fires. This individual should never transfer their knowledge to the company – instead they should become indispensable to the business operations for an indefinite period of time.
Call for a change in staffing and then ignore the documentation process
For advanced readers: Wait for the project leaders to reach the brink of burn out because they have been busy with introducing the software. Then hand off the project to a completely different staff member. The resulting effect is particularly impressive if you have you neglected to cultivate any documentation process. The new person can look forward to starting from zero – especially because her predecessor is too exhausted to be of any help. If you are particularly lucky, the old project lead will become a consultant who may also become indispensable in the company.
Simplify the communication and project culture
Only give your staff enough information to make them hungry enough to starve to death with outstretched arms. We also recommend burdening a staff member with too much work or assigning a task to too few staff members such that they never actually can cope. Discuss these two options at length in never-ending tedious meetings. Those are also useful for completely decimating the last of your team’s motivation.
Deplyoing complex, new software (sometimes across the entire company) almost never results in changes in workflow. So there is no reason to critically question processes or to connect them with sensible (new) developments for the software introduction. So just ignore the organizational aspects in the planning phase – especially if they pertain to the core parts of your business) and only pay attention to them when it’s almost certainly too late.
The Big Bang vs. Iteration – Put all your eggs in one basket
Researchers are still not sure exactly how the big bang took place. Why a software rollout can fail spectacularly is easy to explain though: insufficient change management principles, unforgivable mess-ups during the selection and installation of the software, false expectations, deficient requirements management, unending changes based on insufficient compatibility with the existing system, counter-productive configurations, apocalyptic interface scenarios, cataclysmic transfers of base data etc. – the list goes on and on. The best option would be to take on the full risk and never even consider an iterative rollout process! Pilot projects, mid-way evaluations, process analyses and risks limitations are archaic concepts that have no place in project management.
So you executed complex projects in the 90s using Excel and now you are a completely invincible filter ninja and hardened pivot table samurai. Or even better: you have an app on your smartphone now that allows you to coordinate grocery shopping with your partner, and it’s working “really well”? You should definitely not simply throw all your expertise over board. Make sure to exert pressure when choosing software and do everything possible to cause your favorite option to win. This approach is solution oriented and associated with much less work than laboriously comparing software providers or painstakingly composing complicated requirements specifications and other requirements descriptions or creating long-winded cost-benefit analyses. By the way, these things will not be needed later on in the software rollout process so they shouldn’t receive much consideration.
Go ahead, do it all yourself
If this is your first software rollout then you should definitely avoid the help of experts who, at the end of the day, are expensive and do double the work in a third of the time, or something like that. It’s much better to keep a handful of colleagues close to you so that you can over-work them. That is what naturally happens in complex user scenarios (which you are guaranteed to have – otherwise you wouldn’t need project management software) when they are compared with software solutions with the purpose of maintaining congruence and functionality. But don’t worry, even if you do nothing else for a few months, you will have obtained a good overview of everything – while sticking to the budget. At least until you have to start paying the running costs.
Skimp where you can – especially on training seminars
Generally it is recommended to plan the budget with little or no wiggle room. Specialists depend on “agile” solutions like acquiring a smaller number of expensive licenses than is required by the users. After all, everyone won’t be working on the program all at the same time, so your colleagues can decide amongst themselves who will be using which license and when.
Another completely unnecessary cost would be training seminars. If a software package has a six figure price tag it would be naïve to spend another few hundred Euros on a user workshop. Your colleagues are smart, they’ll pick it up quickly – the manual only has 800 pages. If the team works together they can read all that in no time.
Skip the tests and go live immediately
The advantages of this approach are patent to see. Just press the “button” when things are busy around the office and get started. We also recommend allowing administrators or other key figures to go on holiday on D day. That keeps things exciting when you finally go live. We hope you enjoy the show.
More informative, creative blog posts by Andreas Anding and his colleagues can be found at http://www.mds.eu/blog (German only).