Last Updated on April 12, 2021 by HostingandOther
- 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.
Video Introduction: Getting to a Specific Explanation
Text Introduction (Skip if You Watched the Video)
Business leads have a specific role that can be misunderstood. Sometimes, the business lead can 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 on the IT project. You will learn the true 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 that I work on, to the detriment of actually 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 or do different things, but not why they should or should not do them.
The Problem of Meeting the Business Requirements
One of the greatest 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.
It is unlikely or impossible for the software solution itself not to match the business requirements? Didn’t, after all, the company selects the software?
Actually, 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 normally 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 many times mislead or provided with poor advice by large consulting firms that they hire. These consulting companies have a stronger emphasis on 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 to 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 their customers, but they have 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 just get Oracle’s lies repeated back to them through the consulting firm. Yet this fact is completely 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 is traditionally the representative of the business interests.
The following applies to the business lead role.
- Every project suffers from the limiting factor that 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. But 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 ended up reflecting 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 had their role explained to them.
How to Not be Pushed into User Acceptance
The business lead has a major role in getting value out of 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 a variety of 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 the large consulting firms to obtain user sign off on implementations that do not meet business needs. Generally, consulting companies tend to 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 useful 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 very 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. Often the client project managers feel as if 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 as if 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 then 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. All the 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. It’s essential to insist on everything being 100% before the documentation being signed. If you refuse to sign, you will notice they will begin to react and treat your concerns with attention. After you have approved, the consulting firm could care less about what happens after that. Your only negotiation leverage is before your signature.
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 real role and responsibilities.
It must always be remembered that the company ultimately decides if the solution is used. Many projects have found out the hard way 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 and the consulting firm and the deadlines (which are more often than not based upon inaccurate assumptions) to ensure the highest probability that the implemented solution is a reasonably good fit to requirements.