From day one, IT consultants should ask about and document clients' business objectives before suggesting fixes for the current solution.
Somewhere on the way to Innovation and Efficiency 2.0 the importance of documentation is being lost. This is a big problem for technology consultants, whose job is to do more than fix things that are broken. When consultants listen carefully to clients (and perhaps read between the lines), they'll discover clients are also asking for help addressing business objectives.
Start the process at your first meeting
Documenting business objectives should be the first step you take when meeting a new client. Before designing a new multi-site network, installing a server, or rolling out a router, IT consultants should create associated Visio diagrams and credential documentation. Unfortunately, my consulting office rarely encounters a client who possesses business objective documentation produced by previous providers or in-house staff.
This lack of documentation may be the result of pressures to prove efficient and move quickly, leading some tech pros simply to react. Nevertheless, some consultants hear one thing and immediately think another. Need an email platform for a small office? Microsoft Small Business Server it is. Need a new electronic medical record or electronic health record package? Go with the one you know. Fire up the SQL Server design formulae. Need a new accounting system? Time to call Intuit.
It's never that easy. Micro client offices with eight users might best tap a hosted Exchange solution. The best medical system for a client might be a cloud-based solution. Still another client might be best served integrating its accounting software with a preexisting SharePoint environment, in which case Intuit may not be the correct choice.
What to ask the client
Tech consultants should instead determine how the organization's business needs changed since the current server was deployed. Consultants should explore how the organization's user load evolved, whether new vertical industry packages were added, and how daily workflows have changed since the original IT systems were architected and deployed. Further, consultants should review the client's plans for growth and expansion, while weighing the likely impact of economic trends, evolving market conditions, and legislative changes on the client's business.
All new client meetings should include these questions, with significant energy devoted to documenting the answers. Consultants should look at existing infrastructure only after business needs and objectives, market conditions, user loads, anticipated business growth (or reduction), typical vertical package requirements, and overall systems integration elements and requirements are reviewed. Once the business needs and objectives are documented and current infrastructure noted, the consultant can provide a map of recommendations and costs needed to bridge the gaps.
Consultants shouldn't let the process become overwhelming, however. It should take an hour to create a simple Word template, with appropriate tables for collecting the answers to the commonly asked business objective questions; this template will save considerable time and prevent consultants from having to re-invent the wheel each time a new client meeting is held.
The end result
The documentation this process produces is invaluable. A client might answer a key question regarding user load or system functionality when their attention is elsewhere (e.g., driving). By documenting needs, requirements and benefits, and by forcing a review of the documentation before expensive investments are committed, consultants can ensure client dollars are spent wisely and, ultimately, ensure systems usability tracks best to client business needs.