Introduction
After delivering the DESIGN of a global greenfield SAP S/4HANA business transformation in 2020 – under heavy impact by the pandemic – we have compiled a list of “real life” make-it or break-it topics you need to consider when running a large-scale innovation program. Here is Part 2, focusing on fundamentals during the pandemic.
6. Project Methodology – Remote and Agile
We experienced that it is crucial to properly blend any outside implementation framework (PMI, SAP Activate, SAFe, others…) with your own company’s project management framework and in-house accelerators. Software development frameworks that follow the Agile principles, promote continuous deployment of validated features through iterations. Topics to consider, when mixing Agile and Waterfall during remote work, are:
- Methodology: Do not adopt any outside methodology as a fact => rather blend your own company methodology with outside implementation frameworks such as PMI, SAP Activate, SAFe and others.
- Quality/CSV: Consider Quality Assurance requirements such as CSV (computer system validation) and mobilize/include the QA/CSV team as partners early on.
- End-to-end: Develop an end-to-end mindset by defining end-to-end scenarios and business owners at the beginning of your transformation program. Organize the teams and all activities within the program (define, design, build, test and rollout readiness) around those.
- Training: Plan for additional time/training/coaching for the project team to absorb the methodology while WFH (working from home). Ensure everyone understands the program/project objectives, ways of working, understands his/her role within a multifunctional team and is empowered to make decisions. Remote training can still take place in groups and in an interactive way. Get an agile coach as needed, define super users for each of the tools being used and schedule virtual walk-in sessions.
- Remote work: Consider key success factors for remote work and adjust your methodology. (e.g. Sprint duration, Sprint participants, Sprint preparation, lessons learned) => please contact us for detailed lessons learned on working successfully as virtual teams: info@avoras.com
7. End-To-End Business Scenarios during Design Sprints
Organizations that truly understand their end-to-end business processes will be more innovative, lean, and agile. An end-to-end process structure ensures that all business resources align to achieve a common and holistic objective, to create and sustain a healthy business model.
End-to-end is typically a cross-functional process that comprises all the steps to accomplish a specific goal. End-to-end processes:
- Encompass the entire value chain;
- Focus on the customer’s value;
- Categorize processes based on value.
- Define End-to-End Business Process Owners
Structuring the solution design and build along end-to-end scenarios is key for realizing business value early on. In addition, parallelizing Design, Build and Test enables the organization to familiarize itself with the Sprint modus operandi and obtain and incorporate immediate feedback.
8. Adjust your Validation Plan
In heavily regulated industries, such as pharmaceuticals, GxP is a collection of quality standards to assure safety and efficacy of products for the patient by assuring high quality of e.g. laboratory, manufacturing or other processes. IT systems used to support such processes must undergo Computer System Validation (CSV).
Some of our clients are skeptical or not convinced about the compatibility of Agile ERP system implementation and the documentation required for Computer System Validation (CSV). There are several approaches to adjust classical waterfall to the agile principles and still collect all required documentation, should you and your stakeholders decide to go Agile.
- Waterfall development – Assumes that every requirement can be identified before design and build occurs. There is a long time since the collection of user requirements to the final user acceptance of the solution with no space for short feedback loops and adjustments. Even if the end users were heavily involved into signing-off the initial user requirements, the requirements may have changed by the time the solution goes live.
- Agile development – The goal is to have short iterations (sprints) including detailing requirements, design, build and test, happening to a great extent concurrently. The key to make agile development compatible with CSV is to define your testing strategy and infrastructure (sandbox, development, quality and productive environments) in a way that supports it, including unit testing and informal testing during the sprints and less frequent periods of time for formal testing and documentation (validation before product release). Test automation also becomes very important to prepare the system for frequent updates.
Before creating any CSV relevant documentation (user requirement specification, functional, specification, configuration guide, etc.), it is important that the team understands the training and guidelines provided by the quality assurance team. From our experience we recommend early training to clearly include how we ensure traceability from requirements to functional specifications to test scripts with the tools/templates used within the project. A proper template for each deliverable, with incorporated guidelines, should be available.
9. Communication during Pandemic
Communicate proactively and even more frequently than usual in a working from home and/or remote work environment. It is pivotal to ensure the message is clear and understood by the audience, especially in a remote work environment, where we have a blend of cultures and time zones.
We have experienced communicating in a virtual setup, taking advantage of different tools not only to share information but also to collect feedback and collaborate. Here’s the list of the point we identify as success factors:
- Take the sprint retrospective seriously and use the lessons learned to improve the next sprints;
- Avoid additional workload, and allow for consolidation of information at top level, by using a common template for the sessions (e.g. same template for Sprint retrospective sessions across the different teams, same agile board structure across the teams to facilitate the scrum of scrums);
- Use the sprint review ceremonies to communicate the team achievements to key stakeholders and review priorities as needed;
- Schedule periodic report out sessions for a broader group of end-users. Leverage as much as possible the materials created during the sprint review;
- Define a communication SPOC within each team, responsible as well to foster a continuous Improvement (CI) mindset within the team and ensure the lessons learned are applied.
10. Governance – PMO Office and SPOC (single point of contact)
When designing the project organization we consider three principles:
- Close alignment between cross-functions and workstream
- Reduce bottlenecks
- Resolve impediments faster
Especially under the agile frameworks, the PMO has an enabling role. Its purpose is to resolve impediments that may me preventing the team to create results in the most efficient way. The alignment between workstreams and the PMO and other cross functions (integration, testing, QA, etc.) needs to be tight.
Our experience says that identifying different SPOCs works very well, increasing productivity and saving costs. It does not need to be the same person all the time (the team lead or a scrum master): you can have a SPOC for training, a SPOC for testing, etc. in each of the workstreams.
What’s Next?
Digital business transformation can be intimidating and complex. We can change your experience in what technology investments can do for your business and provide you with peace of mind and confidence when facing difficult decisions in a constantly changing environment. Get in touch with us for details on any topics above. We are happy to share information for your project’s success: info@avoras.com.
Check out part 1 here.
