The key to get a high quality of the development in the production system is to make it just slow enough to encourage the testing and administration worth it.
That is.
The faster the changes can travel from development to production. The higher is the risk that the change is contaminated with an error.
The slower the changes have to travel from development to production, the higher is the chance that it has been thoroughly tested.
What is then slow enough? Once a week, once a month or maybe even twice per year.
It actually does not matter as long as the customer sees the quality and effort put in to the tests, rather than getting the fix into production at once. It must be better to test and find issues in the production system and fix it already there, before it is even entered into the production system.
The recepie for slowness is:
- Bring a large chunk of development into a release
- Take a decent time of test
- Add good amount of time for preparations
- Then finally, finish it of with a go live
The Tests will hopefully result in finding many smaller bugs and corrected as soon as possible (included in the same release). The preparations is when we adjust documentations, instructions, training material etc. The go live is all the activities needed to make sure the change is fully working. Importing a transport. Updating documents etc.
How do we then achieve this?
We will structure the maintenance development in cycles.
Plan the cycles in advance and communicate which dates you can put changes into production.
Perform Change Management meetings with customer to:
- prioritize the changes that are to be developed in the next cycle
- check off which changes that have been developed and tested and are ready for production
- plan which cycles that should be used for applying support packages
- plan which cycles that should be used to apply enhancement packages
The number of weeks per cycle is very customer oriented. Depending on the maternity of the solution it might also change over the lifecycle.
But. To start off I would recommend with a release cycle of three plus eight weeks.
In one year you can then have six cycles (leaving four weeks of codefreeze for summer vacation or period end closing.
With six cycles you also have 30 weeks of development and 6 weeks of tests.
What bad examples are there?
I have seen many different options of setting up system landscapes to support the change management. But one of the least good options is the Maintenance system approach.
At one customer they had a separate system to perform critical changes in. And then they had to retro fit those changes back to the development system.
This approach introduces so any new risks than it actually solves. If the need of having a maintenance system where you can correct bugs fast you most sure have other issues with your development which you should focus on first.
This blog is a part of my series of good change management within SAP.
http://scn.sap.com/community/it-management/alm/solution-manager/blog/2013/08/21/common-mistakes-in-c...
