Posted on February 4, 2012 by Paul Ritchie
Strong SAP SDN post by Mark Chaffen on SAP RDS (Rapid Deployment Solutions) and the case of the missing Blueprint. I’ve only started to dig in to the topic, so these are my (likely half-baked) first thoughts:
- On balance “no Blueprint” is good. Its exclusion reinforces that a RDS implementation is of a fixed, limited scope. There must always be some sort of scope statement, of course, and its there. Unfortunately, “Blueprint” seems to equal “everything and the kitchen sink” in some SI’s SAP glossaries! Wise to make a clean break in the lexicon.
- Avoid Death by Change Order. RDS is designed to deliver only what one needs to execute — the wish list comes later. Only fill in regulatory, statutory, or other compliance gaps during the initial implementation; otherwise make a conscious decision to remaining requirements into backlogs that get burned down release-by-release.
- RDS still too “new solution” oriented. There are other ways to expand a SAP footprint… how about RDS for acquisitions, divestitures, or other growth/transformation scenarios?
Filed under: PMO | Tagged: ASAP, Dennis Howlett, Mark Chaffen, RDS, SAP | Leave a comment »
Posted on March 30, 2009 by Paul Ritchie
Ron Stanton sent me a mail asking how SCRUM works with our implementation methodology — ASAP for Implementation. While SAP does have a SCRUM methodology that we use — SAPScrum — it is an internal approach used for solution development. SAPScrum is pretty straight SCRUM, so there’s no mystery to it.
We just started a project to make ASAP more agile-friendly, we’re a little ways from publishing it. For now, below are a few general guidelines in using SCRUM in an ASAP environment.
- The first principle is to remember that the SAP solution(s) serves as the development platform or environment. It isn’t simply an application to which you’re integrating.
- Of course, a product backlog should be one of the outputs of the Blueprint phase. The product backlog should be mapped to the processes here (as part of identifying testing scenarios).
- Appropriate prioritization of the backlog is critical in an SAP environment. In particular, non-technical product owners often forget to include integration dependencies as one of the prioritization criteria.
- Sprints need to synch with the various ASAP configuration/testing cycles (e.g., unit test, string test, etc) for the overall solution.
- It is critical to ensure that custom development sprints are scheduled so that the sprint output delivers to the relevant testing cycle.
- Most ASAP config/testing cycles are typically 2-4 weeks long, so one sprint:one config/test cycle is reasonable. If the project is especially large — with longer config/test cycles — then consider nesting sprints within those longer cycles.
Filed under: Methodology, SAP | Tagged: agile, ASAP, ASAP for Implementation, SCRUM | 4 Comments »
Posted on July 14, 2008 by Paul Ritchie
Will executives understand this WBS?
Back to business after a few less-than-serious posts…. The latest ASAP for Implementation roadmap (overview page here, NOTE: requires registration to service.sap.com) was recently updated to include consistent alignment and presentation of WBS elements. The latest version of the roadmap is the culmination of several years of effort to harmonize the ASAP methodology’s treatment of outputs/deliverables (what to do) and methods (how to do things) with industry standards, especially the PMBOK Guide.
..or this one?
We also place much more emphasis, in the roadmap and in our training, on using the work breakdown structure as a communications tool. While the WBS should organize and define the total scope of the project — thereby forming the basis for schedules, budgets, and resource plans — it should be a tool to communicate to a wide variety of stakeholders. It is essential to have both graphical and list views available. In particular, the WBS should not be a way of overwhelming senior management with detail. It should make transparent to all what will delivered and the work required to do so.
Filed under: Communications, Complexity, Methodology, Paul Ritchie, Program Management, Project Management, SAP, Scope Management | Tagged: ASAP, ASAP for Implementation, WBS, Work breakdown structure | 3 Comments »