S OneStopSAP
← All articles General

Gate Methodology

Published October 19, 2010

Everyone has heard the horror stories of cost overruns on SAP programmes. While there are a few factors which are outside the control of the programme managers (e.g. business change, funding withdrawn) the majority of the responsibility lies at their door.

From the programme managers viewpoint it is essential to get early warning that things are starting to slip. One of the quickest way to lose your job is to surprise your board 4 weeks from go-live with the message that the programme is 6 months late.

One of the best ways to get this early warning is through implementing a gate methodology which forces a structured review of the programme at pre-defined checkpoints along the way. In essence you build gates at the exit points of the major phases of the programme. Naturally these are also the entrance points to the next major phase.

Let's assume that you have five major phases as follows: Scope & Plan, Design, Build, Test, Go-Live. You would then have five major gates as well - each positioned at the exit point of the five phases: Gate 1 - Exit Scope & Plan, Gate 2 - Exit Design, Gate 3 - Exit Build, Gate 4 - Exit Test and Gate 5 - Go-Live. Potential criteria for each of these gates could be as follows:

Gate 1 - Exit Scope & Plan

  • Is there a scope document, and does it cover all aspects of scope including functionality requirements, modules to be implemented, geography, gaps, interfaces, organisational aspects, technical aspects, data conversion etc
  • Is there a plan, and does it include detailed tasks (nothing longer than two weeks), with resource names mapped to tasks, and is it resource balanced (no simple task)
  • Is the design team mobilised
  • Is there a design authority in place, and is the change control process agreed
  • Is the sandbox SAP system ready, and is there a client strategy document agreed

Gate 2 - Exit Design

  • Has the design been documented, including SAP transactions identified, and signed off by the business. A design walkthrough is strongly recommended.
  • Have critical areas of the design (depending on your business) been prototyped in the sandbox
  • Have all gaps and interfaces been identified, specified and estimated
  • Has the data required been identified and mapped to legacy (ignore this at your peril), and have the data conversion programmes been identified and specified at a high level
  • Have the roles required been identified
  • Have control requirements been identified
  • Has the plan been updated, and (if necessary) the scope document updated

Gate 3 - Exit Build

  • Has the system been fully built and unit tested in the development system (not the sandbox), and signed off by the business. A config walkthrough is strongly recommended.
  • Have the gaps and interfaces been fully built and unit tested (this is a grey area)
  • Have the data conversion programmes been built and unit tested (this is not a grey area)
  • Has the system gone through any scenario-based validation (a step up from unit testing). It is probably best to include this in the Design phase since you cannot be fully satisfied your requirements have been met until you run business scenarios through the system.
  • Has the configuration been fully documented, and the design documentation updated (if necessary)
  • Have the roles been built
  • Have the control requirements been built
  • Has the plan been updated, and (if necessary) the scope document updated

Gate 4 - Exit Test

  • Has the system been fully tested in the test system (not the development system), and signed off by the business. A test walkthrough is strongly recommended.
  • Have the gaps, interfaces and data conversion programmes been fully tested and signed off
  • Have the user procedures been documented and tested
  • Has the training material been completed and tested
  • Has the system been tested by running converted data through it (warning: expect to do this four or five times before it works properly)
  • Have all critical test problems been resolved.

Gate 5 - Go-Live (done a few days prior to go-live)

  • Have the users been trained
  • Are the user procedures in place
  • Is the user documentation in place
  • Did the data conversion work
  • Is the support team in place
  • Is your 'cutover control room' ready, manned 24 hrs, and have detailed cutover plans in place (this might have started already for the data conversion)
  • Have you done a trial cutover
  • Do you have a contingency plan
  • Everyone feeling well rested? Then push the button!

For the programme to actually exit the gate, you hold a gate meeting at which each team is required to demonstrate (not only verbally claim) why the feel that they have satisfied all the criteria. Pre-gate meetings will probably be required about 4 weeks out to help the teams finalise their positions. usually, but not always, post-gate meetings are required where teams resolve any issues which arose during the gate meeting itself.

Share

Cookies on OneStopSAP

We use cookies for session handling and anonymous traffic analytics. No third-party tracking, no profiling.

Privacy →