Project Description
Various approaches have been tried to coordinate the business and IT functions with the aim of improving the capture and management of change requirements. For example, single points of contact ‘Demand Managers’ from within the IT function or so-called ‘Hybrid Managers’ with a mix of business knowledge and IT skills. With the release of Solution Manager 7.2, SAP entered this well-trodden landscape with a collaboration tool called Requirements Management. Filling this much needed gap (so to speak), the aim of Requirements Management is to get the business and IT communicating in a structured, some might say ‘constructive’ way.
We know that requirements are defined in several ways: We have different tools at customer sites, for example there can be multiple lists as Word documents stored in folders, and there is the sending of emails from one team to another team. We also know after the capture of new requirements, there is a process of negotiation before acceptance and final delivery. There is also a broader consideration to requirements gathering and acceptance which is the combining of requirements planning with release implementation schedules.
This gets ever more complicated when 3rd party providers are involved in the process. For example, they can’t always easily share/retrieve information held on customer networks and they often have to provide cost/effort estimates to help feed the approval process, etc. Tracking these responses and understanding the current status of a Business requirement can be a real source of frustration and in the worst case, lead to the business feeling as though their requests for change are going unheard, thus breeding unhappiness with the IT dept and preventing them raising future requirements.
SAP Solution Manager provides a deceptively simple solution to this problem. A Fiori App to capture requirements, where they can be viewed online, sorted, commented on, prioritised and amended. But this tool is not merely another stand-alone application, one of many that are available that subsequently needs more effort to turn from captured requirements into commitments and delivered solutions. The My Requirements Fiori App is the easy first step that takes the requirements process on a fast-lane dedicated workflow.
Two Approaches
SAP provides two approaches to delivering Requirements Management, depending on the project circumstances: One that focuses on the collaborative exchange between business and IT during BAU activities, and one that is built into a large-scale delivery approach predicated on Agile methodology of Waves and Sprints known as Focused Build.
In both approaches, SAP have extended the venerable Change Release Management (ChaRM) in Solution Manager 7.2 with new transaction types for managing the negotiation-to acceptance-and-delivery workflow.
At a high level, on the one side with have the business, and in our best practise scenario it is composed of a Business Process Experts (BPX) and a Business Manager. The BPX is creating the requirement in the system and forwarding this information to the Business Manager. The Business Manager is responsible to validate this requirement, to check if this requirement addresses the business’s strategy.
As soon as the Business Manager has validated the requirement, it is handed over to the IT function. The IT function is represented in the best practise by a Solution Architect who will assess this requirement; performing validation and estimation of time/effort and reporting back to the business what the Go Live dates could be and what the costs behind it are. As soon as the business accepts this it is handed over to the development team to develop and implement this now approved requirement.
Each side of the conversation, Business and IT department, is represented by one specific transaction type, which acts as a virtual document. The business only works with the Business Requirement document, the IT function only works with an IT requirement document, and the developer only works with the change documents. In fact, the IT requirement could now take the place of a Request for Change (RfC) in Change Request Management (ChaRM) for delivery of minor innovations.
The business, IT requirement and the change document communication follows NINE separate inter-personal communication stages (the specifics can of course be customised to suit). :
1st Interaction: The Proposal (Business Requirement document steps 1, 2, 3, 4, 5 and 6):
BR 1. The ‘BPX’ defines the new business requirement. One of the simplest ways to do this is through the new Fiori App to capture requirements.
BR 2. As soon as the requirements definition is completed, the BPX submits the definition for validation and the Business Requirements Manager sees the requirement is their inbox.
BR 3. The Business Manager needs to check the information in this requirement request and has three options:
BR 4. Requirement can be set to ‘Handed over to IT’.
BR 5. Or can be rejected.
BR 6. Or postponed.
2nd Interaction: The Request (IT Requirement document step 1)
ITR 1.When the Business Manager sets the Business Requirement to “Handed over to IT” this creates a new IT requirement document set to the status ‘Define’
3rd Interaction: The Consultation (IT Requirement document steps 2, 3 and 4)
ITR 2. Being able to view all defined business requirements in their inbox the Requirements Manager determines who is best suited to evaluate this requirement and submits it for validation.
ITR 3. The Solution Architect (or whoever was chosen to validate the requirement) acknowledges receipt by setting the status to ‘Being checked’.
4th Interaction: The Advice (IT Requirement document steps 4, 5, 6 and 7)
ITR 4. After providing feedback on feasibility, the document is sent back to the Requirement Manager and he has three options.
ITR 5. The IT Requirements Manager can postpone a decision, pending more discussions.
ITR 6. Or they can accept.
ITR 7. Or reject.
5th Interaction: The Bid (Business Requirement document steps 7, 8 and 9)
Any one of these three options taken will immediately and automatically update the status of the Business Requirement. Included in the IT Requirement, and copied into the Business Requirement, are indications of the costs involved. The Business Manager know of the decision by the IT Requirement Manager not by looking at the IT Requirement document but instead the Business Requirement, which will have one of the three statuses:
BR 7. Committed by IT
BR 8. Rejected by IT
BR 9. Postponed by IT
6th Interaction: The Agreement (Business Requirement document step 10 and IT Requirement step 8)
BR 10. The Business Manager accepts the bid.
ITR 8. Through acceptance the IT Requirement will automatically update ‘Submitted for Implementation’.
7th Interaction: The Start (IT Requirement step 8 and Change Documents Step 1)
ITR 9. When the Solution Architect creates the scope in the IT Requirement and sets the status to ‘Implement’, a corresponding change document to the scope defined is automatically created with status ‘Created’.
8th Interaction: The End (Change Document step 5, IT Requirement step 10 and Business Requirement step 11)
When the change associated with the change document is imported into production, it automatically updates both the IT and Business Requirement documents with status ‘Implemented’.
9th Interaction: The Confirmation (Business Requirement step 12)
Finally, the Business Manager signs off the delivery of the new requirements by setting the Business Requirements to ‘Completed’.
The Focused Build approach to managing new requirements takes a very much slimmed down workflow to manage the highly structured collaborative process outlined above. The focus here is on taking the functional gaps highlighted in large implementation project scoping workshops and quickly assigning requirements to Work Packages aligned to Waves and Sprints.
- The workflow starts with a similar, though more feature rich, Fiori App to capture requirements. This can be used in fit-gap workshops. Requirements entered this way are set to status ‘Draft’.
- As part of an implementation project using SAP Activate, with a model process flow in Solution Manager from SAP’s own ‘Best Practice’ repository, the requirements documented can be assigned to the Solution Manager Business Process hierarchy to indicate gaps in the pre-delivered solution.
- On capture in status ‘Draft’, the requirements are then sent in status ‘To Be Approved’. On approval their lifecycle is associated with a Focused Build Work Package based on attributes for rank, value and effort.
There will be a more in-depth look at Focused Build in a future blog, be sure to keep an eye on our twitter so you don’t miss out.
Conclusion
Many projects struggle to centrally collate and prioritise requirements, and an easier way of capturing these was required. SAP Solution Manager 7.2 has two alternative approaches, each catering for slightly different needs.
The collaboration tool for BAU (with Business and IT requirements handled separately) keeps the requester shielded from the complexity of requirements capture, whose involvement stretches to no more than entering the idea at the end of a web link drives participation. Even so, the possibility exists to drill-down for more detail if required.
The collaboration tool is more complex in overview, but not necessarily complex for each participant where a specific and simple input is required or confirmed to move the workflow along. And unlike the Focused Build approach, it is entirely customisable, allowing more details to be added or steps to be changed.
The simpler Focused Build requirements management approach is a pre-configured solution from SAP (and cannot be adapted). It is designed for large scale implementation projects with integration into the full suite of Focused Build tooling, and specifically the Solution Readiness Dashboard which is a fantastic tool for members of the Project Management Office, allowing easy traceability of requirements through to delivery across the entire project. It is designed for large scale implementation projects where a longer workflow would be harder justify. Checking and review comes at the end of a Sprint and is an integral part of the validation exercise.
If you’d like to find out more about how Solution Manager can be used to help you manage your Requirements capture process then feel to get in touch here…
Leave A Comment