Jim Kane | Think outside the box for complex systems

A typical strategy when proposing to build an information technology-based system is to position the proposed solution as low risk.There can be good reasons to make that claim. Among them:But there is room for a different perspective.The theme of low risk is often still valid, but in the current environment, architecture trumps products and offerings, processes do not necessarily ensure quality and can kill schedule commitments and reporting systems frequently don't measure the right information.These are the insights I've gained by understanding the challenges confronting the engineering and technical organizations that make up the Systems and Software Consortium Inc.It's hard to imagine a situation in which the product or system being offered to a government customer is entirely stand-alone. Almost everything is part of a larger system or even a system of systems.The risk to such projects is not with the product offering but rather how it will fit into an overall architecture. This frequently requires integration with multiple older systems. It's the overall design of the systems architecture that is the most likely cause of integration success or failure.Successful risk mitigation requires first-class systems engineering to ensure that the proposed offering will not only perform as promised but also will not generate unintended secondary effects that can degrade overall performance. An offering can be commercial, government-off-the-shelf or a nondevelopment item, but the most significant risk is how it is integrated ? whether in an enterprise, service-oriented or network architecture.Business and engineering processes are designed to assure quality and performance.They are critical to generating business value and bringing structure and discipline to the organization. However, discipline and governance have to be balanced against agility and speed. The challenge is not merely to achieve CMMI Level 3, ISO 9000, Information Technology Information Library or any other quality framework. Rather, the challenge is to implement those frameworks in a way that not only assures quality but also enables fast and agile response to customer needs. It's hard to be responsive to the customer when internal processes for engineering change or configuration control can take two or three weeks."You can't manage what you don't measure" is a familiar refrain.In a world of performance contracts, service-level agreements and risk sharing, this has never been more true. But there is a distinction between reporting and measuring. Managers bemoan the many reports they prepare and receive, but theyalso complain that they don't have the information they need to assure program performance.Savvy organizations make it a priority to implement program-specific and department-specific measurement programs that generate the information they require to validate results, forecast performance and anticipate potential problems.We operate in a horizontal environment where departmental roles and boundaries are not as meaningful as they once were. Leading companies take advantage of skills across departments to generate winning outcomes for their customers. And they are the companies who make sure that their engineering and technical departments have an increasingly prominent place on the team.