DoWill Bachman: Chris, thank you so much for joining. It is great to have you on the show.
Chris Doig: Well, Will, it’s a pleasure to share some of the things I’ve learned over the years about software evaluations.
Will Bachman: So, Chris, we connected a bit ago and I was so impressed by your methodology and your deep expertise in the area of ERP software evaluations, and asked you to be on the show. Was delighted that you agreed to join. You’ve written a book on the topic. Your firm is really just focused on this. Just give us kind of the overview of the firm and the services that you provide.
Chris Doig: Okay, Will. Well, really, we help clients select enterprise software. And this comes out of, it was a create your own niche type situation that led me to found the company. And really it boiled down to you so often buy software, but it’s only after the software has been implemented that you find out that it works well or not.
And originally, I was an electrical engineer and I have a very methodical approach to these things and it was never satisfactory to do that. I call that the pay-and-pray approach. And really, the idea is how can you know how well software’s going to work for you before you sign on the dotted line? And that led me to founding the company and interestingly enough, we originally started developing a software product to help evaluate other software products, a sort of an evaluation tool.
But after a while, I realized the market wanted more than that. The market wanted the problem solved. It didn’t want to solve the problem itself. It’s a little bit like you taking your car into a mechanic to change the brakes, rather than changing the brakes yourself. I mean, if you were a starving student, you might do it yourself but otherwise you’ll take it in and get it done. And that’s the approach.
And one of the interesting things is in that developing a consulting business, really helped up build up a library of requirements. Because we discovered that in any given type of software, everybody has the same requirements. For example, if you took a retailer and a bank, both would have security requirements, but how they weighted them would be different. But they’d both have identical requirements. And really, in consulting, that allowed us to develop a library of requirements that we’ve reused.
And as we’ve reused these requirements, we’ve found they’ve got better and better. That’s sort of how we arrived at where we are today.
Will Bachman: So this is interesting. Maybe we don’t dive into this part now, but one observation is a lot of independent professionals or people running boutique firms like to have a very broad offering. They don’t want to narrow themselves in too much because they’re afraid that if i get too narrow, I’m going to miss out on project opportunities that are outside this narrow thing that I’ve picked.
And you’re an example of saying, you know, I don’t even do just all IT consulting, or even all software consulting, I just focus on helping you pick ERP software. And so, going super, super narrow. And it seems to be working out well for your firm. So that’s kind of just an interesting example of having a really specific focus and knowing who you’re serving.
But let’s talk a little bit about how you work. So a client calls you up and says, hey we need your help. We’re evaluating a new ERP platform. Talk to me about the process that you follow to work with that client.
Chris Doig: Well, the first thing that start off with is, you know, why’s the client doing the project now? Why not last year or next year? And really, what we’re looking for is how valuable is this project to the client? Sometimes you find clients come in with a really half-baked idea. I think I need to upgrade my ERP but I’m really not sure why I’m doing this.
And quite honestly, we can’t work with those sort of people. What we do find is, for example, a recent client came to us and knew exactly why he wanted the ERP software. He’s planning on doubling his firm’s revenue over the next five years and he’s paranoid about going into an ERP selection and finding out it simply doesn’t work out.
So these things start off with looking at the ROI, helping the client evaluate that ROI and develop an ROI. In the case of this particular client, speaking at a very high level broadly, the value of the new software boiled down to how much revenue his firm could grow by over the next five years, because he’s taking his existing software platform about as far as it’ll go and he can’t take it any further.
So it really boils down to getting the client to tell us what the value of the software is in their own words.
Will Bachman: So that’s kind of step one. And then walk me through kind of the lifecycle of a typical project. So you have this initial discussion around why, why now, what’s the value. And then what are the kind of big parts of the process that you’d follow as you work with that client through the selection process?
Chris Doig: Once we have a contract signed with a client, we go into something, there are four phases. And let me go into those phases quickly. It’s heavily weighted towards the front end, which is phase one, the requirements analysis. And there’s less and less work for each of the subsequent phases. And what it turns out is that almost invariably, if a software implementation goes wrong, it’s because of an inadequate requirements analysis.
What happens is that new requirements are found during the implementation and dealing with these requirements takes time. And when too many of these new requirements are found, dealing with the time taken to deal with them is what causes the schedule to slip. And then as schedules slip, people start saying, whoa, you know, we need to reign this schedule in a bit. Let’s see what we can trim. And so they start cutting things out. And it’s those things that cause business disruption when the software goes live. So an adequate requirements analysis is absolutely foundational to all of this.
So from a very high level, we start off by meeting with users. And the thing about users is most of them, they know their pain points, but they don’t know very much else. So you can’t really expect to get requirements or that many requirements from users. Maybe if some, if there’s a user who was recently at another company who used similar software, you’ll have a broader perspective. But in general, users have a relatively narrow perspective on their requirements.
So we start off meeting with users to ask them for their requirements but the biggest thing we’re doing here, is we’re actually building a rapport with those users because it’s very important that users feel involved in the software selection process. Because if they don’t, they tend to reject it. If they do, they tend to buy in, and that’s the first step of building the buy-in.
Once we’ve met the users, we’ll do some software research. We’re trying to find, at a high level, potential products that could meet the requirements. We usually gather quite a lot and some of them are eliminated very quickly. And you get down to a short list, less than a dozen, very quickly and even that can be shrunk down. So we do some software research then.
And then we move into the phase of developing the actual requirements and this is absolutely key. And for any ERP selection or something like that, roughly half the work is going to be in developing requirements. In addition to the requirements we’ve already gathered from the users, what we do is we have libraries of requirements.
For example, we have a library of over 750 requirements that are common to any enterprise evaluation project. Think of things like usability requirements, security requirements, contractual requirements, licensure requirements, all those sort of things, mainly non-functional requirements, but they’re still very important. We add them to the evaluation. Then we have specific libraries. For example, ERP libraries. We add those requirements.
Then the next step, and this is absolutely crucial. What we do, is we look at the potential products and we re-write the features of those products as requirements. We call this reverse engineering because it’s a bit like doing software development banquets. You’re looking at those features and turning them into requirements. And what this does, is it’s how we find requirements the client doesn’t know they need.
And let me mention a little story from a few years ago. We were helping a client in the civil engineering space and they were looking at project management software. One of the things, this was at the time cloud project management software was just beginning to take off and they had apps on smart phones. And when we showed this to the client, their eyes kind of lit up and they said, you know, whenever we have something, a project in a remote place, it can be a huge problem to lay on an internet connection to that place.
And secondly, when project managers are on the project, they’ve got to go back to the field office to get the information they need. With smart phone apps, they can now be standing on the site and they can get most of the information the need without going back to the project management office.
So the concept of a smart phone app looking into a project management tool was something they’d never even considered. And when they saw this they said, you know, that is such a critical need for us, and we didn’t even realize we needed it. So that’s how the reverse engineering process works. It lets you find requirements you don’t know you need.
The other thing about it is it’s a formal process that you can follow. It’s not a subject of winging it type process. You go through these various products, you look at them, you’ll find the requirements you need.
One thing I want to say about requirements here is it’s very important to write them in enough detail so that they can be implemented. Let me give you another example. Suppose the requirement was to have form software on tables that end users could fill out the form and find it online. But the requirement was written, must have tablet app.
When that software got to the implementation stage and they found that yes, the software does have a table app, but it doesn’t do the forms filling-in, then suddenly there’s a month, two, or three month mini-project to get around the problem. So this is one of the things that happens when requirements are written at a too high level.
When they get into the implementation stage and they can’t be implemented the way that is desired, that causes delays with the run-on effects.
Will Bachman: So you go through the phase of requirements analysis and that sounds like the biggest, most complex piece and where you’re really adding a ton of value because it could be if it’s servicing requirements customer’s not even aware that they have, when you get through that, what are the next phases?
Chris Doig: Okay. Well there’s one last and very, very important step to the requirements analysis. And that is to have the users weight the requirements for importance. And the key here is that we’ve separated the gathering from the weighting. It turns out to be much easier. Because what happens is when you’re gathering requirements, that’s the first draft of the requirements. You gather them from multiple users, they get merged, they get split, that kind of thing. So you can’t gather the weights early.
So we sit down with users to weight requirements. But what happens here is that when users, particularly middlemen, even lower, see their names written on the requirements, why they want it, and how important they are to them, that is when the light goes. And they suddenly the company’s paying attention to me. My needs matter. And they change from being disinterested or even anti-, in becoming advocates or evangelists for the new software.
So that weighting requirement is absolutely critical in terms of building out the user buy-in. So that’s what round off the requirements gathering stage.
Will Bachman: On weighting, you do that kind of thing on a lot of different types of projects, even things way different than software analysis. How do you do it? Do you do kind of forced ranking or do you do it like you have a hundred points, distribute them as you like or is this a one through five? Problem with a high-low, one through five system is everything is important. So how do you get people to weight or prioritize those different requirements?
Chris Doig: Well, we have a scale. And the scale goes from showstopper, critical, very important, important, and then there is useful, nice to have, and no interest. And each one of those is assigned a weight that is used to calculate a gap analysis score. And what we do, is we put this table in front of the users and each of those terms has an explanation.
For example, if it’s a showstopper requirement, it means if the software hasn’t got this feature, then it’s going to be excluded. Or if it’s a critical requirement, that means there’s a lot of work to work around it if that requirement is not adequately met. So we give the users in the meeting a printout of this particular table and then they just decide how important it is to them.
And it’s invariable, if there’s a team of users and we usually to keep these to below a dozen people or so, and there’ll be some discussion and they’ll eventually settle on a weight. And what happens is you get some people out there who think everyone of their requirements is a showstopper. Yep, it happens.
And you ask them why is it a showstopper? “Well, we’ve always done it that.” And you know, that kind of thing, the user doesn’t actually know why the requirement is important. So the team will usually be able to give an answer. Then you capture that.
An interesting thing about weighting requirements is anything that is less than important is actually excluded from the evaluation. We write down why it’s not important and who said it’s not important. But at the end of the day, that’s voted out of the evaluation and it’s only important or higher requirements that are used to evaluate the software.
But key in all of this is involving the users and building their buy-in. So if I can relate another story, I was chatting to a salesperson in Orange County in California fairly recently. And he had taken a severance package from a major pharmaceutical firm that was based in the UK. And this form had implemented the CRM system and had not involved the salespeople at all.
And consequently, virtually all of the salespeople rejected it and they went on maintaining their spreadsheets, et cetera. And then every week, they would put that information into the CRM to pretend they were using it and that sort of thing. And so they spent even less time in front of customers.
At the end of the day, this large company, and I mean large, saw their stock price decrease by about 25% over the space of two years, simply because they weren’t getting enough sales. And that was driven by a very poor CRM selection. This illustrates what happens if you don’t take users into account, so building that buy-in is extremely important.
Will Bachman: So after you’ve done the weighting and you’ve identified their requirements and then the weighting, what are the next phases?
Chris Doig: That completes phase one. The requirements and analysis. Then you move onto phase two, which is the software evaluation side of it. Now, there’s a little problem here in that you, when you ask a software reseller to provide you with an RFI, someone who resell NetSuite, Oracle, Microsoft, SIP, et cetera, you ask them to do an RFI, you really need to make sure that the person who answers the RFI is the same person who is going to implement it.
So at this point, you have to do due diligence on potential implementation vendors because some of them do a good job, and some of them, well, it doesn’t work out so well. So you want to do that due diligence. So the first thing you do is you do due diligence on the resellers themselves.
On the other hand if you are doing a niche product, let’s say something like a clinical trials management system, then the vendors would most likely, not all of them, but some of them, would most likely implement the software themselves. Particularly the smaller vendors. In that case, the due diligence is wrapped up into their requirements.
But really, you need to make sure that whoever responds to RFI is the company that will be doing the implementation. So you do that and once you’ve decided on your potential vendors, then you send out the RFIs which are based on, obviously, the requirements you’ve just gathered.
Now, what we do is we’ve designed those RFIs to be as easy as possible for the vendors to respond to because our way of thinking it, they’re two points here. One is that if it’s easy to respond, then vendors respond faster so it helps projects go a little bit faster.
And the second reason is that sometimes vendor look at it and say, this is far too much work. We’re not even going to bother. So you want the vendors to bother. Because in one case I can remember just about twisting a vendor’s arm, saying please respond to this RFI. And they eventually, grudgingly did. And they were the ones that actually won the deal.
Will Bachman: I think RFI stands for what? Request for information?
Chris Doig: That’s correct.
Will Bachman: Can you explain the difference between an RFI and an RFP, which I think is Request for pricing? I’m a little fuzzy on the difference between those.
Chris Doig: Okay. An RF is actually a request for proposal. An RFQ, which a request for a quote, which is the request for pricing one. But here’s the difference. An RFI is a subset of an RFP. An RFI includes all the requirements and what you’re doing is you’re asking the vendor to tell you how well their software meets those requirements.
An RFP adds to that and says make a proposal on how we can buy your software. So it includes a whole lot of other things like the pricing and all that sort of thing. But at this stage of the project, you don’t need that information. All you need to know is how well the software meets your requirements.
Because at the end of the day, you’re going to eliminate everything but the top six products. So you’re really not interested in proposals from the other vendors, and that’s part of making it easier for those vendors to respond. You don’t want their proposal. You just want to know how well their software meets the requirement.
And I want to mention one other thing here. Is when you ask the vendor how well the software meets the requirement, many vendors will say, meets, and then write a qualifying comment which really boils down to doesn’t fully meet.
So what we do is we say to vendors, pick from this list. It fully meets out of the box, it fully meets with configuration, it fully meets with an add-on or third-party product, it fully meets with some code. And then you go down to mostly meets, partly meets, slightly meets, doesn’t meet, and maybe, future version. And that is factored in with requirements weight to calculate a fit score.
Will Bachman: Rather than forcing them to say does meet or does not meet. You let them say, well it meets it but we’d have to customize it a little bit so that they can be explicit about that.
Chris Doig: That’s exactly it. And what we also do is we say to vendors, don’t give us any comments. Because the comments invariably qualify their thing, and there’s no way to factor the comments into a fit score calculation. So we just get them to say how well the software meets the requirement.
Vendors sometimes are a little bit overoptimistic. So I’ll get on to this in a moment, but we use a process of auditing an RFI to verify the vendor was telling the truth.
So what we’re really doing at this stage is we’re asking the vendors to spend quite a bit of time responding to our RFI and telling us how well their software meets. Now usually there’s a lot of money in this and vendors are going to get a sale, so they’re prepared to do it. So we get their RFIs back and we stack them into this software tool we’ve developed that does the gap analysis. Now that’s the tool we originally started the company with. We’re now using it ourselves.
And what the gap analysis does is it calculates automatically how well the software meets the requirements and that allows us to rank the software by how they meet your particular requirements. So what it boils down to is you’ve measured how well these software products meet the requirements. And that means before you buy it, you know if you’re going to have any weak areas or any strong areas and that kind of thing.
The final step of the software evaluation boils down to this. Let’s suppose you had the gap analysis and no product scored over 70% on it. What’s happened then is your scope of requirements is too broad. Let’s say, for example, you had a whole lot of requirements and you needed to comply to FDA document management requirements.
Well, what you’d find is that none of the products you’re considering meet those requirements. And this goes back to that clinical management system I was talking about a moment ago, is all of those clinical trials management systems, or CTMS, all of them do document management, but none of that document management complies with FDA specs.
So what I’ve said to the client in this particular case, take those requirements out. You already have a document management system, even though you don’t like it. You’ve got it. All you need is to interface to that system to manage your requirements. And once they did that, the scores of all the products rose. And what that is, what you’re really doing here, is you’re adjusting the scope of what you want to match with what can be supplied products on the market.
Now that’s a very important step because what you’re trying to do is avoid the situation where you get a software product that does everything, but isn’t really very good at anything, and you don’t want that. What you’re really doing is you’re looking for products that have a fit score of, I like better than 90%. Not always possible. Sometimes you get in the upper 80s. But you really want to be buying something that is meeting about 90% of your requirements.
If you find something is meeting a 100% of your requirements, you’re probably going to be paying too much, or you haven’t done a very good job with your requirements. But that scope check rounds out the software evaluation. And does that make sense to you, Will?
Will Bachman: It does. So you evaluate the software. And then what wold be kind of the next phases? And I’m curious if you actually get involved in negotiating the pricing? So walk me through the whole rest of the process.
Chris Doig: Okay. The scope check completes phase two. Now we move on to the selection and purchasing. So you’ve got a list of products ranked by fit score. And what we do is sit with the client and we help them to shortlist the top products. And usually they take the top three. It’s not always the top three.
For example, we had one client who’s also in the pharmaceutical space and they said, “You know, there’s this particular product. It’s number two on our ranking but nobody else in our industry uses that product and we don’t want to be the first. So in spite of it being so good, we’re going to take it off the list.” So they chose numbers one, three, and four for their shortlist. So we helped them do that shortlist.
Then the next thing is the demonstrations. And the thing I say to clients, you know, is that your analysis makes your choice. The demonstration confirms that choice. So a lot of people make their decisions on the demonstrations, which is fatal because salespeople generate this reality distortion field, as someone describe Steve Jobs as doing.
But really, a good salesperson does that and you have to cut through that and know how well the software meets your requirements. That’s why you can rely on a demonstration to do a choice. The only time that the demonstration is used to make the choice is if the top three products have virtually identical fit scores, and then you might do it. But otherwise, the demonstrations are just there to confirm your decision.
So what we do is we take the client’s showstopper requirements and we build a demonstration script from that and we give that to the vendor who then does the demo. Some of them stick to it, some of them don’t. When they refuse to stick to the script, you’ve got to ask yourself why, and that puts big question marks there.
Anyway, at the end of the demonstration, we collect the demo feedback and we’ll do that for up to three demonstrations. More than three demos and people really get demonstration fatigue. For example, if you’re looking at ERPs, an ERP demo can last two days. So if you’re looking at three products, you’re looking at six days of demos spread out over two weeks, and that’s a lot to ask from people. So we keep it to a maximum of three.
Anyway, we collect that information and we set it up. So then we sit down with a client and we say, you know, here’s your gap analysis. Here are the products ranked by how well they meet your requirements. Here’s the feedback from the demonstrations from the users who attended. Now you need to make a provisional software selection decision. So the client will sit down and they may have a team. It might just be the decision maker, but anyway, they’ll make a provisional software selection. Very important, it’s provisional.
So what happens next is we take the evaluation from that product and we audit it. And we take all the requirements that the client calls a showstopper and that the vendor claimed to full meet. And we say to them, give us evidence that you fully meet this requirement. We want to see it in your documentation, we want to see it in maybe demo or training videos, and we want to see it maybe in a sandbox [inaudible 00:28:37].
But for all of these requirements, we want to see that you have the evidence that you meet it as you claim. Now, what we’ve found happened here is that sometimes the requirements score will drop slightly. So if I can just add here, because we’ve selected the requirements that the vendor claims to fully meet, the fit score is 100% for that selection for requirements.
Now when we ordered them, we find occasionally the fit score will drop slightly to 99 or 98. You can cut the vendor a little bit of slack there, because there’s always interpretation of requirements and things like that. But other times, and this has happened to me, we find that the score drops to about 80% for the sample of requirements taken. And then there’s also consensus we know the vendor has misrepresented the software.
So in one of these cases I went back to the vendor afterwards, and their score did drop by about 20%. And I said why did you claim you met those requirements when you clearly didn’t? And they said, we just wanted to get in front of the client to do the software demo. And this was from a very large and very aggressive software vendor who shall remain nameless. In fact, on this particular evaluation, two vendors have done that.
And so that is how the audit uncovers those things because if you don’t discover it at this stage, and you believe what the salesperson has put in the RFI, you’ll get to the implementation and you’ll discover it’s not true. But at that point, you’ve signed the deal and it’s too late to do anything about it. So very, very important to do it at that stage.
Will Bachman: So where would your firm kind of end your project? It sounds like you do not get involved in actually kind of the implementation of new software and you keep your focus to the selection and the negotiation and just the purchase of it, but not the implementation. Is that right?
Chris Doig: That is correct. That’s in phase four of the post-purchase but let me just finish phase three quickly, because there’s not much left. After the software has passed the audit, you’ve got to check the references and particularly with larger software products. You’ll get some references from the vendor, but you want to find references that weren’t supplied by the vendor.
So here’s a little trick that our listeners might like to use. What you do is you take the product and you search LinkedIn for it. And you find the people who’ve actually mentioned it in their LinkedIn profile. And then you reach out to those, and you’ll find maybe about half of them will actually talk to you and tell you something about the product.
And getting independent references, and if they say the same thing that the cherrypicked references do, then you know that the references are giving a good answer. But if they give completely different answers, then you have to pause and decide do we want to continue with this product?
Will Bachman: So this is a genius idea. So if you’re trying to evaluate XYZ ERP system, you would just search LinkedIn for XYZ ERP system and you’ll find some kind of mid level manager person who says, “I was responsible for implementing XYZ ERP system at my firm.” And then you go talk to that person.
Chris Doig: That’s exactly it. And here’s something else that you’ll find. If you’re looking at a niche product, you search LinkedIn and the only people who come up are folks who worked for that vendor. Then you know that this is a new product and you’ve got to ask yourself, do I want to take the risk of a new product or not? So it’s a way of independently verifying how good that product is.
Because honestly, if there are no people that mention that product in their resume, you have to wonder, is this vendor brand-new on the market? And we’ve actually had that happen in one case. We had a brand-new vendor and they looked like they were meeting the requirements exceedingly well. But at the end of the day, they had no customers on LinkedIn and the client said we simply cannot go there.
Will Bachman: Are there other websites or other sources of information where you can find user communities?
Chris Doig: Yes. Many of the larger products have user groups and very useful information and you can ask folks there. And the other thing you can do is you don’t have to just search LinkedIn. You can search any job board. For example, Indeed.com or something and you can find out which companies use the product.
For example, they may be looking for an admin for a particular ERP system or something like that. You know they’re using it and then you can reach out to an IT director at that firm and ask them. That concludes the references and you make your decision. Sometimes the top product will fail and then you’ll go to the number two product. And we’ve actually had two products fail those checks on a project. And we dumped them.
Will Bachman: And what’s your view on going to any of the IT analyst type information firms?
Chris Doig: You mean like Gartner? Very, very useful information. But the problem is those analysts always write for the general user. They never write for your particular needs. So they are very useful when you start the project, but they’re not useful when you get to the end.
For example, if somebody said I bought product XYZ because it was the top right of Gartner’s magic quadrant, all they’re saying is, I didn’t do my homework and I’ve taken a chance. And you can guarantee with 99.9% certainty, that implementation is going to be late and users aren’t going to be satisfied with the software. So that’s where they fit in.
The final step of the selection and purchases is the actual purchase. And what we’ve done is we’ve compiled a lot of requirements based around software contracts. For example, here’s one of interest. SAP, one of the ERP giants has just started charging clients for indirect usage to their software.
For example, there’s a company in the UK that sells alcoholic beverages that took them to court. Now this company’s name is Diageo and you can search for it. It happened in about February this year. And they had an SAP connected to their sales force system. And SAP said every sales force user needs a full SAP license. They went to court and SAP won and this company has to pay for about 70 million dollars, almost, to SAP for indirect usage.
So you know, these things need to be written into contracts and we have compiled a list of many of them. But to be honest, you know, if you are going to be spending 10, 20, 30 million dollars on software selection, it pays to get a software license specialist in there because these people do these things all the time and they’ll save you an immense amount of money in those kind of things.
But that wraps up the purchase. We can now move on to the final stage, which is the phase four, the post-purchase. And this is very, very important. So what we do is we take the evaluation that was selected by the client and we export that. And we give that to the implementation consultant.
Now recall, we’ve done a very detailed requirements analysis using reverse engineering, so we have captured all significant requirements. So the implementation project manager can then look at this plan or look at this information and then that person can work out how much time it’s going to take to implement the software. For example, all the requirements that require configuration are listed.
Now, based on their experience, they can estimate how long these configurations can take. For example, they know how many days it’s going to take to set up a chart of accounts, et cetera, that sort of thing. So they go through, and they can give you, they use this as a major input to estimating their project so you can get a realistic project implementation plan time scale out of it. That’s the first step on helping the implementation to go on plan, is have a realistic plan in the first place.
The second thing that happens with us is that the information you collected in the requirements, who wants it, why it’s wanted, and how important it is to them. That goes over to the implementation consultants. So when one of these consultants sees something that is a showstopper requirement, they know they must get that particular requirement right. Very often, why it is wanted is enough information to answer their questions.
But if they need more information, it’s got the names of the people who want it and they know how to reach out. Now, if it’s a small company of say, 200 employees, knowing who to reach to isn’t going to matter much, but if it’s 2000 employees, that can speed things up. Because what happens is it’s the questions these implementation consultants need to get answers for. That takes time, and it’s those delays that start adding up and slowing down the implementation.
So by sort of pre-answering these questions, giving them that information, you reduce the amount of questions they need to ask and they can do the whole job a lot quicker. And at the end of the day, you can actually implement an ERP on the project schedule. And that doesn’t happen very often. And that really wraps it all up.
Will Bachman: Let’s talk a little bit about how you generate leads for your firm. So you have a pretty narrow focus, you know, you’re not doing all kind of IT consulting or all software consulting. But really helping select these ERP systems. How do you build awareness and get leads for potential client projects?
Chris Doig: That is the $64,000 question, and that is one of the toughest parts of the job. And what we found most effective is working with personal networks. In other words, we actually have somebody who is responsible for business development who is going out and meeting people.
You know, for example, bankers. Bankers often finance software acquisitions and they can put you in touch with people who are selecting software. Because our problem is we have to get people when they are thinking about the project. Once they have started it, it’s almost invariably too late unless it’s going seriously wrong. That’s one thing.
Another thing is, I’ve written a book called Rethinking Enterprise Software Selection: Stop Buying Square Pegs for Round Holes. That should be published on Amazon in I hope, about two weeks. I’m just doing the final proofreading at the moment. I write for CIO.comj. That has generated quite a few leads.
But things like books and writing for CIO.com, they are very slow in generating leads. One thing that’s particularly effective is the speaking. For example, I’ve done some speaking at Vestige, if you know of them.
Will Bachman: Yes.
Chris Doig: I speak at Cloud conferences and things like that. And the thing is, and this I learned from somebody by the name of David Fields, who is the consultant’s consultant. But anyway, he said, when you’re at a conference, you don’t want to speak at the [inaudible 00:40:44] session. You want to speak at a breakout session, because the folks that attend your session will be interested in your subject and you can focus on them. And some of them will turn into leads. So that’s really what it boils down to is really working on relationships is the primary method of getting business.
Will Bachman: And David, I’ll point out, is a good friend of mine as well and the very first guest on this show. So if you want to hear more from David Fields, listeners can go back to episode 001 of Unleashed. And his book is great, The Irresistible Consultant’s Guide to Winning Clients. So good advice from David.
So you’ve got a book, you’re doing speaking. I’m curious, for independent professionals or people running boutiques who might be listening to this show who have a client that might be facing this at some point, how do you partner with independent professionals or other boutique consulting firms? Could you talk about that a little bit?
Chris Doig: Okay, we actually love partnering with other folks. And the way we work is when we price out a project, we price it out based on the value the client. And again, this I learned from David Fields. Because if the client can’t see the value, they’re not going to be interested in paying for it. And what happens is that clients like that, something will come up, you know, they’ll have a week court or something and they’ll cancel the project. And you don’t want to go there. So base it on the value of the client.
And then we end up with a revenue-sharing arrangement with these folks, so we’ll pay them a percentage of the project, that kind of thing. And secondly, sometimes we can actually use these folks in the project itself because what we have is subject matter experts.
So if we were doing an evaluation for a company that does meat trucking, for example. Very specialized, refrigerated trucking, that kind of thing. We might find somebody who personally referred the business to us, might already be a specialist in that area. So the subject matter expert actually as two very important functions in the evaluation.
The first is that they help write requirements because they often know many of the products in the industry. And the second thing is when weighting the requirements, they provide perspective. They say, you know, have you considered the case when? Or you know, you want to do X in three years’ time, then you’ll need this for X. And so they help immensely.
And actually, there’s a third place. And this happens sometimes, is that when the project is implemented, sometimes the client wants a project manager to represent their interests on the implementation team. And then this person often is in a good position because they know the requirements very well at this stage to be the project the manager. So they’re really three sorts of ways in which we share the revenue from the project with fellow consultants.
Will Bachman: Great. I had a couple of questions that aren’t tied necessarily directly to what you do. I’m always interested in how professionals like yourself continue your own professional development and your own learning. Could you talk a little bit about that, about what you do other than just the project work itself to continue learning about your field and building your own skills?
Chris Doig: Well the most interesting thing here is I learn an incredible amount from my customers. Every time I think, well now I’ve got there, I know just about everything on it, I am humbled because I don’t, a customer will say something and I’ll start thinking about it and suddenly a whole new avenue will open up. You know, it’s things like the auditing of RFIs.
That came out of dealing with life science customers. I was talking to one of them and I mean, I have a life science IT background but I was talking to one of them once and the conversation came around to that and suddenly the light bulb went on in my head. So what I found is talking to customers helps immensely.
Second thing is I found writing is tremendously helpful because it forces you to think through ideas. So I’ve been writing for CIO.com for several years although I’ve slowed down recently because I was doing the book. In writing those articles, I’ve taken various thoughts and kind of expanded them, talked to folks about them and then put all that in articles. I found that very, very useful.
And the other thing is, of course, reading. I don’t have a particular regime that I follow with reading, I just follow stuff that looks interesting. But I find that you’ll be reading things are that tangential to your field and something one of the authors will say will spark off a thought in your head and then you go and expand that, maybe even turn it into an article or something. But I really find that helps immensely.
But the thing is, what I’ve discovered is that, I mean I can never claim to be a thought leader but I’m definitely at the front there. When you’re in a thought leadership position, then you can’t really learn from other people directly. You learn from them indirectly. You take what they’ve said and you see how it applies and that’s where thought leadership comes from, when you’re thinking of new ways to apply what you’ve learned and things like that.
So that’s really how you’ve got to develop, because if you’re on that leading edge, you will learn from other people. Don’t get me wrong. But you’ve really got to take what you learn and you’ve got to extend it and that’s how you become a thought leader.
Will Bachman: So Chris, you’re running a busy firm. You’ve written a very detailed, exhaustive book on this topic. You know, and you’re serving clients. Talk to me a little bit about how you manage your own to-do list and all the things that you’re getting done. Do you have a morning routine, a way you start the day off right or would just love to hear about how you manage your action items and your daily to-do list, and how you get things done.
Chris Doig: That’s a perpetual bugbear, that one. I tend to be a morning person. I sometimes get up at 2 a.m. and write for several hours or work on a client project or something. But I tend to go to bed fairly early. I mean, that’s just me. I’ve worked with people in the past who’ve been programmers, or night owls, you know? They start at 9 or 10 a.m. and they’ll finish at 12 or 1 a.m. and they can be immensely productive, but I’m a morning person.
I’ve tried using all sorts of tools. I’ve tried using Asana for managing tasks and it sort of works for what I’m doing. I think it’s a pretty good product but for my particular needs I’ve always found that if you use some sort of task manager, it never really works if it’s just restricted to you, because there are always things where, you know, you’re waiting on somebody else to give you some input. And then how do you do it? How do you notify them and that kind of thing?
I have to say it’s a problem I’ve never really solved to my satisfaction. I’ve loved looking at software tools but I’ve never found something that really works for me. And the thing with many of these things, it’s very personal whether it works for you or not. Like many people, I make lists. I find one important thing is keep focused, but don’t over commit yourself in the amount of work you’ve got to do.
And the other thing is delegate. You know, in my company about a year and a half ago, I hired somebody to actually handle the sales side of things. This person is the consummate networker. I find I’m, I don’t know if you’d call me an introvert or something, but I find constant networking and having to do things like writing and working for clients, it’s just too much.
So I was able to delegate the networking to him. And that means the thing there that really matters for individual consultants is that when you’re working on a project, you stop marketing yourself, so your income tends to go down. And you get to the end of the project and you can face a dry period. You’ve got to kind of drum up business again. Whereas if you have somebody who works and does the business development while you’re working on the clients, you can keep the work coming in. That I found very useful.
And the other thing is delegating low-value tasks. You know, things like accounting. Don’t try and do everything yourself. Do what you’re good at and delegate the things that you might find interesting, you might even enjoy doing, but if it’s not your forte then delegate to somebody who it is their forte.
Will Bachman: The last question I wanted to ask, Chris, is how can listeners find your firm online and how can they get in touch?
Chris Doig: Okay. Well, very easy. Our website is wayferry.com, W-A-Y-F-E-R-R-Y dot com. And they can shoot me an email. It’s cdoig, C-D-O-I-G, at wayferry.com.
I’m happy to help people because my mission is to help people do these things. If you end up becoming a client of mine, that’s great. But really, I’m more than happy to share my expertise because really, people make so many unnecessary mistakes in this area and I view my mission as educating folks first, and then some of that spills over into business for me. So don’t be afraid to ask. I’m more than happy to chat to you and advise you and steer you and your clients, or something like that.
Will Bachman: Well, Chris, thank you very much for joining this. This was really a fascinating look at this, you know, very kind of specific process that is so important to firms to get right. And you’ve gone deep on it and have a tremendous amount of expertise. So any listener who has a client that’s going through this process, it seems like Chris would be a good person to loop in. And thanks so much for joining.
Chris Doig: Will, thanks so much for having me. It’s been an absolute delight talking to you.