Five things CIOs should demand from IT consultants

Here are five things that every CIO should demand from any consultant or consulting firm that walks through the door.

Although I've spent most of my career working in traditional IT departments, I've spent a bit of time in other roles, too. I worked about a year in the engineering department as a systems engineer for a financial services company (and, as a result, a client of the internal IT department rather than a member), and I've also accomplished a number of independent consulting gigs.

I've seen a lot of bad IT consultants in my time in the industry -- from people who couldn't deliver what they said they could deliver to people who just didn't have a clue about the environment. These interactions damage the credibility of both the CIO and the consultant. The CIO gets a bad rap for not getting a particular job done, and the consultant gets a bad reference.

Consultants come in all forms, from the IT operations consultant who reviews the department as a whole to the technical subject matter expert lending a hand on a particular task. Regardless of the level of engagement, there are some things that should be common for all consulting engagements.

Here are five things that every CIO should demand from any consultant or consulting firm that walks through the door:

1. Verifiable references that include both technical and personal recommendations. Obviously, consultants are generally brought to bear because of their technical ability, but this shouldn't count for everything. While organizations need to make sure that the consultants brought on board to handle a particular task have the knowledge, skills, and experience to accomplish that task, make sure that the consultant has at least a loose fit with the people with whom he'll be working. After all, if a consultant comes in and doesn't talk to anyone or only half listens to the internal folks, it increases the likelihood that something will be missed or that there will be miscommunication. While a consultant's "fit" isn't nearly as critical as it is for full-time hires, it needs to take at least a minimal role in the selection of the consultant.  Make sure that the consultant -- or the consulting firm -- can provide references that support your technical requirements and ensure that the consultant at least has the ability to interact with internal staff in a way that results in a positive engagement. 2. Full transparency and follow up documentation. A consultant shouldn't walk out the door without providing you or your staff with full and complete documentation regarding the engagement, or at least an expected time frame for such. During the consultant's time on-site, there should be at least semi-regular communications flow... in both directions. Make sure you and your staff know what's going on and are involved in any technical decisions that are being made. After all, it's you and your staff who will have to clean up the mess if the consultant leaves and something isn't working the way you like. Worse, if the consultant leaves without providing a report and there hasn't been complete transparency during the engagement, critical information might be lost. 3. Time to outline the organizational priorities that the engagement is supporting. From a simple Exchange server implementation to an engagement reviewing the entirety of the operations of the IT department, the CIO or her delegate should have at least a short opportunity to help the consultant understand the bigger scope of the engagement. This is particularly important for those higher level engagements. An operational consultant who doesn't understand the organization's priorities is a consultant who can't provide an assessment that aligns with business goals. 4. Respect for both the CIO and the IT staff. I've seen some seriously condescending consultants who walk in the door with an air of superiority and supposed knowledge of, well, everything IT. In almost every case, these people were debunked as frauds when it came time to show results. On the other hand, I've also seen a consultant brought it at the behest of the CIO who was treated pretty horribly by the incumbent IT staff. In both directions, the people involved need to lose the attitudes and get the job done. The consultant needs to drop the condescension and the IT staff needs to get over the territorial issues and make sure that the consultant has an environment that is conducive to success. Of course, not all consultants have holier-than-thou attitudes, but those who do need to check it at the door and bring an attitude that will help the organization move to a successful position with regard to the engagement. 5. Push back when we're on the wrong path. All of this said, the ultimate job of a consultant is to complete the task at hand. In many cases, consultants are brought in to augment skill shortages in the IT department. As such, consultants often have deeper knowledge in their specialties than the internal folks.  In other cases, consultants are brought in to augment a people shortage and have knowledge that's equal to existing IT staffers who simply don't have time to complete a particular project. In either case, the consultant does deserve some deferential treatment, particularly when there is an internal skills deficit. In fact, CIOs who engage consultants should demand that these subject matter experts push back if local IT makes demands that are contrary to goals. As you might expect, if the client insists on -- in the opinion of the consultant -- going down the wrong path, there should be written notation just in case it all goes to heck.


These are five basic courtesy items that should form the basis for every consulting engagement. In my next article, I'll talk about five things that every consultant should demand from the CIO.


Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...


You make some excellent points. When I'm called in by an Executive Director or CEO to evaluate how the CIO's IT department is functioning in small to midsize organizations, it inevitably means the CIO has lost the confidence of the rest of the executive team. That often happens because CIOs are too focused on the technology, which of course IS critical, but not enough on how IT can support the mission of the organization. So by the time I arrive, the CIO is usually toast by definition. (Of course had the CIOs commissioned the assessment themselves, I could have helped them identify areas for improvement, including their relationship with their executive peers--but they never do.) That said, once the engagement begins, it is critical to establish trust with everyone I interact with. That means that if a staff member--and I interview many non-IT people to determine how well the IT staff is performing--tells me something in confidence, I have to respect that confidence, while making sure that the points are heard by management. Usually I can tell if that employee is the only one with that specific knowledge, and thus that fact in my report would inevitably point to only one person, or whether it can be attributed to a group of people. If necessary, I ask them that. To get the information I need I guarantee that anything sensitive will not be attributed to a specific employee who might be retaliated against. The information is in my detailed interview notes, but I organize and extract the information that goes into my report--management does not get to see the detailed notes. Early on I provided 100% of my findings and had management embarrass people in public meetings, so I learned not to do that. You don't have any control over your report once you turn it in. I would also like to point out that if I uncover a significant issue, it has to be communicated to management--that's what I'm there for. I've never found a case where I couldn't reconcile the need for the interviewee's privacy and the need to point out an issue in my findings and recommendations. But establishing trust and not violating that trust is essential in doing a thorough job. One last point. I have done some of these studies through third parties (the work is for their client), and in one case I had a disaster where the third party insisted on watering down the findings and distorting them so they were useless, because they were horrified by my blunt, dispassionate findings. They're a consulting company themselves and are in the habit of stroking their clients, so they had difficulty with a report that mentioned IT processes that worked well, but that focused on the many out of control processes that needed immediate attention. While you don't want to be sarcastic or caustic, you also are being paid to tell the truth, whether positive or negative. If you can't live with that, you should be in marketing instead. :-)


You mentioned documentation and communication, which are important and related to this. Sometimes there also needs to be deliberate and explicit knowledge transfer to internal IT staff so that they can maintain the system or implement future changes.

Editor's Picks