Working with small businesses, I often find that the person designated to be my point of contact on a given project is made responsible internally for the success or failure of the project, but has no technical knowledge whatsoever. I am accustomed to mitigating this kind of situation by translating a lot of the technical aspects of the project into business-speak and by keeping the project sponsor well informed. But in many cases no matter what I do, the poor fellow just seems overwhelmed, scared and unprepared to communicate with a technical professional. Over time I’ve come to notice a few things that the best-prepared and most successful non-technical workers have in common when it comes to dealing with technical professionals like myself.
I’m sure this will all seem obvious to any technical worker, but this article isn’t for you; it’s for the non-technical guy whose boss makes him responsible for getting a technical project done, who finds himself besieged by a bunch of geeks speaking a different language and doing things he doesn’t understand. Hopefully this little bit of advice will help alleviate some of the pain that often accompanies working with a technical service provider.
1) Know Your Business
Before undertaking any technology project, you must know two things: a) How the portion of your business that will be impacted by the project works now, and b) How you want that part of the business to work post-project.
This may seem so elementary as to not merit mentioning, but it must be said. I am always amazed at how few businesses have a clear picture of their internal workings. On more than one occasion I’ve been in a requirements gathering session with clients who are arguing amongst themselves about what their processes are. Make no mistake – you absolutely cannot get underway with any technology project until you know what is happening today and what you want to happen tomorrow. This is not to say that you should not also allow your technical service provider to map your processes your own business process knowledge is a supplement to the provider’s discovery process, not a replacement for it. A third-party analysis of your business can often reveal subtleties that you miss due to the classic forest/trees effect.
If you yourself are a project sponsor, make sure you know your business backward and forward. And if you are the manager responsible for delegating oversight of a technical project to one of your non-technical employees, make sure you delegate it to someone with good domain knowledge.
The best case scenario is that you select a competent enough provider to simply turn over the entire project without dedicating any of your employees to oversight. However, this is sometimes not realistic, so be certain to do your homework on your own business. If nothing else the perspective will enrich your performance at work.
2) Select a Provider Carefully
It can be hard – very hard – to reliably select a technical service provider. The ubiquity of PCs and computer books have produced a glut of self-described “developers,” “consultants” and “network administrators” who are not truly qualified to do any project that has the operation of a business relying upon it. This leads to an environment of considerable uncertainty when you area non-technical worker who is tasked with making a technical project happen in your workplace – how do you know who to trust when you don’t have sufficient technical knowledge to verify a potential provider’s competency?
If you’ve ever read The 5 Laws of Choosing a Software Developer, you probably won’t be surprised to learn that those laws apply to choosing a web designer, network admin, or any other type of technical service provider. I suggest you read the whole “5 Laws” article, but the basic 5 Laws are:
- Demand Experience
- Demand References
- Demand Value
- Demand Communication Skills
- Demand Availability
I cannot overstate how important it is to select the right technical service provider. Not the cheapest one, not the best-dressed one, not even the most talented one, but the right one. It is very much a matter of fit. Once you’ve chosen a technical service provider, trust and listen to that provider – if you did your due diligence before making a choice, this should be easy.
3) Demand Outcomes, Not Technologies
I’m always suspicious (but empathetic) when non-technical clients contact me to say “We need a Javascript application” or “We need a SQL Server database” and with good reason – when you visit the local car dealership, do you ask for a car built by an ABB industrial robot? When you buy a computer, do you ask for one whose hard drive heads were cut by a Haas Automation CNC machine? Of course not – you ask for a car that gets better than x miles per gallon, or that has heated leather seats and a navigation system.
The means and the outcome are two distinct issues, and should be treated as such.
For maximum results, your focus as a client should be on the business-enhancing outcomes you want from your technical project. You are the expert on your business – the technical service provider you select is the expert on making technology support business needs. Talk to your provider about your desired outcomes, and then trust the provider to determine the most appropriate means to achieve these outcomes. Obviously, if you are in a company that has already heavily invested in one particular kind of technology (whether you’re a UNIX and J2EE shop or a Microsoft shop), you’ll need to make this known and it will certainly factor into your service provider’s recommendation.
Once you have communicated a set of desired outcomes, stand by them. If you have chosen your provider wisely, they will be able to understand your business and deliver the results you’ve asked for. There is no acceptable excuse for nonperformance.
There are undoubtedly many other things that a non-technical worker can do to be prepared to handle a technical project; the three I’ve listed here seem to be the most common denominators of success amongst the clients I’ve worked with.