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