5 tips to successfully carry out software projects

In a global market environment, companies have to constantly adapt to new circumstances in order to remain competitive. This results in new requirements for internal processes, but also for the existing system landscape. Companies are faced with the challenge of closing the gap between technical knowledge and technical understanding, especially when technical changes are necessary. Problems with communication between the specialist and IT departments are often pre-programmed.

So how can you deal with this challenge and ensure that business applications solutions achieve satisfactory results for everyone involved?

The 5 Tips:

1.      Form the project core team

Content: Especially in software projects, the list of stakeholders can quickly become very long due to the relevance for numerous specialist and IT areas. It therefore makes sense to identify main contacts from the different departments involved in the implementation of the project. Ideally, these are people who have a broad professional and technical understanding (regardless of whether they work for the business or IT side) and ideally have a certain self-interest that the project will be implemented successfully. These can be included in the project core team and are a single point of contact (SPOC) for their respective team as well as for the project. This bundles information flows and reduces communication problems,

Recommendation: In the kick-off meetings, discuss who is suitable from the different areas as SPOC and clarify exactly what you expect from the involvement and the necessary time investment. In any case, the manager of the person should be taken on board. In the course of the project, it is also advisable to hold status meetings with the core team (e.g. weekly status JF) to keep the core team up to date so that the SPOCS can pass on information to their team.

2.      Appoint change ambassador

Content: The change ambassador can be defined as a supplement to the SPOC. The change ambassador represents a department that is affected by the software project but is not directly involved in the implementation. In many software projects, the affected departments are involved at the beginning of the project as part of the definition of requirements, e.g. via interviews, but then they do not notice much of the implementation as the project progresses and can have little influence on it. In the worst case, if requirements were misinterpreted, this only becomes apparent after the go-live. He can syndicate the implementation status with his team and, if necessary, take countermeasures during the project. This ensures that the end result actually meets the technical requirements and is also accepted.

Recommendation: Similar to the SPOC, care should be taken with the change ambassador that he has a ready professional and technical understanding and, above all, that he is convinced that the software project is meaningful. If it is difficult to identify a suitable person, this is an indication that communication measures are necessary for the department early on in the project in order to either clear up questions or even revise the project objectives.

3.      Plan realistically for Business Applications Solutions

Content: The standard challenge of every project is to plan realistically. In software projects, there are many unknown variables that can lead to a delay in the project. In the first step, it makes sense to visualize possible stumbling blocks for the specific project. To do this, the context in which the project is taking place should be considered and asked about what can lead to problems and how these can be included in the planning. One approach:

Company: Each project is embedded in the actual core business of the company and possibly other projects. Are milestones planned outside of the project that have an impact? Are there any resource conflicts?

Persons: Are all the necessary capacities for project implementation available? In particular, it should be considered here that one person is available in each area at all times.

Project: In which project phases can problems be anticipated? For this purpose, short interviews can be conducted with the responsible departments in order to draw on empirical values. The most critical phases are typically the testing phase and production deployment.

Recommendation: Always plan the project phases generously so that there is room for follow-up work. In the test phase there are often problems with test readiness (e.g. due to missing data, access or deployments) and in the preparation of the go-live (e.g. due to differences between the test and production environment or firewall releases), so plan here in particular buffer on. There are also certain preventive measures that you can take care of. For example, create a vacation plan to have an overview of whether foreseeable core resource bottlenecks will arise. In addition, there should be a substitute regulation so that there are no significant project delays even in the event of unforeseeable absences (e.g. illness).

4. Demo-based focus group feedback

Content: The course of each project is set within the framework of the definition of requirements. Documented requirements are always an interpretation of the statements made by the requester; error-free acceptance can only be ensured through repeated feedback loops. In projects, contact with the requester often breaks off after the initial requirements have been recorded, which greatly increases the risk of having an unsatisfactory result after the implementation packages have been completed. Consultations should therefore take place throughout the course of the project, e.g. with the change ambassadors in order to be able to incorporate feedback into the development process.

Recommendation: Several loops should be carried out with the requester while the requirements are being recorded in order to ensure that the requirements packages are recorded and documented correctly. An additional, very useful means of ensuring the correct implementation of the requirements later in the project are demos of the first software drafts. To do this, arrange dedicated demo appointments with the development team as part of the deployment of the first software packages on the test environment, in which a developer presents the intermediate results to the project core team and one or more requesters (change ambassador if necessary). It does not explicitly have to be an end result, but should serve to

5.      Communication to “Those Affected”

Content: The success of a software project is not only measured by the quality of the functions provided, but above all by the marketing of the added value that a new solution brings with it. The best software solution is useless without awareness and acceptance in the departments that are ultimately supposed to work with the software. Therefore, a change management concept with appropriate communication measures is so important to take relevant stakeholders with you during the project and to enable the smoothest possible takeover of the new processes at the end of the project. As a rule, software projects are primarily unpleasant for people who are not directly involved. Either new processes are added to the existing ones (more work) or existing processes are replaced (different type of work). In both cases you have to adapt and in the end you might have “no other choice”. Everyone would like to be picked up individually, but for most software projects this is simply not affordable for capacity reasons. In addition, the expectations of a software solution can differ greatly, so it is essential to convey which problems the software solves and which not!

Recommendation: Put yourself in the needs and, if necessary, concerns of the users of the new software solution. Ask individual people about this and show your appreciation for employees, no matter how justified or seemingly unjustified the objections may be. When it comes to communication measures, personal contact options are always preferable, e.g. departmental meetings or at least online Q&A sessions. Impersonal measures such as e-mailings or intranet posts help to transmit information in a structured way, but do not support the necessary dialogue with employees. In the communication, also make it clear what the steps will be after the go-live. Are training courses offered? Are further releases with new functions planned? For such and other queries, you can also use a contact point (e.g.

Conclusion

With the right preparation and a keen eye for the stumbling blocks of a software project, the biggest problems can be avoided! What is particularly important here is understanding and empathy for the stakeholders involved, regardless of whether it is a software vendor, in-house IT or the specialist department. If communication works well at these interfaces and everyone speaks the same language, there is (almost) nothing standing in the way of a successful software project!