Project Management Tools That Work

Can Your IT Project Manager Sell Better Than Sales?

In short, IT needs a sales quota. We’re not talking about database admins making cold calls or security teams sweeping LinkedIn groups for prospects. Instead, our organization should assign a target sales goal as part of its overall IT objectives, focusing your team on increasing revenue hand to hand with the sales organization. … It’s tough to admit you don’t really get the sales process, but IT teams just don’t have a ton of sales experience to build upon.” Sell It! InformationWeek, Michael Healey, March 26, 2012.

Hmm, IT doesn’t understand sells or marketing? Let’s think about this notion a little bit. Keep in mind “IT” are people just like those folks in other departments. Very often, especially for technology products (mobile phones, consumer electronics, PCs, iPods, etc.), those IT folks often look more like the customer than the sales and marketing folks I’ve worked with. Let’s take a real world example to add some perspective.

I was managing a software development department. We had some 100 software engineers and technicians that worked on our products and delivered them to our customers. The problem was that we were not a “profit center” but were categorized as a “cost center.”

That was strange to me. Here we were selling our software to customers both as stand alone products and as a service. Customers paid us to develop new capabilities and install them into their IT centers. Engineers were sent out to work at customer sites and we charged our customers hourly rates for their work. How were we not a profit center? What was our purpose if it was not to generate revenue?

It seems that with each revenue transaction we associated the sale not with the engineering department, but with the marketing team and their customer. Even as the Director of Development, I could not see from my finance provided accounting data how much revenue my team generated by their development and service activities. It was like we were invisible as a revenue source.

Add to this situation that it was not unusual for our account teams to inveigle me to send out engineers free of charge to help at a customer site (support was a billable item per our customer contracts). It seems that since the account got to recognize the sales, but not the costs, it was not a conflict for them to try to get an engineer onsite but without charging our normal fees.

I raised this situation up to more senior management and recommended a solution which was to designate my department a profit center. Finance would simply also keep and show the data of how much revenue we generated and of course continue to show our costs. Senior management found this humorous. The other development directors thought I was nuts. Needless to say, my recommendation was not adopted.

The finance system was locked up tight such that I couldn’t pull the data to see what revenue we generated (and I had already tipped my hand to what I was trying to do, so my request was met with silence from finance). I considered tracking the revenue manually but that just seemed silly when we had a whole system that captured the needed data.

The insight and breakthrough came while I was updating my annual budget. It came in the form of a question (a good metrics technique). While I didn’t know my revenue, I did know my cost, so the logical question was “how much revenue would I need to generate to break even?” This translated into “how many hours do I need to bill at the average contract rate for my team to pay for itself?” This was easy to compute since I knew my cost and I knew the contract rates. It came out that I needed to have about 40% of my folks (total work hours) billed to revenue generating activities (contract development, service calls) for our team to break even, to pay for themselves and for all our equipment, systems and overhead.

While all this was going on, we were regularly being extorted to cut costs and do more with less. It was obvious to me with this accounting that it was equally important to get more of my team working on a billed contract (as opposed to the normal defect repairs and developing future capabilities that may or may not be billable as new capabilities, etc.). In fact, it seemed obvious that selling our capabilities to put more staff on a billable activities made more sense than trying to reduce folks. Yet, here I still had account managers, for example, trying to give away our engineering hours for free (e.g., “we’ll earn their goodwill!”).

At a budget review I summarized my department and then I dropped the bomb that if we had 40% of my team on billable hours than we would pay for ourselves. Over that, we would generate a profit. Why were we talking about reducing staff costs when these “costs” generated revenue and were highly prized and sought after software engineers? Let’s proactively put them to work rather than giving them away for free. Unlike the reception of my previous recommendation, this notion struck a chord with most of managment during these budget reviews.

When an account manager would ask me to send out software engineers for free, I would ask them how were they helping to pay for the team we had? Was it OK with them and their customer if I reduce the size of my, costly, team and so have less people available for these free visits? I was being asked to reduce my costs after all. If I had someone I could send out for free, obviously she was someone not working on anything billable and so probably was someone I could let go. How about using someone who was also working on a billable project for the customer? Send them out? Of course that would probably slip out the project delivery date or otherwise cause us to do a bit less due diligence on development and testing, since we would spend time away from our billable projects.

I knew I had finally gotten through when an account manager walked into my office, sat down and his first words were “I have a request for an engineer and the the customer will pay for him!”

Once we had the insight on how our engineers contributed to our revenue and to selling our products and services, we had less “giving away the store” than we had had in the past. People would now look at our technical folks and see their revenue capabilities and not just their costs. Needing, per the opening quote, for the engineer/IT person to do more to sell the product or service just seemed silly in this case once we gained an objective perspective on how they already contributed to the bottom line. Putting everyone to work using their primary expertise was still the best project management tool.

Is your project team seen as a cost or as a generator or enabler of revenues?

Thank you for sharing. Sharing and comments tells me which articles are most helpful to my readers: