What value a Proof of Concept

[boobboo]

As I wrote in a previous post, I was not able to run a PoC of an  MDMP  Unicode Migration. So I want to explore the value of a PoC and  find out  how other Technical consultants view it.

Just  to be clear about  what I mean when I say PoC of a Technical Upgrade  project, it is a  copy of Production less than 6 months old which is in a  similar  environment to Production. These points are important as the  PoC, in my  view, has to accomplish several aims.

1. Provide a clear  indication of what  functionality the upgrade will 'break' after the  upgrade has finished.

This is hugely important as it allows your   developers and functional consultants a 1st time view of what work  needs  to be done.

By giving them this view,  they can plan any  functional changes easily, for example if the client  has a customised  business process which is now SAP standard. The  functional consultant  can plan a revert to standard.

2. To highlight areas of concern  for the  technical team.

Because the technical  team are  providing most of the heavy lifting during the Go-Live weekend  - we  have to be aware of where the problems lie. The PoC provides a  clear  view as to where these problems are, we can then either fix them  so  they do not re-occur or we can fix them in place and then plan for  the  same error in future executions.

3.  To validate the scope of the  project.

Sometimes  the client has not fully taken into account  how the upgrade will affect  their Enterprise Architecture when they  have gone out to tender. By  validating the core business processes with  the business and the functional  consultants, the project team can  validate or invalidate many of the  assumptions made by both parties  during the tender process.

Similarly sometimes the client has  picked  the wrong thing to do, either they are addressing their issue in  the  wrong way - perhaps an upgrade is not the right thing to do, it  might be  better to re-implement.

4. Provide the client with a  sense of  momentum.

Projects can be slow to start  sometimes, and  seeing a technical team sourcing and providing systems  straight away  gives the client a feeling that things are happening,  rather than  watching a lot of functional consultants attend workshops  were the  output will not be tested for weeks. (I am not dismissing the  valuable  work my functional colleagues do in anyway.)

5. Make the client  see a customised  upgrade process from the first button press.

It  is easy to spend the first 2 to 3 weeks reading every SAP note  and  manual, having a massive checklist of things to go through, but  this is  wasteful of a consultant's time and the client's money. By using  a PoC  we are able to execute a reasonably 'vanilla' upgrade and begin   customising an upgrade process from the first button press. The first   few days are spent reading the major SAP notes and manuals for the very   obvious issues and applying experience of previous upgrades to the   process. This will yield a reasonable list of actions, then we can start   the upgrade - where we will hit more issues than we have in our list.   These issues will be fixed and added to the process, which will be   refiend with every further upgrade - until the client has a fully   customised upgrade process.

But what  about the reasons for not  doing a PoC upgrade, I have not heard of many  but here is a selection  of them and why I think they are poor reasons.

1. There is no  time to do the PoC

As we have said above the PoC allows the   whole project team to see how the upgraded version sits with both   customer data and business processes, by doing this critical decisions   can be made without affecting the to-be landscape.

2. The budget  does not allow for it

It is my experience that not having a PoC   often leads to additional costs for two reasons -

A. Because  architectural decisions have be  made in DEV, often this means it needs  refreshed post-project to bring  it in line with the eventual decisions  made in the project.

B. Processes have not had time to  integrate  within the project team during upgrade execution, so often  there is a  requirement to run a second dry-run before go-live.

3. We do not  have enough hardware for the  PoC

SAP mandate that there needs to  be a minimum of 2 systems in order to support an SAP application, so in  order to run an Upgrade project there needs to be more hardware  available, so plan accordingly.

Often an upgrade project utilises  new hardware to take advantage  of both higher performance (often  required for the new application) and  the ability to reduce the SAP  hardware estate.

Even if a migration to new kit is not involved  in the project, there should be an expectation set early in the  process  that an upgrade is a hardware intensive process.

So if anyone  has any views similar or perhaps different to my own, leave a comment so  we can discuss.