Deliver incremental values and respond to changes with SAP Commerce Cloud Project Framework
Most SAP Commerce Cloud solutions share similarities in their base processes and concepts. However, a commerce solution’s main value is in how it differentiates itself from the competition. Typically, this differentiation leads to unique internal processes, and a different set of associated applications in a given IT landscape. Additionally, organizations need to keep up with technology which is constantly evolving, as well as consumers, who are constantly demanding more from organizations who are competing to satisfy them.
During the lifecycle of an SAP Commerce Cloud solution, there are various types of projects, starting with the initial implementation project. The goal of this project is to define the requirements for the solution, build the solution to meet the requirements, and then deploy the solution to the production environment where it’s accessible to the end users. This initial implementation can take the form of:
-
- a ‘replatform’ project. This is where you’re replacing an existing solution.
-
- a ‘greenfield’ project. This is where there is no existing solution and you’re starting from scratch.
Table of Contents
SAP Commerce Cloud Projects from Different Perspectives
Technology Perspective
An SAP Commerce Cloud solution consists of a set of modules and extensions. You build your unique e-commerce solution through a series of customizations and configurations on top of SAP Commerce Cloud. Furthermore, in order to keep your e-commerce solution up to date, you’ll have to regularly:
-
- Upgrade the platform and selected modules to the latest released version.
-
- Migrate specific solution modules, data model in database and business data.
Both Implementations and Upgrades are delivered in a project environment. This article focuses on the project framework for implementation. In the near future, we will have articles covering the upgrade topics.
People Perspective
Every business is different; they have different requirements, different ways of working, different standards, different internal governance processes, and more. Additionally, there are many different approaches and methodologies to delivering implementation and upgrade projects, each with their advantages and disadvantages. The ‘right’ approach is different depending on the project context.
No two projects will ever be the same. Therefore, they will need to be managed differently. The scope, size, and duration of these projects will also vary significantly from project-to-project and business-to-business. Some projects are so large with so many dependencies and work-streams, they often need to be managed as programs. Others, however, are fairly small and self-contained.
There is a commonality, however, how all these projects hang together along with a set of practices that can be applied. Together these form the Project Delivery Framework.
Project Delivery Framework Fundamentals
There are a set of fundamental principles and practices that need to be understood for an SAP Commerce Cloud project before going into the detail of how each phase works. These are important across all phases.
Variable Scope
Variable scope means that features can easily be swapped in or out, and focus will be on delivering the highest value features first, leaving the lowest value features to later. It also means that contingency is planned around the features, not the time or the cost. If the unexpected occurs, some low-value features can be deferred to the next release. This ensures the current release is delivered on time, on budget, and with high quality.
Time-Boxing
Time-boxing ensures that time control is baked into everyone’s mindset from day one. It’s important that nothing is allowed to extend outside its time frame. Ultimately, this naturally ensures that all the project activities are delivered on time, and therefore increases the likelihood of a successful project.
Iterative Development (Sprints)
The Realize phase consists of iterations called sprints. This is a Scrum term meaning mini analysis, design, build, and test activity cycles that are typically fixed at 2-3 week durations. The duration is set at the start of the project and is then fixed/time-boxed for every sprint and only changed in very exceptional cases.
Just-in-Time Requirements Analysis
It’s important that requirements are only estimated at a high level early in the project, then elaborated and defined in more granularity only when needed as the project progresses. Because change is inevitable, it’s wasted effort to analyze everything in detail up-front.
Iterative Documentation
Just because an Agile approach is being used, it doesn’t mean that there are no functional requirements, technical design specifications or sign-off process. Rather than being completed up-front then updated throughout the project with change requests, they are completed iteratively using a just-in-time approach during the project.
Acceptance Criteria
Acceptance criteria are specified for both functional and non-functional requirements. These are agreed and signed off by the customer. The functional acceptance criteria are defined and signed off sprint-by-sprint. The non-functional acceptance criteria are defined and signed off during the Explore phase, then amended through change control during the Realize phase if needed. These acceptance criteria are then used as the basis for the customer’s user acceptance testing.
Lightweight Change Control
Using an Agile approach that allows for flexible requirements during an ongoing project enables change to be embraced rather than resisted. Therefore, a lightweight change control process is permitted rather than the typical rigorous change control process seen with fixed-scope projects. Scope changes can be verbally agreed with the project team, usually with the Project Manager.
Quality Baked-in
All testing activities must be identified from the start, responsibilities assigned and planned alongside all other critical path activities. These will cover all aspects of testing including functional, non-functional, exploratory, system integration, cross-browser, and cross-device testing.
Empowered Customer Representatives
Fast, effective and efficient collaboration and decision-making are essential to the success of the project. Because requirements are elaborated just-in-time, there is a high level of communication required at all stages of the project.
Cross-Functional Collaboration
Cross-functional collaboration is expected through the streams; project management, business, technical and quality management. Each of these streams has a corresponding owner on the project team and the customer side. This improves communication with the customer and underlines the importance of each of these perspectives.
Continuous Improvements
Retrospectives are a vital part of the project and occur at the end of every sprint, release, and project. This process of continuous improvement becomes embedded in the mindsets of the whole project team. Not only does this improve the ways of working but is also very motivational as it empowers the team to make positive change.
Creative Design
Often there is a separate organization or design team responsible for designing and creating the user experience and creative designs for the user interfaces. The project team is responsible for taking these designs and integrating them with the back-end development to meet the overall requirements.
In these cases, it’s essential that the three key parties (customer, design team and project team) collaborate from the start and throughout the project. There are tight dependencies between the designs and the implementation, along with trade-offs regarding features and effort.
Transparent Reporting
It’s essential that these real-time progress reports be shared with the customer and that the customer is educated so they can fully understand them. This builds trust from the start and avoids surprises later. If something is going off track early, it’s far better to tackle this together with the customer at the first signs, than hiding and hoping it improves. Trust is an essential part to the success of the project.
Delivering SAP Commerce Cloud Projects with SAP Activate
Project Phases
The project delivery framework for SAP Commerce Cloud has been adapted and aligned with SAP Activate Methodology. Each of the phases is summarized for quick reference purposes. The five phases and high-level stream view is presented below.
-
- Prepare Phase – The where, why, how, and what of the project, including scoping, architecture, planning and costs.
-
- Explore and Realize Phases – The building of the solution, whether iteratively (for example, Sprints) or broken down into sequential design, build, and test sub-phases.
-
- Deploy Phase – The preparation and delivery of the solution into the live production environment.
-
- Run – This starts with the first deployment to production. It is a continuous work stream providing support and live operations management.
Stream View
Deliverables Per Phase
| Phase | Deliverable |
|---|---|
| Prepare | Initial proposal |
| Explore | Prioritized Requirements List (Backlog) Project Plan Solution Architecture Definition Non-functional Requirements Quality Assurance Definition Project Management Definition |
| Realize | Software Package (Release Notes) |
| Deploy | Go-live Checklist |
Releases and Iteration
A large project is often broken down into slices or increments called a ‘release’. The size of a release can vary depending on the context. An example would be breaking down a 12-month project into 2-4 smaller releases of relatively equal duration, with each release containing all the project phases.
The set of sequential phases would then start again with the next release. The initial up-front phase that assesses the project feasibility, business case, high-level scoping, and more, is often not required as the outputs of the previous Prepare phase are still valid.
Smaller releases can help to reduce project risk, improve time to market and give more immediate visibility to the business and end users. However, they need to be balanced with the overheads involved when starting and ending each release.
Conclusion
During any software development, there will always be complexity and uncertainty that customers and delivery teams must manage. This cannot be entirely eliminated but can be significantly reduced by developing on a stable software platform such as the SAP Commerce Cloud. The remaining complexity and uncertainty can be managed by using an appropriate methodology. There is no one-size-fits-all method for successful software development. The ‘right’ approach is to select the appropriate method given the project context, and sometimes by taking a blend of different methods. The key is being appropriately skilled and experienced to understand the different options and how best to apply them.
