How to Understand The Role of the Business Lead on Any IT Project

Executive Summary 

• Business leads have a specific role that can be misunderstood.
• How the business lead can be viewed as a “firewall” between the business and the technical team.

Introduction

Business leads have a specific role that can be misunderstood. The business lead can sometimes be viewed as a “firewall” between the business and the technical team. Business resources are often assigned as business leads on IT projects without explaining their role in the IT project. You will learn the proper role of a business lead, its role, and what it is not.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Why I Wrote This Article

I have witnessed an increased focus on the technology side of the large IT projects I work on, to the detriment of matching the solution and configuration to the business requirements. I am increasingly seeing very technical consultants showing business users that they can do different things but not why they should or should not do them.

The Problem of Meeting the Business Requirements

One of the most significant reasons for the high failure rate of large IT projects is that either the software solution selected or the configuration of that solution did not meet the business requirements.

Is the software solution unlikely or impossible to match the business requirements? Didn’t the company select the software, after all?

This is a common feature of the outcomes of software selection. Here are a few reasons why.

Reason #1: Software Vendor Salespeople

Software salespeople will generally say their software will cover requirements that their software will not.

Reason #2: Bad Advice from Financially Biased Consulting Firms

Often, companies do not know all the best alternatives in the market and are misled or provided with poor advice by large consulting firms they hire. These consulting companies strongly emphasize recommending software vendors that they can bill consulting hours. As a result, very few companies are implementing the best software for their needs.

Reason #3: Not Getting Independent Advice

Few companies in the US hire deep technical experts to advise key decision-makers.

They do hire them to do work but rarely advise them during the software selection process.

Thus, these key decision-makers do not know what they are buying and do not know how to puncture software vendors’ claims. When I worked for a large supply chain planning vendor, I arrived to manage projects several times where at least one of the modules was not a good fit for the business. I was told to keep that to myself by my boss, and when I told the customer the truth (which they were going to find out eventually), I was told by our salesperson that I had.

“You ruined my credibility with the account.”

Suppose we take the example of Oracle. Oracle not only constantly lies to its customers but also has a large army of Oracle-aligned consulting firms that support Oracle in these lies.

This is why Oracle consulting firms (unless it is a highly unusual entity like House of Brick that helps protect customers against Oracle) will repeat what Oracle says, like parrots, and lie to others about the state of Oracle projects.

Any company relying on a consulting firm that is a partner of Oracle will get Oracle’s lies repeated to them through the consulting firm. Yet this fact is entirely ignored by most companies that buy enterprise software and think that a company like Deloitte or Accenture will not lie to them for financial gain.

The Role of the Business Lead

Essentially, the business lead traditionally represents the business’s interests.

The following applies to the business lead role.

• Every project suffers from the limiting factor that the Business Lead does not have experience in every area (and cannot have unless it is a small or medium business).
• Many projects have gone live where the Business leads were from area A and overemphasized A, so area B was not configured correctly.
• The Business Lead’s expertise leads the technology consultants in the right direction but must build consensus from the often wide variety of viewpoints.
• The business lead may question requirements as not a good idea for business reasons. The technology consultant or lead may push back for technical reasons. However, the Business Lead is more of a combined role of requirements gathering and serving as a firewall between the business and the technology solution.

What the Business Lead is Not

The business lead is a management role combined with domain expertise. However, they cannot reflect all of the technology team’s requirements unless the company is on the smaller side. This means the business lead must interact with other business areas to reflect the requirements for the implementation. I have seen business leads that superimposed their own preferences onto other groups and did not listen to them. This meant that the solution designed reflected the business lead’s preferences rather than the other areas the software was meant to address. This was one reason I wrote this article, as the business lead had never explained their role to them.

How to Not be Pushed into User Acceptance

The business lead has a significant role in getting value from the implementation company and the vendor. And one of the most critical areas of leverage they have against the consulting firm is withholding user acceptance testing sign-off. Large consulting firms will use various techniques, including flattery, the idea that your interests are their interests, and the illusion of power to get sign-off on non-functional systems.

The Issue with Sign-Off

As IT projects have become less and less about the actual business value. And more about perpetuating IT projects, it has become more critical than ever for large consulting firms to obtain user signatures on implementations that do not meet business needs. Generally, consulting companies care little about their clients and are just there to bill hours.

Once the client signs the user acceptance documentation, they have progressed far in achieving their goal and protecting themselves from the lawsuit. Since the system implemented has major holes or is not helpful to the business, the consulting firms need to sign off. The way this is accomplished is listed below:

Shorten the period for user acceptance testing to be done quickly and against a deadline.

Consulting Firm Technique #1: Co-opt the Project Managers from the Client into Adopting the Time Frame of the Consulting Firm

In this way, the client project managers support the consulting company’s agenda over their own company’s needs. The client project managers often feel that a missed user acceptance test deadline reflects negatively on them. They want to mitigate this by agreeing with the consulting company to rush through UAT (user acceptance test) and get approval.

Consulting Firm Technique #2: Intimidate the Users

I was at an account where the consultants almost filled the cube of the users. The user then felt they had four people to make happy rather than testing if the solution worked for them. Consultants may frequently remind the user during the UAT that the testing approval “really needs to get done.”

Denying the Shortcomings in the System: It is normal for the user to get stuck and for the consultant to take the keyboard and force a workaround. It gets the user through that portion of the UAT, but later, when the consultant is not there, the user will fail in the same activity.

Consulting Firm Technique #3: Playing Their Game

It may be hard to accept fully, but the consulting firm does not care if the implementation is successful. Big consulting firms have big brands and are relatively immune to failure. They get new projects based on their name and the many relationships they have in the executive suites. Their primary focus is on getting all the project documentation signed off on.

Once the documentation is signed off on, they can safely leave the account with or without a functional system, and they get to collect their money to defend against being defrauded by these firms. Insisting on everything being 100% before the documentation is signed is essential. If you refuse to sign, you will notice they will begin to react and treat your concerns with attention. After you approve, the consulting firm could care less about what happens afterward. Your only negotiation leverage is before your signature.

Conclusion

There are many reasons for a misalignment between the designed solution and the actual needs. However, one of the easiest to rectify is simply a misunderstanding on the business’s part about their actual role and responsibilities.

It must always be remembered that the company ultimately decides if the solution is used. Many projects have discovered that you cannot force the company to use your solution because there are always workarounds. The business lead should be empowered to push back on the vendor, the consulting firm, and the deadlines (often not based upon inaccurate assumptions) to ensure the highest probability that the implemented solution reasonably fits requirements.