There's a great song by Graham Parker called "The Three Martini
Lunch" and in it he sings these words: I know what I'm
doing, I just can't stop doing it.
In 2000, I inherited (meaning I got stuck with) a messy Siebel
deployment. For kicks, SAP was being rolled out at the same
time, except in an "accelerated fashion" -- meaning 8 weeks or
something goofy like that. All I know is it was without
question one of the least enjoyable portions of my career. It
was highly debatable if either product was needed, it was
unquestionable that they weren't needed in a rush, and it felt a
little bit like attending a 3 month continuous homeowners' meeting
-- an unhappy ending was inevitable.
A global systems integrator was leading the SAP effort, in
partnership with a systems integrator who specialized in Siebel,
which was then a fairly new product. In effect I became an
owner's representative for my employer, and calling it an owner's
rep is a kind way to put it, because you couldn't have called me a
project manager, and for good reason: I'm not a trained
project manager. About the only qualification I had was being
nominated to help, and when all was said and done, seeing this mess
unfold in person gave me some invaluable lessons for my
career.
These are all pretty simple, but here goes:
- Hurrying is foolish. Rushing to roll out
an enterprise-wide application is a horrible idea. No
self-imposed deadline validates the unfortunate things that
accompany a "we'll miss the deadline" sentiment on a large project
deployment team. Worrying about a missed deadline means
pushing forward with bad ideas, and a poorly thought out
product. And if multiple project managers are more concerned
about checking things off a list than figuring out if the right
things are being done, you're in trouble. Missing a deadline
is not inherently bad if it prevents a much larger mistake.
- Check resumes. Systems integrators often
promise the moon. The two companies leading this charge were
engaged on promises and pledges but no one checked the resumes
before signing the dense contracts. Numerous people came into
the project from both integrators, and even more left the
project. Moral of the story: when the systems
integrators can't keep someone on your project, something's very
wrong.
- Customization is tempting but a bad idea (like a
combover). If you can't use 90% of a product out of
the box, you have made it too complicated. And anything
complicated and done in a hurry is simply not going to work.
I still distinctly remember the Siebel systems integration lead
saying, Now not everything's shaped like a funnel, to the company
CEO who felt that when it came to sales, everything was in fact
shaped like a funnel.
- Don't buy anything that costs more than your revenue in
the previous calendar year. To do so means you're
assuming continuous exponential growth, and that's an incredibly
ignorant way to think. You'd be much better off having some
growth issues and challenges rather than have high-dollar software
prevent revenue due to a poor implementation. You don't need
any software this badly.
- Appoint and then train an expert or two.
Someone on your team must know every nuance of a product you're
paying millions for. There's no other way to make it
work. If you can't select a few folks and get them thoroughly
and properly trained, which means incidentally that they are almost
certainly trained by a professional trainer, then you shouldn't buy
whatever you think you need.
- When you go live, ask yourself if you're better
off. In the case of this death march project, two
off the shelf software packages were thrown out in favor of two
expensive ones. Goldmine (CRM tool) was kicked out for
Siebel, and Quick Books (Accounting) was kicked out for SAP (and
the accompanying full-time ABAP programmer needed to keep it
together with baling wire). It was apparent within a week of
rolling out these products that they wouldn't work as intended, but
it took two more months to admit it.
I'm alternately pained and amused to even write these
thoughts. Who in his right mind would roll out two systems in
such a rush? Why was Siebel considered far better than
Goldmine (which perhaps wasn't even as good as another out of the
box tool, Act)? In retrospect I suppose I could've washed my hands
of the project, but I needed my job, and convincing someone of an
impending failure is not easy.
EMR systems with crtical modules and price tags in the millions
are being sold and deployed each month, and inevitably some of
these won't go as planned. What will mark those that
fail? Who is talking about these? Will we learn from
someone else's mistakes, or will we pretend things are going
fine?
When faced with the choice of selecting and rolling out systems
that bring with them such sweeping change, let's hope that the
decision makers are not busy with the allure of great
promises. Instead, perhaps the decision should begin with a
simple approach centered on protectionism. Whatever you do,
don't break what was working before.