process, technology and tools are the same as with business scope. Additional technical scope comes with a cost: acquiring and supporting licenses from an initial purchase through maintenance, personnel training costs, and additional and often hard to find specialized resources, to install and configure the technical products and tools. It's important to look towards the future in the field of technology, but given the industry project failure rate, coupled with often changing customer needs, it can be unwise, and even dangerous, to buy more than is needed, and to "engineer for the future," without proper controls. The best solution is typically to use only as much process, technology, and tooling as is necessary to deliver a solution to meet the customer's needs .
There is also a risk in striving for a single, monolithic, and point-in-time technology or suite, which will inevitably come with technical limitations, may quickly become dated, and possibly lock the customer into one vendor. Avoid the temptation to search for a systems engineering "holy-grail." An "Agile" approach to technology and tool trade-off analysis may be more successful.
Even software maintenance can be "Agile." In very tightly controlled environments, such as financial institutions operating under Sarbanes Oxley requirements, after a product has been delivered into production, a tool like CVS may be successfully used to store and access both technical and business artifacts, such as "sign-off" documentation. If a systems engineering suite has been in place, it generally isn't necessary to continue to provide licenses for all team members. One member of the team can be appointed to act as a secretary, to keep the information contained in the suite up to date, until its contents are exported and archived, and the suite retired.
The focus of a systems engineering project manager should remain on delivering to the business needs of the customer, with a good ROI, and against known and reasonable points of time in the future. Make practical cost management decisions . For example, software licenses should only be purchased for users who need them, and they should be turned in as soon as possible. Additionally, technical teams should take advantage of any available floating licenses, when possible, and where it provides a cost advantage over fixed licenses to particular individuals or machines. The systems engineering project manager should keep in mind that there is a trade-off between acquiring licenses and hiring personnel. A software license, when not in use, will not contribute to a delivery, so a deliberate effort should be made to consistently drive down licensing costs, in support of a lower cost delivery, and a greater opportunity to hire additional personnel as needed (See Figure 1).
Figure 1–Cost of a Technical Product at Time Adopted Within the Product’s Lifespan
The maturity of a technology should also be taken into account, during a technology trade-off analysis. A new technology typically starts with a low ROI, which steadily increases over time, based on the technology's success, and which eventually lowers again, as the technology shifts out of favor, and becomes obsolete (See Figure 2). For example, COBOL was initially a new and sophisticated programming language, which became commonplace and very practical to use in the 1980s, but which now requires hard to find and often expensive resources. Consider the time horizon of the customer's business operations , and correlate lines of business to technology selection decisions, based on technology maturity. Keep an eye on maintenance, retirement, and disposal, as these phases typically consume 80% of the total cost of a technical solution.
Figure 2–Budget Trade-off Between Personnel and Software Licenses
A periodic review of