A Balanced Approach to Systems Engineering

Member Submitted

A balanced approach to systems-engineering project management will help navigate difficult and seemingly intractable decisions. A project manager’s focus should remain on business needs. Technology and tools—having a limited and identified lifespan—should be supporting elements. Consider agile principles for technology selection and product maintenance, as well as for software development.

Systems engineering management can be a complex endeavor, especially for large programs, as are often found in the Washington, DC Metropolitan area. Certain programs, for example building a space shuttle, will require a high degree of precision, while other projects, such as prototyping a new internal Sharepoint site, may be less precise, even if the information the site will contain will be just as important to the nation’s interests. Many technical initiatives also may have no clear beginning or end; a project may occur in the middle, with a goal to, for example, reverse engineer technical requirements from an existing product, in order to assess the cost of producing a more modern replacement. Also, if a modernization effort is undertaken, the legacy product may well remain in operation, running in parallel to the new product, as a "hotbackup," with no plans for retirement. So, with all of the variation and complexity in systems engineering, how do you know, as a systems engineering project manager, how to approach decisions in process tailoring, technology and tool selection?

The PMBOK leads us to start by identifying the deliverables . If the project team's work is in support of building a space shuttle, but the task is to design a new logo, then deep technical rigor will probably not be necessary. The list of final deliverables, which have been directed and approved by the customer, should drive systems engineering management decisions.

Avoid the trap of "gold-plating" technology selections. For example, some systems engineering tools provide a feature to "automatically generate" technical documentation. However, this feature may have low utility. In fact, a case can be made that there is an inverse relationship between the amount of automated technical documentation and a high quality and low risk delivery. The heart of the issue lies in "what" vs. "how.” Business requirements should describe what is needed by the users and business organization, and technical documentation should describe how a solution satisfies what is needed. Automated technical documentation typically produces a long and monotone list of what is included in the technical solution. Technical teams often make a mistake in assuming that this list obviates the need to describe how the technical product was developed. As a result, automated technical documentation may increase cost and risk. In time, there may no longer be any personnel available to explain how the solution was produced and, even if a limited number of people are available, when the information is needed, it may be a challenge to remember the details of a project from well in the past.

It can be to the customer's advantage to generate the technical what. information, if it is needed and when it is needed. The information will exactly match what was delivered, which is an advantage in technical precision. This information may then be discarded, as point-in-time technical data, in support of an analysis or defect fix, as opposed to an additional and lengthy artifact, which may require unnecessary and expensive maintenance.

While "round-trip" systems engineering suites may provide great capabilities in visual modeling and automated testing, they tend to include very limited and insufficient support for project management schedule and cost analysis. MS Project is an excellent project management tool, as is MS Visio for architecture and design, so long as the information is properly version and access controlled, using tools like CVS. Most CMMI Level 3 certified programs use MS Office. A fully integrated and single brand set of systems engineering software is not necessary for process maturity or a high quality and low risk delivery.

The risks in “gold plating”

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.