There is good evidence from experience reports and other literature that an on-demand or kanban approach to scheduling is highly effective in many instances of software development activities. The question remains, however, if it is equally applicable to the systems and enterprise engineering found in large or complex system environments. This paper discusses goals, concepts and initial findings from ongoing research into this question within a specific type of environment. The research focuses on rapid response software development projects incrementally evolving capabilities of existing systems of systems. It is defining and modeling the combination of a kanban-based, value-driven scheduling system with a negotiation-based services approach to systems engineering in such an environment.
Discussions of systems engineering theory and practice usually focus on the technical tasks that are to be performed by systems engineers. In this presentation, a set of socially-oriented tasks that are necessary to accomplish the systems engineering mission on a large-scale system development are described, and the need for the inclusion within the scope of the systems engineering function established. Most importantly, the implications for technical practices are described; for example, the representations and views of a system used by the systems engineering function are asserted to have a critical role in the success of these social-oriented systems engineering tasks, and through them, on the success of the entire project. The over-all impact on the systems engineering process of incorporating social aspects into the process and responsibilities are considered, and it is shown that the net effect is to increase the efficiency of the over-all process. Because these techniques help to manage and counter the complexity inherent in such large-scale system developments, they therefore constitute an appropriate element of lean engineering.
Time and money are precious to any business. If you could “see ahead” of everyone else and cut your need for both resources, would you gain a business advantage?
That’s what the General Theory of Innovation (GTI) has been delivering to product developers for the last several years. Its originator, Greg Yezersky, universalized a true Systems-level approach to finding and capitalizing on where a market is going, based on fifty years of design improvement findings from the TRIZ methodology. GTI identifies which products a business needs to direct its energies into, to take full advantage of the evolution logic followed by all markets.
GTI also provides something critical that has been missing in the Lean Startups approach. Lean Startups-style experimentation is an ideal way to get around the low effectiveness of traditional market exploration approaches like focus groups, marketing clinics, and customer surveys. These only have the likelihood of creating market growth below 1 percent. Lean Startups is much better, but still inefficient because it subjectively “stabs in the dark” to choose its experiments: It lacks a systematic front-end approach to determine where to conduct your experiments. In other words, it gives no help on finding out what your customers need next…and most. GTI provides the “eyes” you need to use Lean Startups effectively. The GTI approach is equally effective in a traditional established business environment, where forecasting lowers risks and improves results. In either case, it will lower your burn of time and money.
This session will present the GTI-based framework for how to see what none of your competitors can see, and tools for zeroing-in on what you need to do next for best business effect. It's like adding radar to your binoculars! The session will provide real-life examples, with actual results, and take-home tools you can use right away. If you also choose to attend the two-day workshop following the conference session, you will learn the step-by-step methodology (called the Design for Advantage™) and all the details (process, tools, principles, etc.) hands-on, with extended examples, background theory, and more helpful tools.
All five steps of lean thinking (Value, Value Stream, Pull, Flow, and Perfection) focus on customer (stakeholder) value. The fundamental purpose of systems (products, and services) in to provide value for stakeholders. Systems engineers are leaders of systems thinking, systems integration, and systems decision-making. Therefore, systems engineers play a critical role of working with stakeholders to identify and measure stakeholder value during the system life cycle to support systems decision making. Lean and system engineering have very common goals. However, in order to achieve these goals, they need to be able to qualitatively and quantitative define stakeholder value. For complex, dynamic, and interdependent systems there are many system functions that create value for multiple stakeholders. System designs must consider conflicting values and objectives of these multiple stakeholders. This presentation illustrates the use of functional analysis and Value-Focused Thinking with multiple objective decision analysis to develop a mathematically sound value model that clearly identifies stakeholder value across the life cycle value stream and measures the potential value of system designs and improvements that can effectively and efficiently increase potential value. The presentation illustrates and advocates the early development of the value model and the use to the value model to assess value trade-offs during the entire system life cycle.
Working closely with end users can help ensure complex systems meet not just the contractual specification but also operators’ and other stakeholders’ evolving needs in realistic operational environments. Gaining users’ strong support is crucial to maintaining funding for projects and programs in austere budget environment. But working with users is often difficult to arrange and fraught with challenges: They often disagree among themselves and change their opinions frequently. And which users should we contact and whose inputs should we consider? Users don’t speak engineering and engineers seldom speak “ops” so how can we have a meaningful conversation with them anyway? DOD contracts seldom contain any provisions for contacting or visiting with end users, nor does the USG want to pay for such discussions, so how can we arrange discussions with end users? Since there is no substitute for detailed operational discussions with end users of complex systems, an effective, efficient, reliable method must be found by systems engineers and project managers for the regular, methodical engagement of hands-on users of the systems we design and build. This presentation describes the Technical Concept of Operations (TechCONOPS) as the primary document for tying together users, buyers and designers. Then the briefer discusses the four most common user groups, when to involve each and what kinds of information we can typically get from them. This is followed by a brief discussion of how a robust TechCONOPS can drive modeling and simulation. Lastly the other two key communities (technologists and threat/intel specialists) are discussed in the context of their crucial contributions during regular revisits/updates to the CONOPS. Finally, several real-world examples of failed developmental systems (division air defense artillery system, UAV, imagery analysis software, others) illustrate common pitfalls of not building CONOPS and not involving hands-on end users early enough or often enough in system design and test.