Blueprint? RDS don’t need no stinkin’ Blueprint

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?

Using SCRUM with ASAP

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.

  1. 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.
  2. 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).
  3. 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.
  4. Sprints need to synch with the various ASAP configuration/testing cycles (e.g., unit test, string test, etc) for the overall solution.
  5. It is critical to ensure that custom development sprints are scheduled so that the sprint output delivers to the relevant testing cycle.
  6. 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.

KM that works — ASAP for Implementation roadmap updates

As a follow-up to my ASAP and WBS features post (here), I should relay a quick KM win anecdote and give kudos to my team.  The director who leads our methodology and enablement team drove a simple, but effective, effort to incorporate the conversation from our internal social media into our external-facing methodologies.  A new set of accelerators – samples, templates, and white papers - was published based on frequency analysis of the questions and answers from internal discussions hosted on our internal SAP Corporate Portal.   

Furthermore, the team focused on available material — i.e., well-regarded accelerators already published — so we could respond efficiently and effectively.  The results of this initiative are now available in the ASAP for Implementation Roadmap and are embedded in our PMO innovation lifecycle.

  • Sample Conversion and Interface Strategy
  • Configuration Documentation Template/Sample
  • Sample Cutover Plan
  • Business Process Flow Template/Sample
  • Requirements Traceability Matrix Practice Document
  • Business Blueprint Presentation Sample
  • Authorization Definition Template/Sample
  • Knowledge Transfer Template
  • Production Support Strategy and Production Support Plan
  • Data Conversion Methods and Metrics Guideline
  • Centralized Data Management White Paper
  • Sample Test Cases
  • Integration Test Signoff Template

Updated ASAP for Implementation Roadmap — WBS features

Will executives understand this...

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?

..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.

Follow

Get every new post delivered to your Inbox.

Join 2,518 other followers

%d bloggers like this: