Tech Manager—Buying Technology, Part 1
Your firm’s staff members want the latest features and dependable software. Management wants efficiency and deliverables completed on time. Clients want creativity and revolutionary designs, within budget. Tech Managers want tools that satisfy all of these.
When it comes time to buy more software or hardware, it needs to be justified, researched, tested, and an obvious improvement over what you have now. You need to have a good process for finding and vetting your purchases. No one wants to toss money at you. No one wants to spend money on tools that do not work or are not used. You need to spend wisely.
The Tech Manager is charged with supporting organizationally owned or acquired computer hardware, software, and peripherals in ways that meet the strategic priorities. Your firm is a highly interconnected design entity and is dependent upon secure and reliable technology to meet the needs of the client.
In a proactive effort to be wise stewards of tech resources, you should do your due diligence when acquiring technologies to support design teams. It must be compatible with existing systems, be efficiently supported, and bring new techniques, solutions, and tools to the process of design. You may have negotiated numerous purchasing agreements with hardware, software, network, and telecommunication vendors, service agencies, multimedia companies, software developers, and others. In order to take advantage of these contracts and ensure that your technology purchases meet standards, you must be involved in all information technology-related acquisitions.
But I find that sometimes those who are not in the tech management world think that a quick demo and suggested solutions are enough to send you hurtling down the purchasing chute. “Buy it, install it, give it to us” is what you are hearing. That is the cry of your users and management. Just get it working. But you need to do some homework (and so do they) before moving forward.
Due Diligence
Due diligence is needed. There is a need for rational, reasonable investigation into the desired purchase to verify that it can and will perform as expected. I have developed a long list of questions that need to be answered by me or by the person/department requesting the purchase. Some of these questions may be answered quickly while others will take some time. Your goal is to get definitive answers so the need can be defined, the solution framed, the research focused, and the outcome ensured.
Here is a list of some of the items I like to get input on and why I need it. People look at new technology from many angles. Does it help me get my job done? Does it do something I cannot do now? Does it not fail like the existing tools might be failing? Does it make us more efficient? Can it open us up to new markets? So many things might be going through the heads of the buyer, but not necessarily what you need to know. Some of your questions are to get them to think through the effort and others are for you to prep and deploy with expectations of success.
Ask Yourself and Others
Already Own It – what other tools might we already have that answer this need? This is the first thing I ask myself and have others think through. Many times, one office or department does not know what is available or in use elsewhere. You have a great view of all the tools in use. Ask the requestor if “such and such” tool might do the job. If you already own it, but not in their office, can you borrow the software or reassign it?
Applicability – why are existing tools not sufficient? If there is a tool that you think might do what they need, have them tell you why it is NOT the tool that fits. Don’t just let them chase the new and shiny, have them define why the old dependable is no longer good enough.
User – who is the end user? Designers? Managers? Engineers? You need to know who might need the software and the length of use. Project kickoff, design phase, documentation phase, and/or construction phase. Who will be using it and when? This helps you know if you can buy bundled tools, short-term tools, or those for the long haul.
Quantity – how many licenses are needed? List all sites that will need this software. Do these sites know they need the software? Is the requestor thinking too broadly—“Everyone needs this.” Maybe so, but do they all need it now? Can you buy in chunks? Licensing can be concurrent user, subscription, device install, or others. This info defines the number needed.
Timeline – when do they need it? Have them provide a date, not just “today.” I frequently say that “ASAP” is not a date. You need to know when they realistically expect to have it. This often leads to a discussion of the buying and delivery timeline, plus the install and configure timeline, which needs to happen prior to getting it in their hands.
Duration – how long will this need last? Is this a short-term need or long haul? You will need to know how long to negotiate a license/maintenance agreement. Again, this may impact the type of licensing you select. Short-term, subscription-based licensing might work.
Business Value – how does it support the business goals? This question forces the person to think broadly. Think beyond the current dilemma or project. It encourages corporate thinking. It moves the conversation beyond being about them and their team. It is about the firm and where we might be headed.
Best in Class – is this the best tool for the job? A lot of vendor demos say they are best in class. How do you confirm this? What have you been hearing? Are other firms talking about this solution? Has your requestor heard of this tool in multiple places? Are others using it? You may or may not want to be the early adopter of new tech. Keep that in mind.
Shareability – can others collaborate/see/use my data/files? I am not sure that “shareability” is even a word, but is this software creating a proprietary format that others cannot use? Does it export and import other formats? How will the files interact with other software you have in place? This, again, moves the user from getting “my” job done to getting “our” job done.
I will provide more ideas for vetting new tools in the next article. Until then, be sure to enlist others in your research, prepping, and due diligence prior to buying new tech.
