It’s not enough for SAP implementations, upgrades or migrations to hit their performance benchmarks — additionally, they need to meet the needs of all stakeholders. Unfortunately, poor SAP project management leadership can get in the way. When SAP project managers don’t get the functional and technical teams working together, or fail to engage both the ground floor and the top floor, gaps emerge in the project plan, leading to costly failures or the need for complex revisions later.
In the most extreme cases, this can lead to SAP HANA implementation failure at go live. However, more commonly, it simply results in unsatisfying results — the system performs inconsistently, breaks more than it should, and fails to deliver the SAP performance benefits the client was looking for. Here’s why strong SAP project management communication is key.
SAP Project Management Leadership
One of the trickiest things about SAP project management is finding a team with the right combination of hard and soft skills. As a practical matter, any SAP project management team will have certain SAP certifications— SAP won’t let you download and install software without them — but basic certification is not enough. Look for an SAP project management provider with a strong mentorship and continuing education program, and a team who are used to working together, and have at least a few migrations under their belt.
Your SAP project management team also needs to understand the business end of the SAP landscape. They need to understand all the steps in a transaction, the type of information that has to pass between departments, and the tasks users need to perform on a daily basis.
Finally, your SAP project management leader needs real project management experience. SAP project management is an iterative process, where steps are repeated and refined until the system has been perfected and can be safely put into production. This process only works if the leader can get everyone working together.
SAP Project Management — Coordinating Stakeholders
Any SAP project will rely on a division of labor between various specialists, and two broad teams: the functional team (who work with the partner to design a solution) and the technical team (who work out the details, assemble, and — in many cases — run it). A technical partner like Symmetry is often introduced after the client has decided on a solution with a functional provider, good communication between functional and technical providers is crucial to meeting the user’s goals.
For example, your functional team may not think about how the system connects into external applications or off-site users, such as a tax system or an outsourced financial team — they’re more concerned with developing the system than working out all the details of production. The technical team needs to be able to communicate with them to track down those details, directed by an SAP project management leader who understands the way the two groups need to interface.
SAP project management also needs to examine gaps between different client stakeholders. Executives may be interested in cutting-edge features, but not have a good grasp of how the rank and file use the system on a daily basis. Managers may be used to doing things in a certain way, and they may not be aware of inconsistencies or duplicate functionality between departments, which should be addressed during an SAP HANA migration.
Your SAP project management team needs to talk not just to senior leadership, but to stakeholders at all levels. They need the communication skills to work across hierarchy and specializations, and get everyone on the same page so that the system meets everyone’s needs. In a big corporation with a complex leadership structure, that requires a delicate touch.
SAP Project Management – Technical Execution
With the stakeholders engaged, technical architecture well understood and interdependencies documented, the technical execution of the project can proceed. However, as is the case in any major IT project management undertaking, there will be variances. As you connect the pieces together and test the system under conditions that mirror day-to-day operations, you’ll have to tweak systems and fill in details to get everything to work correctly. This is all perfectly normal — it’s why SAP project management has so many steps. But it’s also the most serious test of your project management team.
It is crucial to capture all variances in detail for every step (and every member) of the SAP implementation project. These variances should be reviewed collectively at the end of each phase of the SAP project, and your team should come to a consensus on how the next iteration should be adjusted to accommodate the changes. Regular review meetings will help ensure that resource planning is done before you need particular technical, software, and other resources. This will ensure sure that your team is prepared for each stage of the project, and ready to proceed on schedule.
SAP Project Management and Change Management
SAP project management doesn’t just have to account for filling in technical details. As your SAP implementation, upgrade, or migration is proceeding, your company is growing. It is generating new data that needs to be recorded, demand may be changing or increasing, and your company may be adding new resources into the mix, such as satellite offices that need to be looped in.
In addition to growth, your company may be changing in ways that can complicate or add new considerations to your SAP project management approach. For example, you may outsource complex business functions, adapt new software or security measures, or alter the way you handle business processes.
Your SAP project management team can plan for demand growth by carefully sizing your software for your use case, and predicting growth in demand early on — leaving a safe buffer for unexpected growth. Likewise, there are well-tested methodologies for accommodating data generated during the project.
However, accounting for other kinds of changes can be trickier, since they may require your team to either alter the project, or add additional phases afterwards. Your SAP project management team needs to maintain strong connections to stakeholders, and have a well-designed change management approach. Change management considerations, like technical execution issues, should be discussed in regular meetings, with client, technical, and functional stakeholders involved.
SAP Project Management — Continuous Support
SAP upgrades are a little like going to the dentist. If you upgrade regularly, it’s relatively easy and painless, and you can catch small issues before they become major problems. But if you put it off as long as possible, it’s going to be disruptive, painful, and expensive.
Unfortunately, many companies only start projects when SAP starts to break. They don’t watch to see if the system is reaching capacity, they don’t consult their SAP managed services provider about slowdowns and bugs during high demand, and they put off upgrades that could improve security and provide useful new functionality. This approach hurts productivity, creates security and downtime risks, and costs far more than it saves.
Retaining a technical partner for ongoing SAP Basis Managed Services helps you develop a more strategic approach to SAP project management — one where regular technical upgrades keep your system fast, stable, and responsive. The right partner will integrate regular SAP testing and planning into their ongoing SAP managed services, and work with you to schedule upgrades in a way that minimizes disruption and assures your SAP landscape always supports your needs.
SAP Project Management Is a Partnership
Your SAP landscape is the backbone of your business. Everything you do depends on it functioning properly. The right SAP project management partner will communicate with you every step of the way to ensure the project provides the most benefit, with the least possible disruption.
To learn more about choosing the right SAP project management team, download our free whitepaper, Separating the Technical from Functional: The Business Case Against Single-Sourcing Your SAP Implementation