This article defines and explains what we mean by “Technology Engineering.” There are two basic types: 1) technology used internally to make your business or agency go and grow; 2) technology provided to customers as a revenue stream for your business, or as a service to your constituents. Either way, it is the disciplined practice of figuring out whether to build, buy or rent. Within Technology Engineering, 3K3 focuses on six critical elements:
- Requirements
- Technology assessments
- Product analysis
- User applications
- Tool development
- Resource acquisition
Requirements: As with any planning process, the first thing to consider when performing technology engineering is a requirements analysis. What does the technology have to do in order to be a good investment? Is it purely something to save money by helping you perform better, faster and/or cheaper? Or is there a strategic reason to have the most advanced technology in order to have a competitive advantage as a market leader? Also, are all the requirements actually required? Or are some things you consider to be requirements actually optional features? These are some of the questions you need to answer, and others will surface during the requirements analysis. This applies whether you are working on an internal technology issue, or providing technology as a product or service to your customers.
Technology assessments: So now that you have at least a solid draft of the requirements, you should perform an exhaustive industry search to discover whether technology already exists that could solve your problem. If you want to build something to provide to customers, you likely know your primary competitors, but there could be others out there with a better mousetrap than yours. Sometimes this can lead to a good merger and acquisition opportunity. If a competitor has something it is willing to sell for the right price, you may be able to incorporate it instead of reinventing the wheel and trying to take market share with your product.
Product analysis: Again, assuming you are building something to sell, once you identify the other products out there on the market, you need to analyze not only the products themselves, but the companies that make them. What technologies were used as the foundation for the product? And what will be the lifecycle cost of the product if you buy or license from someone else versus maintaining yourself? If you create your own product, are there opportunities to license it to external users as a revenue stream? Or is it better to protect the technology and simply use it for your own production advantage to create deliverables more efficiently?
User applications: User applications are the suite of software programs that accomplish the overall goals based on the requirements and analysis steps in the technology engineering process. This may include custom hardware to support the software tools. The bottom line is to find the right solution to address the issues with which you are dealing. And once again, you must determine what the costs will be to internally support applications you build versus simply paying someone else’s maintenance fees and technical support charges.
Tool development: Overall, user applications typically evolve over the life of a program through development of specific software tools to further increase efficiencies. In other words, as user applications gain acceptance and widespread use, people begin to ask for additional capabilities. Shortcuts can be created to reduce the number of steps in a process, or automated QA/QC procedures can be introduced through specific tools, or specific deliverables can even be generated from software tools.
Resource acquisition: How you actually acquire the technology resource(s) depends on whether you implement it internally or externally. If internally, you must budget for continued development and support to match the lifecycle of the product need. In other words, if you are developing technology for a “one-off” specific project, there may not be any long-term funding consideration. But if your technology engineering project supports an on-going business function, you must consider the long-term costs. Moreover, if you have elected to hire a third-party to perform the work, you must have plans in place in case that person or company goes away. Protecting the products under a third-party arrangement not only includes consideration for exclusivity (i.e. can they resell this product or something similar to others?), but also things like placing software source code in escrow in case the company goes bankrupt or the actual developers leave. On the hardware side, you must consider the production issues and ongoing support requirements for the product line. Of course software and hardware manufacturing standards must be considered, depending on the industry you are in and who your end users are.
In a previous life, we were part of a management team that used Technology Engineering to our advantage for many things:
- Bike-based GPS: We designed and helped build a bike-based GPS data collection system in 1996 for critical asset data collection and management of above-ground utilities including telephone poles, telephone lines, street lights and cable TV. This saved utility companies more than $1M per year and accelerated mapping delivery schedules.
- Airborne LiDAR: We were part of a group that co-developed an airborne LiDAR system back in 1997 as a means to produce high-quality digital elevation models (DEMs) for digital orthophotography. This led to large-scale LiDAR-based elevation mapping for things like the updated FEMA flood mapping program, which has saved millions of dollars as compared with the old methods. This effectively revolutionized the FEMA floodplain mapping program.
- IENCs: We helped pioneer the first Inland Electronic Navigational Charts (IENCs) in 2001 in partnership with the U.S. Army Corps of Engineers. This set the standard and provided safer navigation for inland waterways across the USA.
- Distributed Image Processing: Our team designed and built a hardware and software solution for distributed image processing from 2003-2005 to perform overnight processing and delivery of mission-critical imagery, such as the imagery immediately following Hurricane Katrina that was used to save additional lives in the rescue efforts.
- Mobile/Field Mapping: As part of a development group, we performed software development and hardware integration for hand-held field collection in 2007. The system we helped create provides warfighters and responders with remote-mapping capability and enterprise system integration.
Note that all of the examples above were for technology products used internally to support our mission of providing professional services to our end users. We were not in the shrink-wrapped software or hardware manufacturing business. Rather, we developed better mouse traps in order to increase internal production efficiencies and provide better customer service and value. The takeaway here is to realize what business you are in and not try to do something that is outside your strategic plan. For more about that, please see the first article in this series!
Technology engineering can be fun and rewarding. Or it can be a necessary evil. It can begin as a simple quest to improve a process, and end as an entirely new product offering. Careful analysis must be performed on the front-end to ensure the deliverables will hit the target, the up-front and long-term costs are justifiable, and the competitive advantage or other strategic reasoning is sound. Just go into it with the end goal clearly defined and with your eyes wide open. Remember at the end of the day, the reason to implement technology engineering, and all of the other best business practices discussed in this article series, is to save time, save money, and/or save your bacon. Keep this in mind and you will prosper.