Project Description
The Realization Phase
This is the second of three blogs on how SAP Focused Build can transform your approach to SAP programme delivery. The first blog covered easy requirements capture, the re-invention of documentation in Solution Manager, and project planning with an Agile twist. This blog continues the story to introduce how Focused Build is used to break work into work packages and work items, ensuring minimum documentation, and tracking successes in a dashboard for project managers.
The Realization phase is where Focused Build takes the requirements captured in the preceding Explore phase and helps manage project delivery from development to final integration and acceptance testing.
There are four major activities driven by Focused Build in this phase:
- Assigning requirements to work packages for delivery through state-transition workflows.
- Managing development activities through controlled scoping and transport creation.
- Monitoring of the progress of the project following the Solution Readiness Dashboard.
- Testing using the test management capabilities of Focused Build.
The realization phase is often considered the place where the rubber meets the road, where progress can get mired down and great efforts need made to put things back on track. Focused Build can help forestall these issues but before we show how it is worth itemising the common problems all large scale implementations face and determine that a new approach, with new tools, is needed.
- Managers must work hard to get a clear picture of progress. Much time is spent collating information. Each team lead will set aside a portion of their hours to progress reporting, the PMO office will spend time collating results, the project manager will have to chase up missing reports.
- Documentation follows the laws of entropy and tends to travel in the direction of disorder and incompleteness as if driven by some universal force. Much effort must be expended to halt this decline, such as with governance procedures or diligent time spent correcting inconsistencies. Many on project team members consider proper documentation a sunk cost, of benefit to only those who come after go-live in support roles. This lack of professionalism is often a problem for the customer.
- Keeping on track of one or two transports is never going to be a problem. The problem comes with scale, and inefficient control mechanisms can be overwhelmed on larger projects, creating intolerable delays and frustration.
Requirements realized through work packages and workitems
It is the job of the Solution Architect to work with the requirements document creator (usually a Business Analyst role) to package up the requirements into work packages. It is not necessary for a single requirement to be answered 1:1 with a work package. It may be the case that a requirement has been broadly defined and needs to be broken down into several work packages. A requirement should be an Agile methodology “user story”, a single expectation delivered to someone with defined value, such “As a purchaser, I want to be able to pick view the release status of the orders I’ve raised”. To help in this mapping, work packages can be given a preceding or succeeding sequencing in the order attempted. Conversely, several requirements may be defined at a granular level such that they all could be sensibly wrapped up into just one work package.
Whatever the starting point for deciding the requirements to be delivered by a work package, the work package is a unit of work with an associated Single Functional Test Case (SFTC) indicating when passed that it has been delivered successfully. This SFTC is a document stored as a part of the Test Management component in the Solution Documentation, assigned to a business process step.
All the requirements will have the opportunity to be linked to the BPML (Business Process Master List) in Solution Documentation and therefore it seems sensible to consider a work package to be related to a single business process step – although this only a suggestion and not a restriction. As a Focused Build process ideally needs the Solution Documentation process hierarchy to exist it is therefore of capital importance that an outline business process structure is in place before exiting the Explore phase.
Storage of the necessary albeit minimum supporting documentation depends on this structure being established. As a concession to usability, uploading and managing the completeness of the document can be done entirely from inside the Focused Build work package. This is important not just for the SFTC document but all other documents necessary to complete a Focused Build work package. Which documents are necessary is determined by the classification of the work package (Fit, Gap, WRICEF – the same classification optionally indicated in the requirements. These terms were defined in the section on the Explore phase (in brief: a “Fit” is configuration; WRICEF is development; and a “Gap” is a development performed by a 3rd party but still needing to be documented and integration tested. In general, developments (WRICEFs and Gaps) also require a Functional Specification, and Fits require only updating of the configuration guide.
In short, Focused Build helps you divide your project’s scope of requirements into manageable chunks; it masks the complexity of navigating the process hierarchy and allows resulting documentation to be stored in the correct place in the BPML without additional governance.
The work package completion workflow actually comprises of two separate “state-transition” workflows, semi-automated team collaboration around an electronic document by transitioning the document status as it is completed.
The Document KPI workflow. Each status change of the work package examines the availability and readiness of the supporting documentation, the documents themselves having to be in the correct released status before the next phase. This sequence of document availability and completeness is illustrated opposite in a simplified form, first for WRICEF and Gap development, and then for Fit (config only). Each document must be available (status IN PROGRESS) and then completed (status RELEASED) for the work package/work items to transition through its own workflow status changes. With Focused Build creating the right level of documentation is integral to progressing the build activities. This workflow is called Document KPI because the documentation and their completeness are one of the underlying metrics used to track progress in the Solution Readiness Dashboard (see later). Each document can be considered a “mini milestone” for completion of a work package. Making correct documentation front and centre of a development activity is a classic quality management technique. Each step of the process involves a handover, and Document KPI workflow ensures the next step can’t be performed until the pre-requisite step is completed first. Hardly an original idea, but one that can often be overlooked.
The Change Document workflow: This is used to progress completeness of workitems. Workitems can be categorised and as Normal Changes (NC) or General Changes (GC). The difference between them is that Normal Changes are used for transports through the entire landscape, whereas General Changes can be used to update documentation or make changes to non-transportable objects. There can be any number of workitems of type NC or CG created to realize a work package, the term scoping is used to describe the job of determining how many and of which type.
Both of the above workflows produce key metrics for the Solution Readiness Dashboard (more on this below) providing real-time project status reporting for the Project Management team.
In the previous blog the Focused Build units of time (waves and sprints) were introduced as project planning terms. Earlier in this blog the units of work (work packages and workitems) were explained. The next section describes how these two concepts are related.
- Starting from the top, an implementation programme will have one or more releases. Each release is served by a master project, but this master project can be split up into multiple sub-projects. Release can run in parallel, but only if each release has a different transport path. This is a relevant consideration for hybrid cloud/on-premise implementations.
- Before go-live, each release will have a Functional Integration Test (FIT) of all the sub-projects in that master project release.
- The sub-projects would normally be divided among functional areas, and each expected to be no less than 2 months in duration. This sub-division is not mandatory but is a good starting point for consideration.
- Each project will have multiple waves. The conclusion of each wave is a Quality Gate with an Acceptance Test where developers present the changes and new features to the requesters and key users. As a wave is made up of individual work packages, each with their own SFT, the alignment of wave and work package to business process and business process step is an obvious one, although again there is nothing that prevents flexibility here.
- As mentioned earlier, each work package is broken down into work items, for example a WRICEF development, a functional configuration or a change not needing a transport request. Within a wave, the workitems are planned as sprints typically no more than 10 days in length, and can be scheduled to maximise productivity, so long as they completed by the due date of the wave. Each sprint is confirmed by a Unit Test. All these points demonstrate Focused Build is aligned to the principles of Agile Methodology: flexibility to cope with changing scope, extending scopes, new requirements. It does this by providing a methodology to deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. It makes working software is the primary measure of progress. It encourages the business and developers to attempt continuous delivery of software.
The Solution Readiness Dashboard is the go-to report for monitoring the progress of a release. The SRD is an interactive report with each tile displaying a different key metric. Each tile can be drilled down to list summarised data. As each master project has exactly one release, displaying the master project therefore summarises all sub projects (all business areas for example). This gives a global overview of the entire programme. In addition, each sub-project can be managed separately, ideally focused for workstream leads.
The two state-transition workflows, Document KPI and Change Documents, are used to monitor progress in the bar chart tiles of the SRD. This gives an absolute, solid measurement of progress. If a work package is due development, then the functional specification must be released. If a development is due testing, then the workitem must be set to “To be tested”. Also displayed in the SRD are risks and issues. Risks are defined as a potential problem which requires mitigation planning, whereas issues are having an existing impact and require resolution
Overall status – Project status a traffic light gives an instant visual signal to context of the rest of the matrix. It is set manually, for master projects by the project manager, and if the sub-projects are broken down by workstream then functional team leads can take responsibility for it.
Next Q-Gate – The number of workdays remaining until the next Q-Gate, much better than a date as a countdown always creates a sense of urgency.
Total numbers assigned to project – with drill-down to individual documents. This gives an at-a-glance figure, and easy navigation access to the detail.
Requirements backlog – How many work packages are still open, which ones are in progress, and how many have been rejected? Again, an at-a-glance figure, and easy navigation access to the detail. The project scope is the backlog ma d reducing this is a key metric of performance.
Schedule – How many tasks in the current project are complete in relation to their due date (to-date target)? This tile gives percentages, useful ready-made summarised hard data for communication to the steering committee.
Current Wave Progress – shows the percentage difference between actual and planned completion. Again, useful ready-made summarised hard data for communication to the steering committee
Risks – Number of risks rated according to status, impact, and probability. Risks are defined as a potential problem which requires mitigation planning
Issues – Number of issues rated according to priority. Issues are having an existing impact and require resolution.
Scope change – Percentage of work package that has been changed or extended after the initial scope had been set. A key metric for quality. Can give an early warning sign of problems ahead.
Sub-project statuses – Status per sub-project indicating which documents or activities are behind schedule (overdue) The two state-transition workflows, Document KPI and Change Documents, are used to monitor progress in the bar chart tiles of the SRD. This gives an absolute, solid measurement of progress. If a work package is due development, then the functional specification must be released. If a development is due testing, then the workitem must be set to “To be tested”. There is no hiding place from these metrics.
Summary
Focused Build provides attractive-to-use and simple-to-run tools to address the problems seen in many implementations. Getting a clear picture of overall progress is supplied by the Solution Readiness Dashboard. Ensuring accurate and complete documentation is ensure by the Document KPI workflow. And controlling large scale development efforts is aligned to the work package/work item workflows that integrate with transport control processes.
In the next blog, we will look at how we can use these tools to test our developments and deploy our releases.
If you’d like to understand how Focused Build can help make your S/4 implementation project successful contact us now to arrange a no-obligation, hassle free demo.
Leave A Comment