A Balanced Approach to Systems Engineering

[article]
Member Submitted

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

About the author

Ryan Maxwell's picture Ryan Maxwell

Ryan Maxwell is a senior consultant with MTS, a Virginia-based technical consulting firm. He earned a bachelor of arts from Johns Hopkins University and has thirteen years of systems engineering experience. He is a PMI-certified project manager, a Sun-certified enterprise architect, and an IBM-certified process specialist and requirements manager. Ryan enjoys speaking about systems engineering and working on technical projects. He lives with his wife in California.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!