Tomicide Solutions February 2008: Maximising Project Value Through Better Collaboration Between Business Development And Project Management Teams

By Tom "Bald Dog" Varjan

There is also a podcast version of this newsletter but only for subscribers. If interested, you can subscribe through my free business development white paper.

CIonventional wisdom and extensive history tell us that business development and project management should be handled as two separate business processes by two totally different groups of people. The traditional high-tech business model is that commissioned salespeople, most of them with only bare minimum or zero technical knowledge, hunt down prospects, do their memorised dog and pony show presentations on features and benefits, twist their buyers arms to overcome objections for the sale, and when the service is sold, they hand over the client to the "professionals" who actually manage the project.

And then the sales folks go and start hunting for the next "victim". I use victim because when we talk about hunting, which is the traditional approach to selling in most high-tech companies, it's unavoidable to have a victim. There are the hunters, the super-aggressive salespeople and there are the hunted, the prospects that desperately try to out-run and out-hide these aggressive salespeople.

So far so good. But there is one big problem. Sales folks sell their services to purchasing or procurement departments not to real buyers and authorities. What that means is that that the very department that interacts with sellers has no technical knowledge. The hiring is based on an RFP with rigidly drafted specifications usually put together by the procurement folks, and since procurement wants to see every bidder on a level playing field, it rips all unique value points out of the bidders' offers.

And of course, when it comes to communication between procurement and the top dogs, many offered value components don't even get communicated to the top dogs. So, the real buyers don't even know what they're missing.

And now on this level playing field, stripped off of distinctive value, procurement is ready to make a buying decision. And since there are no differentiating factors between offers, the buying decision is based on price.

According to the 1995 Chaos Report by the Standish Group, in the $50-500 million annual revenue range, only 25% of companies conduct detailed ROI analyses before initiating projects. And I dare to bet one of the main reasons for such a low number is that in most cases sellers are not allowed to conduct ROI analyses. They are expected to blindly respond to RFPs that were put together by salaried pencil pushers with minimum or zero technical savvy and no profit-loss responsibility.

So, essentially, the procurement folks make buying decisions over something they know nothing about. Maybe the company hired some technical consultants to establish the problem and write up a course of action to remedy the problem, and now the procurement folks use this list to draft the RFP. Then bids are rigidly assessed against this RFP that was created by a committee of technical laypeople, based on the first consultant's prescription.

The procurement folks compare bids against bids and are looking for rigid similarities and differences, "You cost 10 cents more, so you're out."

In the title I used collaboration, and I meant it between four groups of people...

...and they have a hard time to communicate with each other.

I've deliberately left out the procurement department because it's good only for one thing: To leave real value outside of the company's walls. A very similar position HR departments fulfil regarding top-tier talents.

And the real problem is with collaboration between the seller's business development team and the buyer's executive team. However, it's vital that there is a peer-level match between buyers and sellers.

It's hardly a peer level match when the lonely salesperson runs a canned dog and pony show to the board of directors. The seller company's lowest level person, the salesperson, is trying to infiltrate the top of the buyer company. And it hardly ever works. This salesperson is highly likely to be relegated to the peddler fodder department, also called procurement and purchasing.

For the salespeople to offer meaningful proposals for projects, they must meet the person in charge. But the problem is that in most cases the procurement folks are heavily guarding access to real buyers and their project management team.

What Does This Protection Mean

It means that the seller's technical staff can't make a proper diagnosis of the buyer's problems, and procurement encourages buyers to bid their solutions based on the buyers' self-diagnoses. But in most cases that self-diagnosis is inadequate because it doesn't go deep enough to uncover the real causes. And what is the result. Well, some years ago McKinsey & Co did a study and concluded that...

Some 84% of high-tech projects go over time and over budget. And it's not due to human incompetence. It's largely due to the retarded policy that procurement doesn't allow the buyer's tech team and the seller's tech team to jointly diagnose the underlying causes of the symptoms the buyer is experiencing.

According to autopsy results, doctors misdiagnose fatal illnesses about 20% of the time. So millions of patients are being treated for the wrong disease. And this happens in an "industry" where the expert, the doctor, is conducting the diagnosis. And it's also important to consider that a huge chunk of medical education is dedicated to diagnostic skills. That is, these people actually know how to do diagnosis. The same in engineering education. I did my engineering education in the UK where project management and diagnosis occupied a pretty big chunk of the curriculum.

So, how can we describe the medical equivalent of the kind of diagnosis that's going on in technology industries? Well, roughly this... Patient compiles a request for bids.

"Doctor wanted. Must have qualified from a leading school (Harvard is preferred), minimum 15 years of experience of working on backs (John Hopkins internship is preferred) and bid maximised at $500. Qualified doctors can send their detailed proposals to the Procurement Department of Fred Cringingnuts. Please keep your proposal simple because the Procurement folks know nothing about medical science, and there is no need to confuse them.

If doctors worked the same way most high-tech companies do, based on their patients' self-diagnoses, most patients would die. But if doctors don't work that way, what is the logic that so many high-tech companies do?

The reason for that is that many high-tech companies, instead of assembling proper business development departments that market and sell the company's services in collaboration with their own and the buyers' internal project management team(s), merely hire armies of lone wolf gunslinger salespeople (often called peddlers, hucksters or worse) and send them out to roam the land to drum up business.

Just this week I received nine requests for business development projects. All nine buyers said they had read my web stuff and like the systematic non-peddler approach. Yet, when it came to discovering whether or not we have a basis for working together, all nine decided all they needed was more feet on the streets, that is, more peddlers running around and systematically annoying and alienating their target markets.

And of course, knowing the reputation of these super aggressive commission-hungry salespeople, sellers are protecting themselves by erecting strong peddler fodders, called the Purchasing And Procurement Department. The job of the peddler fodder is to protect the buyer's company from the unwanted and undesirable infiltration of these glib, super-aggressive smooth-talking hucksters. So, these peddler fodders issue RFPs, and these lone wolves invest a huge amount of their time, money and effort to respond to them. And the peddler fodder department makes certain that no one from the seller's company can talk to anyone in the buyer's company.

In my view, doing business through procurement departments is like making love through a proxy lover. I authorise you to have sex with my wife, and then you'll do a detailed presentation about what it was like, so I can enjoy it too. It's plain retarded.

Using RFPs to hire external expertise achieves the same dismal results as using resumes to hire high-calibre talents. These processes keep the most valuable candidates outside of the walls of the company.

So What Can Both Sellers And Buyers Do?

Sellers Are To Integrate The Operation Of Their Business Development And Project Management Teams

In aviation, the highest number of accidents happens when tower controllers change shifts while a plane is taking off or landing. That's when tower control goes from one controller to the other. In this transition, valuable information is lost and missed. The previous controller has a good understanding of the plane's position and the pilot's mindset. She has vital tacit knowledge of the plane's and the passengers' situation which cannot be passed on to the next controller. The same is happening when business development.

In high-tech, the highest rate of cock-ups happens when the business development folks hand over the client to the project management team. And since the project teams start out on the wrong foot, from there on the project goes down.

I believe, the business development team should stay involved in each project until it's completed and beyond. I say "Beyond" because it's the business development folks who stay in touch with this - by then - former client. That is, the relationship stays alive. The company still provides value to the client through a newsletter or occasional articles of interest.

Sellers Are To Replace Armies Of Lone Wolf Peddlers With Integrated Business Development Teams

These business development departments can seamlessly take clients from first contact to the point when the project management folks can get involved to start some initial diagnosis. This diagnosis makes certain that there is a business case for the change initiative, and this process quantifies the cost of living with the problem. This provides differentiation from the competition and helps to avoid fee objections. That is, the business development folks of the seller's company arrange meetings between the buyer and the seller's project management teams and various key people. When these people are together and on the same page, then a thorough diagnosis can be conducted facilitated by the seller's business development team.

And if there is a clearly quantified value for living with problems or capitalising on opportunities, then the project can go ahead.

Buyers Are To Make Their Project Teams Available To Collaborate With The Sellers' Project Teams

This way the two teams working together can jointly diagnose the undesirable situation the client experiences and quantify the cost of the problem. There is no need for Procurement Or Purchasing to poke its nose in this process. All they can do is to remove crucial value elements from the proposed solution, thus undermine the quality of the completed project and compromise the projected improvement. Remember, procurement is cost focused not ROI focused. This is why RFPs talk about budgets but hardly ever mention ROI. They talk about tasks and activities not results and outcomes sought.

Installer Or Consultant

In recent years, it's become pretty common to recommend even to consultants to turn their offerings into "packaged" goods. The problem I see with this approach is that this approach also turns those offerings into commodities.

But we also see is that technology is becoming more and more complex, and pre-packaged things can hardly ever solve clients' problems. And while it's easy and tempting to go with clients' own diagnosis and just offer some kind of off-the-shelf solution, it can also be the demise of a consulting firm. Mind you, this is how most large "consulting" firms do it with the help of lots of low level "installers".

The senior partners go on a hunting spree, set up some projects and then the low level installers show up to install the pre-created solutions.

But this is no longer consulting.

This was my problem with one of my instructors in 2002 when I was doing my CMC accreditation. For his MBA mind, consulting was all about churning out pre-created processes and charging for the time it took to churn them out. In one of the assignments I referred to perceived value and how that should relate to consultants' fees, and I was ruthlessly verbally beaten up for my unrealistic daydreaming.

There are many IT consultants out there who are nothing more than repair people, that is, contractors working on predefined (by clients) problems, such as, "replace my crashed hard drive" or "Update my antivirus software". Contractors are called in because clients have neither time nor inclination to do the work. Clients are not involved in the process only in the evaluation of the work. Considering the skills required, this type of work is usually considered as a commodity, and these contractors are compensated accordingly. Well, simply because there are so many of them.

While contractors work for clients, consultants collaborate with their clients on solving their problems that are unclear. Jointly with clients consultants diagnose the problem, and together they develop an ideal solution. Clients are involved in the whole process, and they do most of the work with the consultant's guidance. This is a relationship between equals. This is vital because one aspect of consulting is to develop the client's capability to solve the same problem in the future without external help.

According to the - Canadian Oxford - dictionary, the verb "consult" means to seek information or advice from a person and refer to a person for advice and opinion. It mentions nothing about doing manual labour for clients. Consultants are collaborated with and provide additional value-added that represents something clients did not possess before.

This is an important distinction, because without the clear understanding between the two you can grossly ill-position your firm, thus gradually bringing it to its knees.

While as a contractor, you focus on technical issues only, there are some other factors to consider in IT consulting.

One big difference is that while "geeks" make good contractors to provide technical solutions, most of them make poor consultants. Geeks are called geeks because they have a very strong technical focus, thus they possess amazing technical skills.

However, IT consulting is about providing business solutions, and this goes way beyond selling strong technical expertise.

In IT consulting you need three key competencies: 1) technical skills, 2) business skills and 3) people skills. While contractors fix problems, that is, they take contingent action, as a consultant you must be able to think big picture and take preventive or innovative action to advance the client's business. Read again. While contracting is about restating the status quo, consulting is about improving the client's condition by raising the bar to a new level of performance.

You must think ahead and take preventive actions, that is, to help your clients to reduce or eliminate the possibilities of problems. Also, you must keep your clients' visions in mind and people's readiness to use your technology. That is why you need both business and people skills.

A Closer Breakdown Of IT Consulting Components

IT Consulting Model
  1. You have technical skills and business skills, but missing people skills. In this case you can do the technical work that supports business processes and is in alignment with the client's vision, but cannot effectively interact with people to make sure they actually use your new technology.

  2. You have people skills and business skills, but are technically lagging behind. This situation does not happen too often, but every now and then we can see it. But it is important to note here that - even when it happens - it is probably the smallest problem. Why? Because in the worst case as you assemble the implementation team, you can draw some people from other firms which have the needed technical competency.

  3. You have technical skills and people but do not understand how they tie into business processes, and you may end up recommending a system which is totally counterproductive when put to work. Actually this scenario happens quite often.

  4. As a consultant, you must operate in such a way that you have technical knowledge to accurately diagnose problems and develop solutions, business skills to analyse business processes and people skills to make sure people are willing to use your new technology which supports the business.

So, when it comes to skill-building for your people, just keep in mind that technical knowledge is just a small part of the overall game. According to an old Harvard research study (later confirmed by Stanford and the Carnegie Foundation), success in any profession is about 15% content expertise and some 85% of seemingly irrelevant skills. So, as your people advance technically, make sure they also advance in their people- and business skills.

In Conclusion

The high-tech sector is notorious for projects that are over time and over budget. And one of the main culprits is that many high-tech companies develop their solutions based on the symptoms their clients tell them and fail to perform their own detailed diagnoses.

Clients say what they want. Then the seller's people go away and develop something in isolation. That costs a bushel of money and time. Then the seller's project team comes back and hands over the ready-made solution. And clients are flabbergasted because in many cases they get what they didn't want.

So, make sure that your business development folks and technical folks work together for the greater good. After all, what really matters is that your clients receive the pre-agreed value and you get paid for providing it. And the better your folks work together, the more value your clients can receive, and the more you can charge.

Attribution: "This article was written by Tom "Bald Dog" Varjan who helps privately held information technology companies to develop high leverage client acquisition systems and business development teams in order to sell their products and services to premium clients at premium fees and prices. Visit Tom's website at http://www.varjan.com.