Many
employers roll out new software on the step-by-step basis, but can firms
co-ordinate a ‘big bang’ approach? Keith Rodgers reports on how one company
managed the latter approach
Anyone involved in a major enterprise software rollout in the late 1980s or
1990s could be forgiven for thinking twice about embarking on a large-scale IT
project today. Disaster stories abound of projects that missed deadlines,
overran on budget, failed to deliver to expectation, or in many cases, suffered
from all three malaises. The successes that became vendors’ marketing
references have often been overshadowed by the high-profile failures.
Combined with today’s harsh economic environment, those memories have led
many organisations to adopt a step-by-step approach to software implementation.
Rather than spending years preparing to install systems and then going live in
one ‘big bang’, there is a strong school of thought that argues in favour of
keeping projects manageable.
‘Project creep’ – the process by which implementations accumulate more and
more tasks and objectives as they roll out – is far easier to control if you’re
overseeing a series of two-month long initiatives rather than a two-year long
programme.
Spending can also be more easily controlled on smaller scale projects where
parameters can be tightly set.
And the need for flexibility – crucial today, when companies need to adapt
to changing business conditions faster than ever before – means organisations
want to spend less time installing software and more time using it to create
value.
Throw in the fact that few organisations can afford a 1990s-style
enterprise-wide rollout right now, and it is easy to see why the emphasis is
falling on tactical initiatives that deliver a fast, measurable return.
Not everyone, however, is going down the incremental route. CVS Pharmacy, a
US drug store chain with more than 4,000 outlets and 100,000 employees, spent
29 months and in excess of $5.5m (£3.58m) preparing for a simultaneous launch
of three enterprise-level HR modules.
Forced to justify both the upfront expenditure and accumulated costs during
the course of the project, the HRIT team went through exhaustive processes to
establish the most effective way forward. Its decision to opt for the big bang
approach reinforces the opinion of market watchers such as AMR Research – that
while there’s much to be said for piecemeal rollouts, in many instances there’s
still a strong business case in favour of one-step implementation.
Monica Barron, senior analyst at AMR, suggests that are several typical
drivers that push an organisation down the big bang route.
In many instances, companies will have multiple HR and payroll legacy
systems. If they phase in new software incrementally, they will have to build,
test and maintain a whole range of temporary interfaces between these different
systems during the implementation process – interfaces that become redundant as
soon as the new application is fully installed. In addition, organisations are
keen to see the benefits of software installation as quickly as possible, so a
big bang approach offers advantages in terms of speed.
But there are other, more prosaic reasons for taking this route.
"The other thing I see, and something affected by the spending environment
today, is that users are afraid that if they don’t get it in at once, they
might not get the funding in later years," says Barron.
With the exception of that last point, several of Barron’s arguments applied
to CVS. From the outset, the HRIT team knew it had a major project on its
hands. The company had been facing up to the prospect of spending $3m (£1.95m)
simply to re-engineer its existing mainframe technology to provide a platform
for ongoing growth – $3m that would effectively deliver the same functionality
– and HRIT successfully argued that it was better to invest a higher total sum
in return for a new, more flexible system.
CVS fuelled that argument by finding a limited amount of hard savings,
primarily through automating processes and shaving a small amount off
headcount. It also pointed to soft savings at the store level. If it could
reduce the amount of time store managers spent working on HR administrative
tasks such as payroll, for example, it could direct a higher number of chargeable
hours to their top priority – dealing with customers.
Having won the investment argument, CVS turned to the issue of how best to
roll out the three Peoplesoft modules it had decided to implement – HR, payroll
and benefits administration.
The company already had a centralised IT shop, with one mainframe-based
system handling all the processing for its 100,000 employees, while all HR data
entry was carried out in the corporate office. Although it didn’t have a wide
range of disparate systems to manage, it would still have needed to carry out
temporary integration and customisation work to keep a combination of old and
new systems working together during a phased approach.
Mike Howson, manager of HR technology at CVS, says the organisation looked
in detail at three other options.
The first was to roll out one module at a time, beginning with the HR
system, and then moving on to payroll and benefits administration.
One of the problems with this approach was that CVS already did pay
calculation and benefits administration in-house through its core legacy
system. Taking the phased approach would therefore have required it to
customise Peoplesoft’s ‘base benefits’ modules (part of the HR application, the
first to be implemented), and subsequently remove them when it implemented the
benefits admin application. It would also have had to invest a sizeable amount
of resource in the initial rollout phase building an interface to the payroll
system – work that would have been obsolete as soon as the Peoplesoft payroll
system was implemented.
As Howson remarks, while this kind of approach was safer, it would have
eaten up more time and money, and the full benefit of implementing the new
system would not have been realised until all three modules had been installed.
The second approach would have been to phase the rollout by employee,
installing all three modules simultaneously for different groups of users over
a period of three to four months. However, this too would have required more
work.
According to Howson, the conversion process would have been more detailed,
and the company would have had to build a central reporting hub to consolidate
data from the new and old systems during transition – another costly project
that would have been dismantled on completion, once all the reports could be
handled by the Peoplesoft system. While this approach was quicker than the
first, the reporting hub would have had limited capabilities and the
requirement to dismantle it post-implementation was not attractive.
The final approach considered by the CVS team was a combination of the first
two, phasing by module and employee group. While this ensured that the company
would have enjoyed the benefits of both phased approaches, it would also have
been lumbered with the downsides.
Ultimately, therefore, the big bang approach proved to be both faster and
cheaper – albeit more risky. Howson points out, however, that this approach
would not be suitable for every user – decentralised organisations may be
better off adopting the ‘phase by employee’ approach.
AMR’s Barron agrees, particularly in instances where operating units have a
lot of autonomy in making their IT infrastructure decisions. She also suggests
the step-by-step approach may be more suitable in other specific environments.
Organisations implementing new, relatively untested software would usually
be better off taking a phased approach, rather than going with a big bang
rollout and discovering, for example, that the software wasn’t sufficiently
scalable.
Political considerations may also play a part – if HR rollouts involve major
cultural issues or extensive changes to business processes, it may be necessary
to prove the concept step-by-step to both end-users and senior management.
That’s especially true if the rollout involves new technology – such as moving
to web-based applications – or if it changes the way trans- actions are carried
out and affects individuals’ roles, for example, the introduction of employee
and manager self-service.
The CVS implementation, demonstrates, however, that big bang can work in the
right circumstances. Although the system was installed three months late and
$500,000 (£325,241) over budget, for a project of this size that kind of
slippage is deemed to be a relative success.
Tips for managing large software rollouts
Monica Barron, senior analyst at AMR
Research, suggests that users opting for the big bang approach should take into
account four key issues:
– Understand the full change management implications,
particularly where business processes will be affected
– Communicate effectively with end-users and be aware of their
issues, however small – eg if you’re moving from a mainframe to web-based
systems you may discover some users don’t know how to use a mouse
– Test rigorously – particularly in high visibility
applications such as payroll
– Pay attention to training needs. "I’ve seen a number of
projects where training was given short shrift or not considered at all,"
Barron says. "As a result the project was disastrous"
Mike Howson, manager of HR technology at CVS, and John
Borowski, corporate systems manager, have a list of recommendations for
companies going down the big bang route:
– The choice of consulting partner is key. Bear in mind that
the biggest consulting companies will most likely charge the highest fees, but
unless the user is on top of the game, they won’t always assign their most
senior staff to a project. On the other hand, smaller partners may staff
projects with higher quality individuals, but there’s inevitably a greater risk
attached to working with a smaller operation if the project runs into trouble
– Individual consultants should be treated in the way that you
would hire your own staff – you should ask for CVs from all the people who will
be working on the project and interview them. Demand a money-back guarantee
allowing you to substitute individuals supplied by the consultant after 30 days
if they prove unsuitable
– Impose a hiring blackout period – the CVS project leaders
recommend one to two years – where individuals cannot move from one
organisation to the other.
– Be prepared for personality clashes, particularly between
in-house staff (who may be feeling threatened) and the new team of consultants
– Use temporary staff to take on routine work that will be
automated by the new system, freeing up skilled employees to work on the rollout
– Be aware that users may not see the urgency of the project at
the start, particularly when it’s still on the drawing board. Borowski cautions
that one of the biggest issues CVS faced was getting people to turn up to gap
analysis meetings: "They didn’t see it as critical, it was years
away." Inevitably, that became an issue later on in the testing phase when
they became more interested
– Data conversion can be a hugely time-consuming process. CVS
wrote a program to convert from the mainframe to Peoplesoft, then used tools to
re-engineer data back into the mainframe and compare the differences. It
under-estimated the time by three months
– Consider breaking the testing into three phases
– new system testing, controlled parallel testing (using a clone of the legacy
system, not the production system), and mock live testing
– Devote sufficient time to training. CVS built 32 training
modules and devoted a month to general and job-specific training. It also
encouraged users to seek answers to queries from its support website
– Beware of scope creep – in a project of this length, new
managers who join the organisation may try to change the rollout programme
Sign up to our weekly round-up of HR news and guidance
Receive the Personnel Today Direct e-newsletter every Wednesday
– Bear in mind that you will not be able to fulfil every
promise. As problems crop up, some promised functionality may have to be
shelved until the second phase
-Most of all ensure that people involved on the project have fun
