Skip to Content
Author's profile photo Ramesh Babu Nagarajan

BBP phase – Can it be Avoided or Compressed?

In this blog I am specifically going to talk about a variety SAP project in which I feel that the necessity of BBP phase can be called into question.

Recently I was part of a project that can be described partially as SAP instance consolidation and partially a greenfield implementation as it had both. Like a typical SAP project we went the through all the phases starting from Business Blue-printing, Design, Realization etc. But hind-sight tells me that the BBP phase has not been of any great value as the goal of the project was to move from SAP 4.7 instance to ECC 6.0 which is already existing with minimal business process change. While the greenfield part of the project does require BBP, but it was a small portion and I feel it could have been handled as part of Design phase itself.

I see the following are some of the important outcomes of a BBP phase

  1. Clients business processes are throughly reviewed, analysed and documented?
  2. As-Is and To-be business processes are documented and proposed/reviewed and frozen.
  3. In-efficiencies in the existing business processes are identified and acted upon for removal in the To-Be process
  4. Obsolete requirements are identified and the relevant aspects are eliminated in the To-Be process
  5. Identify and ensure that all stake-holders are part of BBP and their views are discussed, reviewed and appropriate action is taken on special requirements
  6. Prepare a platform for successful business stake-holder participation right through the project

So if BBP is not there, the major issue will be missing of points 5 & 6. Can these two be achieved in the design phase itself. My experience says that it can be achieved by having appropriate planning of the design phase involving a sort of business process review as a first activity.

Since the goal of the project is to keep the As-Is & To-Be process same with zero to minimum change, elaborate BBP phase running into 8 to 10 weeks to cover all the areas of project was not at all required. A compressed BBP phase spanning to say 2 weeks would have been ideal as there is a bit of greenfield implementation is there in the project scope.

What are the risks of such compressed BBP?

  1. Not enough time for detailed study of the the As-Is process
  2. Increases the probability of surprises later in the project which can turn out to be a drag on timely completion of project
  3. Existing in-efficiencies may continue in the new system too

While these risks are valid, but I think these can be mitigated in the design phase by focussing & achieving enhanced business key-user participation in the project. My experience has always been that the more the key user participation is achieved in the solutionizing phase, easier becomes UAT and sign-off 

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Luke Marson
      Luke Marson
      Hi Ramesh,

      This is an interesting perspective. I have to say that in all the projects I have worked on without a full or adequate blueprint have been extremely difficult and unncessarily time consuming. Clear, defined requirements, confirmation of scope and delegation of the scoped tasks to team members cannot be done without a well-prepared blueprint document.

      Sure, in your case for a "simple" upgrade it might not be required, but generally even then I would want some form of (blueprint) documentation to specify what the client is getting in the final outcome of the project. If the processes aren't changing then this document can be minimal and, as you say, produced in just a few weeks.

      BUT, I see clear value in a blueprinting phase and a blueprint document and will continue to be involved in these phases.

      Best regards,


      Author's profile photo Ramesh Babu Nagarajan
      Ramesh Babu Nagarajan
      Blog Post Author
      Thanks Luke for your comment.

      I do agree with your point the BBP plays a very important role, but based on the specific project types we must look at the value addtion it will give to the project and whether the time & effort it entails is really productive or the same time & effort will be better utilized in other phases of the project.

      Author's profile photo Former Member
      Former Member
      Hi, Ramesh,

      I agree with your cost/benefit perspective on blueprinting.
      I would always recommend to do some kind of E2E-process-work to avoid the 'infamous' IT/business disconnect and facilitate the organizational framework of the project (Communication, Change mgmt, Steering meetings etc.). E2E-type value chain scenarios also helped me to categorize integration issues & design integration tests.

      Functional blueprints (e.g. on pricing, invoice verification etc.) may have less benefits to justify their detailed elaborations. Prototyping-based alternatives may have a better business case especially in non-greenfield projects.


      Author's profile photo Ramesh Babu Nagarajan
      Ramesh Babu Nagarajan
      Blog Post Author
      Thx Harald for your comments.

      As I had explained in the blog, given the context of the project the length BBP phase has to be decided. Just having a normal BBP without looking into the value it is going to give the project is something that needs to questioned and studiously decided upon.


      Author's profile photo Former Member
      Former Member
      BBP phase...  Is it needed?  Well I'm a developer.  I shouldn't need to know the big picture so for me it should be easy to say the BBP should be avoided.  But do I?

      No on ANY project a BBP should be done.  The easier the project the less time it will take.  When doing an upgrade - what are the new technologies that we can use instead of our custom code?  In a small project - agreed upon requirements.  That is the first and probably most important step..  The UAT should be based upon the requirements.  I'm not saying that good BBPs will fix everything.  They won't.  There is still a human element.

      If a BBP was done at all levels - during all projects.  You already have your As-is document going into the project.  That will save you a lot of time.  It will just be a check to make sure the end user is still doing things the way the requirement document says they are.

      If a BBP wasn't done, you have to revisit the same requirement over and over.

      Can the timeline of the BBP be compressed?  It should be sometimes we plan so long that we lose sight of what we were trying to do in the first place.  Too many "what-ifs" will stop a project from ever going live.  Not enough "what-ifs" will lead to problems during testing or worse case - during go-live.

      So - I'll agree compress those timelines.  I'll disagree - I don't think it can ever be avoided.  Not even at the lowest level.  The program.



      Author's profile photo Ramesh Babu Nagarajan
      Ramesh Babu Nagarajan
      Blog Post Author
      Thx Michelle for your comments.

      With the iterative process of managing project, the risks we associate with not doing a detailed BBP can be mitigated. My experience strongly points that having an extended BBP phase results in lot of un-important requirements getting added while the real ones come later during the design and UAT phase by when we find such requirements cannot be wished away as the business process will not work without them. So the length of BBP phase must be studiously decided based on the nature of the project.