|
New Page 1
|
Gate Methodology
Or,
get the control back!
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.
Properly implemented and
executed, a gate methodology provides and excellent early warning
system and should be looked at by every project.
Continue the 'manager'
Article Tour (3 of
5)

|
New Page 1
|
|