Beware These Hazards to Functional Engagement in IT Projects

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. 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 the ones that do go badly and 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. 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 (homegrown) 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.

This is hardly an untouched topic. Some would say it is a dead horse. It has been a popular topic because it is pretty simple and because the failures in this area have been large, public and expensive. But it isn’t sinking in. I hear it from peers, associates, interviewees, interns, and I still read about it in trade journals.

Good IT leadership has many facets. But if you can get this one right, your projects will go more smoothly, your business partners will be better served and your project leaders will be positioned for success. To be forewarned, here are five common scenarios where you will feel pressure to skimp on functional leadership:

1. Just replace the homegrown system with a package—no need to involve the functional teams.

Enterprise platforms like Siebel, Oracle and SAP are not intended to be heavily customized. When going from a niche, custom application to Siebel, you need a strong functional leader to push back on every “Yeah, but” statement. They must start at zero and make the business justify every customization. Saying “no” to customization is bitter medicine for your business partners. They will make contorted faces and whine ad nauseum. But it is for their own good.

While most IT professionals understand the serious pitfalls of customizing package software, the business teams will not. You must help the functional project leader to understand these pitfalls so he or she can be the first line of defense. Never assume that the end state can be defined in terms relative to the current state, even in simple upgrades. Businesses change over time. Needs change too. Make the functional teams talk about what their needs are. With the functional project lead playing the bad cop, listen and question everything.

2. Business leader wants it now! We don’t have time to find a project leader.

I’ve lived through this one and it hurts. The scenario for me was a brand-new vice president who wanted a dashboard reporting tool. Eager to please and make an impression of being a “can-do!” person, I found it very hard saying “no,” or even “wait.” Now was not the time to introduce the new business leader to the elegant rigor of our toll-gate process. Now was the time to impress with action! I figured, what the heck, I know it is wrong, but maybe we can get in and out quickly, no strings attached. Eighteen months later we still had no functional spec and were still playing bring me a rock.

This is one piece of advice that everyone will ignore, but you absolutely should hold your ground with a new vice president and stick to the safety, predictability and quality of a toll-gated process. Heck, I know I have not seen the last time I will find myself at this perilous decision point. I hope next time I will still remember this lesson and do the right thing.

3. The IT person in this area knows the system better than anyone else. Let them lead the project from both sides.

While this is usually true, it makes a lousy reason for functional owners to check out of the project. If your company makes refrigerators, it is safe to say that the engineering department knows the refrigerator better than anyone. Yet you won’t see businesses suggesting sales and product management and marketing do not need to be involved in new refrigerator development. In fact, it is a given that a business person will lead the effort and engineering will deliver the solution.

Entire organizations (product management) exist to thoroughly own the product and ensure it hits the mark. This is sparklingly clear on the product side of the business but the message is lost when it comes time to implement a solution and digitize an internal process. Why on earth would anyone want an IT professional designing a business process? The best IT project leaders will ask “Why?” repeatedly when discussing needs and desired functionality. But the response must come from an empowered business person, a functional owner.

4. It is just a data warehouse—it doesn’t do anything! How hard is that?

Don’t be fooled! Data warehouse projects can be a path through quicksand. Sure, if they are constructed well, they really don’t do anything. There is no functionality to develop because what is needed for reporting is native to the application. So what is the need for a functional lead; how hard can it be? Well, it’s hard. If you don’t get the data model right, you will end up trying to cobble it together with code.

The IT project lead must spend weeks with functional teams understanding sales and product hierarchies, territories, go-to market organizations, pole structures—poking on every exception that has been baked into the business over years. IT project leaders know how to ask the questions but we simply can’t do it alone. If you try to, your data warehouse will be clogged with code intended to fake the wrong business model into acting like the one you should have designed in the first place. It won’t scale. It will cost a lot to support. Spend the time with the functional experts to get the data model right and it will rain reports.

5. We will do even better—we will have several functional leads.

Sun Tsu listed Unity of Command as one of his five basic principles of war. Seriously, he only went five deep and Unity of Command made the list! Must be important. Multiple functional owners = no functional owner. I’m not suggesting project management is war, but there are certain similarities. Listen, one key purpose of the functional lead is to boil all the issues to the surface, get the right people in the room and drive to a decision. That is much easier to accomplish if one functional owner is empowered above all others to be the deciding vote if necessary.

Accomplishing any objective is much more likely to happen if one person feels the burden of responsibility disproportionately carried on their shoulders. Thinking of it like this, it becomes very clear why naming a tomato can to lead the project is as dangerous as not naming a leader at all. If the business wants the project done right, they must look down the bench and find someone with the credibility, experience and seniority to make things happen. Tap the sixth man, not the water boy. If the business can’t spare a ringer, cancel the project. Spend the money on new product development.

Stay Strong

The fatal trap of underwhelming functional ownership repeats itself with such regularity across projects of all shapes and sizes that it is safe to say that this list of reasons for it is neither exhaustive today nor final over the long run. Rather than try to list them all, it is probably easier to just assume that you will brush up against some of them again some day. You will be tempted again. There will be that harmless little upgrade or innocuous Web project that begs you to bend… just… this… one… time.

In those moments of weakness, try to remind yourself what a beautiful thing a well-owned project can be. Try to think about the best functional lead you have ever worked with and consider this your chance to build a new one. Remind yourself of what a happy functional team looks like on the launch date of a well-owned project. Think of the benefits stream realized and what you did with the money besides sink it into the repair phase of the project. Imagine your project team turning over the project to the support team cleanly, disbanding the project and moving on to the next value-adding activity. Gives you goose bumps!

But just in case none of that works, keep this article. Laminate it. In those moments of weakness, read it again. Accept that the penalties for forgetting these lessons are very harsh. Throw some water on your face and take up the torch again. Your business is counting on you not to forget.

Liam Durbin is CIO at GE Fanuc Automation. He has been with GE for nine years, serving in several roles including sales force automation leader, IT Master Black Belt, and supply chain IT leader for GE Consumer and Industrial. Prior to his GE experience, Liam served as an officer in the U.S. Navy for 12 years. GE Fanuc Automation is a $1 billion segment of GE Industrial that produces hardware and software solutions for factory automation.