How should firm leaders make go/no-go decisions on whether, how and where to spend on technology?

Discussions of technology can quickly get bogged down in a rabbit warren of tools and technical jargon. Even tech-savvy leaders can be challenged by the complexity of deciding where to allocate precious financial and human resources in building the right design, financial, communication and operational technology platforms for their organizations.

The stakes are high when considering large-scale systems. The right decision can improve essential design and business functions. The wrong ones can be costly in cash, staff time and the derailing effect they have on other important initiatives.

So how should firm leaders make go/no-go decisions on whether, how and where to spend on technology? The answer is threefold: leaders should have a set of principles to guide them through analysis of technology decisions, develop an appropriate set of requirements for systems and software, and know the right questions to ask.

Principles provide the framework for investigation and decision making that can be applied to technology questions. They pertain to all types of technology and are universal enough to be relevant throughout the mind-bending pace of technological change. Principles are founded in the five key areas of running a firm: marketing, operations, professional practice, finance and leadership. They are the basis of requirements and smart questions that can take much of the mystery and guesswork out of technology decisions.

Some examples:

  • We are leaders in professional practice who see technology as a fundamental competitive advantage and strategic asset
  • All technology systems must be appropriately redundant; the failure of any one system should not cripple our firm
  • Investment in technology systems must yield a measurable return on investment through greater efficiency, labor reduction, increased capacity or better projects

Requirements describe what you need the system or software to do. They should align with your principles and thoroughly detail what the technology must accomplish for the firm and the user.

One example could be a customer relationship management (CRM) system to support business development. Assuming that you have (or are developing) a well-defined business development strategy and process, you will see whether the general capabilities of the software aligns with the way you target, acquire, and manage client relationships.

Then it is time to thoroughly visualize how the system will be used, imagining specific scenarios (known as “use cases”). In our CRM example, the principals or partners responsible for business development may travel extensively. The system, therefore, would need an easy-to-use mobile interface that allows the partner to capture the essential information you need in your business development process.

What do you do if most of the system will work well for your organization but there is a discrepancy between your needs and the software’s capabilities? In some cases, it may make sense to alter your process somewhat to match the tool before considering costly modifications or customization. Violating your basic requirements is the threshold not to cross.

Perhaps the most valuable tools in evaluating systems and software are key questions, which come in several different categories. Your requirements will create a detailed list of capabilities questions that address what you need the system to do. Other important categories include value, implementation, and risk questions.

Value questions ask how the system will either remove waste, increase capability, or provide other types of less measurable benefits. For example:

  • How large will the return on investment be?
  • How long will it take to recoup the investment?
  • Will it enable process improvements?
  • Will this enable us to create more value?
  • Will this enable us to be more productive? By how much (and how will we measure)?
  • Will this enable the creation of valuable intellectual property?
  • Will it provide other benefits like improved quality of work experience?
  • Will it enable us to be a learning organization and stay ahead of what is next?
  • Will it improve the design and delivery of our projects?

Implementation questions deal with the practical aspects and ramifications of installing systems and training staff:

  • How much investment will be needed to retrain staff? Set up systems? Convert data or files?
  • How much time will we need between installing the system and using it to its full capacity?
  • Will this software integrate with other data systems?
  • What are the ongoing maintenance requirements?

Risk questions help you identify, evaluate and mitigate potential hazards:

  • If this system were to go down completely, what effect would it have on the organization?
  • If all my competitors had this and I did not, what would happen to my business?

The list of questions goes on. Once you have developed your principles, requirements and key questions, you might want to consider one final criterion to ensure your process and systems are properly designed: is the solution simple enough to explain to a second grader?

Bob Fisher is a contributing editor to DesignIntelligence.