The harsh lessons of poor functional leadership are as infinitely forgettable as Groundhog Day was for Bill Murray in his movie of the same name.

This is even more the case when projects succeed with strong functional leadership because there really is no lesson in the first place. The project went smoothly, function got what it wanted or at least understood what it was getting, scope changes were minimal. Yawn. Isn't that what is suppose to happen? No one wants to talk about that. Nothing to see here, move along folks . . .

But even with the ones that do go badly, where everyone later agrees that functional engagement was a factor (even a big factor), it takes only a couple of months before we are back at it, trying to push a rope again. I'd say a catastrophic failure, blamed 90 percent on poor functional leadership, could only be milked by a talented CIO for six months before the business starts really resisting necessary levels of participation again.

But this is just conjecture. The real figures are unavailable.

Even CIOs forget. We get seduced or tricked or just take our eye off the ball and find ourselves back in a mess again, asking: "Now where did that functional leader go?" For us, part of the reason is that we absolutely hate to ask for that which we cannot succeed without. Because resources are scarce, good ones even more so.

Speaking from Experience

I took my current position on the heels of such a hard lesson. Our software business was the scene of the crime for our disastrous CRM implementation. The inside sales team was bleeding badly from several deep wounds and a thousand paper cuts. Channel partners were revolting. Activities that used to take minutes, like placing an order or checking availability, now could take half an hour. The system was bouncing frequently. The IT team was releasing a Siebel recompile every other day.

To this day Siebel gets a lot of abuse from the walking wounded. But to blame Siebel would be like the carpenter blaming his tools. What happened was (mostly) not its fault.

Our hard lesson was a classic example of thinking like this: "You don't need a functional leader. Just make Siebel do what the current (home-grown) application does." As a result, our Siebel instance was heavily customized, an enormous base support burden and as slow as continental drift. The IT team was worn out and frustrated. Before it was set straight the budget to correct the implementation was 150 percent of the original implementation budget.

We got through that tough time and the application is now stable, but three years later much of the heavy customization and support burden and most of the slowness lingers. A lot of the damage is irreversible. Sound familiar?

Hey, I'm over it. But in that project I relearned something that everyone reading this article likely already knows, yet is also doomed to relearn as well.