Introduction:
Focused Build is a ready-to-run and integrated, tool-supported methodology to manage requirements and software development in large, agile projects, provided by SAP as a part of Focused solutions.
It is a project management tool which can be used from requirement to deploy, especially innovation project such as S/4 HANA Conversion project and it can play a key role in that. It consists of requirement management, process management, change management, test management and release management, everything closely integrated.
Ready-to-run means we need to activate the different functionalities only once and later we can use it without any additional coding or customization.
Integrated means that all the functionalities and steps for the project management in Focused Build are on the single tool and it has its own mechanism, hence we don't need any external tool to support project management in Focused Build.
What Focused Build Provides?:
- Transparency
- Accountability
- Standardization
- Effectivity
Benefits and Features of Focused Build:
- Ready to run tool for Agile Methodology
- Integrated tool to manage requirement and software deployment in large
- Save effort and shorten duration for controlled rollout projects.
- No additional coding required
- Enables the tracking of project from Requirement to Deploy
- Ready to use project plans with predefined work breakdown structure
What is included in Focused Build?
Why Focused Build?
Using standard SAP Solution Manager Application and functionalities for Project Management for Requirement to Deploy scenario will need us to configure all the functionalities one by one and then customize it and then integrate it for our use, which is like cooking our own meal.
Whereas using Focused Build, which is a ready-to-use and integrated tool, for our project management is like going to restaurant and ordering our meal and enjoy dining, without any hassle.
Why Customers love to run their projects with Focused Build?
- Focused Build bridges Business and IT view
- Saves effort and shorten duration for controlled rollout projects
- Clear project status with business process context
- Seamless Solution Documentation handover to operation.
Why Project Managers love to run their projects with Focused Build ?
- Fulfilling all business process requirements in time and budget
- Starting with Best Practices
- Immediately available tool for standardized and agile processes
- Transparency on current project status
- Efficient processes by reduced efforts
Focused Build Configuration:
Please go through the Focused Build Configuration guide.
https://help.sap.com/doc/59abbad28d5343f38faff834d641ecaa/210/en-US/FocusedBuild_ConfigGuide.pdf
Security Guide for Focused Build:
https://help.sap.com/doc/3250ae223eb941f58b1f0ec2714151f9/240/en-US/FocusedBuild_SecurityGuide.pdf
Different roles in Focused Build:
- PMO - PMO are Project Managers who are responsible for creating projects, defining the dead lines of the projects, categorizing the tasks, defining the sprints, waves, approving the requirements, etc.
- Architect - Architects are further classified as Business Analyst, Technical Architect and Developer. Business Analyst- They define the process, create a requirement in system. Technical Architect- They create Work Item and Work Package based on the requirement and assign developer. Developer- It is who actually works on the changes that needs to be made via the work item.
- Test Management- It involves Test Manager(who create, edits, and manages the Test Plan), Tester ( who perform the testing).
- Release Management- Release Management are mostly the Basis Admin team who are responsible for moving and importing the changes via the release cycle.
Roles and Respective responsibilities in Focused Build:
Focused Build Architecture and Integration Model:
High Level Flow in Focused Build (Based on above diagram):
The figure above shows the high-level overview of the end-to-end process as delivered with
Focused Build. The discovery team starts with a discovery workshop, during which you define
the process model and application landscape. Very importantly, you also capture
requirements and gaps, and in doing so, define the scope of your project. From the requirement you create work packages and then assign the work packages to build teams.
These can be on-site teams or remote teams that you subcontract for your project.
In the Focused Build approach, these teams are called Remote Factories.
Build the solution: Once you have assigned the build team, a development architect slices the
work packages up into work items and then assigns the developers. Now the development
process runs according to the status schema that is also delivered as part of Focused Build.
At all times, the work progress is documented and tracked in the so-called solution readiness
dashboard.
Execute testing and manage defects: After the build is finished with a successful unit test, the
developers release their work items and the resulting changes are automatically transported
into the quality assurance system. This is where the testers execute single functional tests,
functional integration tests, user acceptance tests, and regression tests. Of course, a fully
integrated test plan, as well as reporting dashboards for the test suite, is part of the solution
as well. During the testing activities, defects found by testers are corrected by the developers
responsible.
Release management and transition to operations: When you want to import a release into the
production environment, you have to pass the quality gate (Q-Gate) build-to-deploy. This
means that the release manager can validate the release and deploy it. All the tasks necessary
to complete the Q-Gate and, eventually, to close the project successfully are part of a preconfigured work breakdown structure (WBS), which is also part of the delivery. After go-live, the build team remains available to manage the hyper-care phase with the operations team. This transition to operations and support is prepared all along the build phase as the WBS contains tasks that have to be delivered in all phases.
Few Terms in above architecture and integration model:
- Wave - A wave comprises a well-defined functional scope of work packages to define what needs to be done. Wave is assigned at work package level. For simple understanding, work package is similar to Request for Change in CHARM and Work item is similar to change document in CHARM.
- Sprint - A sprint comprises a well-defined scope of work items to define how to do it. Sprint is assigned at work item level.
- Work Package - Work package are like the change request which are created after requirement is approved by change manager in a project. Based on the complexity and demand of the requirement, the requirements are categorized and work packages are created.
- Work Item - Work item are one where actual development takes place. In FB, there are two types of work item, one is Normal Change, which is transportable and other is General Change which is non-transportable. In SP11, for enhancement projects, Normal Change, Urgent Change and Standard changes are available. For fix projects, Urgent change and standard change are available.
- Milestone - Milestones are specific dates in a project plan, deliverables should be available at. They are maintained in waves and sprints and focus on major progress points which must be reached to achieve success, e.g. availability of the functional or technical design documents, test cases etc. The milestones are used as default due dates in the Work Packages and Work Items as soon they are assigned to the Wave or Sprint. In the Work Package and Work Items the due dates can be adjusted individually.
- Q-Gate - Quality gates are check points that are scheduled during the handover from one project phase or wave to the next with a clearly defined due date. All project stakeholders review the deliverables of the q-gate by formally checking their availability (e.g. are all deliverables available, are all test successfully executes), and deciding collaboratively whether the project can move into the next phase or wave.
In FB, there are three kinds of projects:
- Master Project
- Build Project
- Single Project
We will talk about the first two kinds.
Master and Build projects have parent and child relationship, where Master is parent and Build is child. n- Build projects can be assigned to a Master project. master projects can be created separately as well as along with build project. To monitor project in FB via live dashboard, we must have a master project. The dashboard will have dropdown of the projects created in FB, but the dropdown will have entries of only Master projects. To track build projects, we need to scroll down and click on the build project assigned to master project.
Solution Readiness Dashboard (FB Project Dashboard):
Dashboard- Main or Master Project:
Dashboard- Build Project:
To know more about Solution Readiness Dashboard, you can go through my blog "Solution Readiness Dashboard in Focused Build in Detail"
https://blogs.sap.com/2022/11/12/solution-readiness-dashboard-in-focused-build-in-detail/
To learn more about Project Management using Focused Build in SAP Solution Manager:
Streamline Project Management with Focused Build in SAP Solution Manager | SAP Blogs
Conclusion:
Focused Build can be key player in innovation projects like S/4 HANA Conversion projects and due its benefits as mentioned above, it is so widely popular among all the customers. It brings transparency, accountability, standardization and effectivity in projects. With this we can track the progress of project at the smallest level, we can track our estimated time, effort and cost of a project. We can assign and categorize the tasks of a project at team member level.
So, go and explore this amazing product my SAP under SAP Solution Manager.
It will definitely help you in project management.
All the best and cheers !
- SAP Managed Tags:
4 Comments
