Every organization is different, every software anyway. That said, we believe that a clear procedural model will stand any selection and onboarding project in good stead.
We divide our process model for software implementation into four phases: Requirements phase, selection phase, introduction phase and establishment phase.
Software selection is only one part of a successful software launch. Set broader, so that the new software optimally supports the project landscape and users. How pronounced the individual phases are also depends decisively on the PM maturity level of your organization.
In this phase, you lay the groundwork: clarify the requirements for software implementation, especially the expected benefits. In requirements workshops you collect the business requirements, which you later translate into technical requirements. If necessary, methods, processes, or organizational issues can be addressed here and should be clarified prior to selection. Finally, this phase ends with a clearly described, agreed and prioritized requirements definition.
Products found via market research or market study can often be pre-filtered based on key requirements. After the call for tenders and the vendor presentations, there are usually one or two candidates left, who are put under the microscope by all the stakeholders in more detailed test settings. Are also licensing costs, SLA, etc. clarified, nothing stands in the way of an informed selection decision.
The selection of suitable software is a necessary but not sufficient prerequisite for successful implementation. A big bang is usually not useful. Implementation planning and the right choice of pilot projects is therefore important. Gradually put the software into operation and use the individual roll-out steps for a critical evaluation and possible adjustments. The end of the implementation phase marks the end of the selection and implementation project and the official discharge of the project team.
To ensure that the software is used continuously, the PMO collects feedback and "deburrs" the new processes and tools. The new solution is measured against the benefits demanded at the outset. Especially in the first period, the need for training and especially support in the running operation is high.
A new software changes many things: processes, information channels, opportunities to exert influence. All of the above phases need to be managed from a change management perspective. This includes, for example, discursive approaches to requirements elicitation, transparent and comprehensible selection, and – within the bounds of possibility – the greatest possible flexibility during introduction. This aspect is therefore by no means a marginal issue, it should be inherent in every single step of the implementation project. This is the only way that people, method and technology fit together in the end.
Really test – not just install
Ensure that as many future users as possible are actively working with the software during the test phase. A clear test program with good moderation helps against sprawling test positions or sporadic clicking around.
Select suitable pilot projects
Invest time in choosing suitable pilot projects: Not too small, so that the software is used extensively. Not too complex or with too much time pressure, so that there is time to learn the new software. Ideally with open users.
© 2022 Mey Mark Meyer / prometicon project management