One of the first things that each software implementation project has to worry about is the general structure of the project team. We at BestXperts have tried a few different variations of project team composition over the years and can definitely attest to the fact that there is no canned project team setup that will work on every project. First of all, if you are not already familiar with standard agile project roles and responsibilities, such as Product Owner and Scrum Master, we highly recommend watching the Agile Product Ownership in a nutshell video by Henrik Kniberg. The following article from Ambysoft also provides a good overview of the agile roles in small and large project teams.
Also, if this is your first time reading one of our blog posts about implementing SAP in an agile way, we recommend taking a look at the Agile Terminology for SAP Project Teams post, that covers some of the basic terms used in this article.
One of the first things we do on any SAP implementation project is put together a baseline of features that make up the general scope of a particular release. A release it typically associated with a go-live – for example corporate headquarters going live with Human Resources (HR) and Finance (FI) modules of SAP ERP, or a particular business unit going live with an SAP Extended Warehouse Management (EWM) system. One important thing to note is that the initial list of features in a release is in no way all inclusive or frozen for changes. Most of the time, if not all of the time, new features will be added to the list as the project progresses and some of the old features will be either moved to a later release or even removed entirely from the project. This is perfectly normal and even encouraged. Since predicting the future is incredibly hard and business conditions change often and rapidly we want to embrace changed rather than discourage it. This is not to say that we are going to attempt to accomplish anything and everything that comes up as a possible feature or user story. Far from it. Part of embracing change is constantly re-evaluating the prioritization of project features and user stories and focusing on the ones that bring the most business value.
A good starting point for building a list of features for an SAP implementation project is SAP\’s Best Practices library. Once you\’ve choosen a baseline or industry-specific package that most closely represents your requirements you will be presented with a list of SAP best practice scenarios, each designated by a unique number. These can be located underTechnical > Content Library menu path. For example, under the baseline package you will be able to find scenario 112 called \”Sales Quotation\”. Generally, we try to keep our features as close to SAP best practice scenarios as possible, but there are a number of areas, for example SAP ERP Warehouse Management, where best practice scenarios are just too generic and high level to be useful, so we break those down into more meaningful list of features ourselves. The end result is a list of features that outlines the first pass at defining the overall scope of what we think we are going to accomplish in a particular project.
Once the initial feature list is put together we can start building our project team structure. Here are some general guidelines that we try to follow.
Leadership
We usually see a few leadership roles that span across multiple cross-functional sub-teams. In the context of an agile SAP implementations these roles are much less about management and are much more about leadership, which is often a source of tension in many organizations that are trying to do agile for the first time. What I mean by that is that many traditional managers are used to working in an environment where they create layers of superfluous entities (status reports, WBS structures, functional and technical specification documents, detailed tracking of estimated vs actual time) all typically under the banner of \”proper management\” and for purposes of historical reference, and then depend on \”data\” from those entities to reveal red flags in order to take some \”corrective action\”. With agile the use of such activities is greatly discouraged and many managers who are not successful leaders often struggle to find their niche within an agile project.
Project Manager aka Scrum Master
The role of an agile project manager typically boils down to:
- Facilitating the prioritization of features by working with Product Owners (key business leaders)
- Ensuring and promoting the use of agile practices within teams
- Keeping all project teams and business leaders informed of the overall progress of the project (overall communication management)
Solution Architect
We often dedicate one or two solution architects whose role is to ensure that the overall SAP implementation across sub-teams is sound and in-sync. These are typically natural leaders that have extensive technical experience across many SAP systems and modules. And even though cross-functional sub-teams often rely on solution architects to get direction in complex integration scenarios, the teams themselves still retain the responsibility of moving all of their user stories and tasks forward.
Solution architects are typically responsible for:
- Cohesiveness and robustness of the overall delivered solution for the entire project
- Integration design and testing across teams, systems and modules
Product Owner
Product owners are typically a small number of key business leaders who can make critical decisions about the need and importance of features within a particular release. They also help with prioritization of user stories to some degree, but given the volume of stories in an average SAP implementation (we see anywhere from 1000 to 5000), their involvement in prioritization at the individual story level is somewhat limited.
We can summarize product owner\’s primary objectives as:
- Identification and prioritization of features (in tandem with project manager aka Scrum Master)
- Review and acceptance of delivered solutions through a live demo (usually a batch of 15-30 user stories)
Cross-functional
This is often a source of confusion in an SAP project as the term cross-functional has historically referred to cross-module (for example SD, FI, MM, etc.) in the SAP world. However, in the context of an agile team structure for an SAP project cross-functional refers to the various functions performed by the project team – requirement gathering, configuration, development, documentation, training, etc. We typically build a number of such cross-functional sub-teams, each focused on a small number of SAP systems/modules. For example:
- Sales and Transportation team – 3 BPOs, 2 analysts, 1 developer, 1 trainer/instructional designer
- Materials and Warehouse Management team – 2 BPOs, 2 analyst, 1 developer, 1 trainer/instructional designer
The main objective is to build teams that are as self-sufficient as possible and that rarely need to step outside of their own team to accomplish a task. Don\’t get me wrong, by nature of how integrated SAP solutions are project teams will need to interact and work together on a number of requirements, but we find that anywhere between 80-90% of the work in an SAP implementation is accomplished internally within each SAP system/module, and only 10-20% falls under the cross-team \”integration\” bucket.
On smaller size SAP projects we have seen the need to share resources across multiple teams, as there is simply not enough demand to dedicate certain types of resources full-time to each team. For example, in case of SAP developers on smaller projects we have either dedicated developers to each team on a particular day of the week or used the more traditional departmental approach where all developers are part of a separate team and the incoming demand is managed by a development manager. The later approach is usually the least preferred as it makes it difficult to have developers naturally be part of the the agile process (such as daily stand ups) and promotes \”over the wall\” mentality where the ownership of a task is perceived to have been shifted as it is thrown from one team/department to another.
Self-directed
In general, each team is charged with owning and managing all of their logical units of work (features, user stories, tasks, etc.) from start to finish. That means they are responsible for gathering user stories and tasks (blueprinting), working with the business to prioritize those stories, performing the configuration and development work (realization), testing, documentation, demoing solutions and even training end-users. Ultimately, teams own all of their user stories from the time they are identified to the time they are considered done,with as little pass down of tasks between teams as possible.
All teams are expected to create their own user stories and tasks and keep their Kanban boards clean and up-to-date. There should be little to no \”traditional\” project management and oversight. Teams are expected to engage in continuous dialog with business users, prioritize their own workload and get things done.
Daily Stand-ups
One of the most crucial techniques for promoting self-directed teams is the use of daily stand-ups. These are short and focused meetings, typically at the beginning of each day, where each team member answers the following 3 questions
- What have I accomplished yesterday?
- What am I planning to accomplish today?
- Is there anything in my way that is preventing me from making progress?
Most daily stand-ups should last less than 15 minutes, as long as additional follow-up conversations are taken \”offline\” and done after the standup.
Most of the time we have each sub-team perform their own separate daily stand-ups, as we found that having a single large stand-up with all of the sub-team members present is typically not as efficient and engaging.
Team Dynamics
One of the important lessons we\’ve learned over the years is that no single cross-functional team is alike. The combination of individual personalities, strengths and weaknesses, coupled with unique requirements of each SAP implementation make it virtually impossible to apply a \”cookie cutter\” approach to building your cross-functional teams.
We expect pretty much every team to behave and perform differently. Some teams will struggle with determining a team leader. Other teams will be more likely to stray away from agile principles and require more engagement from the Scrum Master. Each individual team brings a separate set of challenges. This is where the leadership skills of Scrum Master and Solution Architects play a critical role in filling in the necessary gaps and helping each team achieve its utmost potential. The important take away point is that instead of fighting the diversity of teams and expecting all of your teams to behave and perform exactly the same, you should accept and embrace their differences.
