I need a Systems Engineer, but I don't know where to find one.
I build custom solutions for customers. I have Sales&Marketing folks to help me find customers with problems. I have business operations folks to manage the contract and tally the expenses along the way. I have engineers to design and build. I have test engineers to evaluate requirements. Everyone is a professional and I am convinced that they are proficient.
Why is it not possible to meet the customer's expectations with the negotiated resources? Everybody told me from the beginning that it could be done.
My senior manager, Brett Seylor, helped me to see the team players in a new light. The team is not complete. It starts with S&M who are tailoring the scope of the problem to the customer's budget, then throw the opportunity over the wall and start developing new business. The engineers are excited by an unbounded opportunity and the chance to stretch their wings and try new things. Often isolated from the customer, they apply their specialty to the problem. When all that you have is a hammer, every problem becomes some variation of a NAIL! If they are a mechanical engineers, the primary design will be hardware; if they are a software engineer, everything can be solved with a script. These unmanaged assumptions result in building a Cadillac when a VW Beetle will do.
The BusOps folks are the rearview mirror with earned value reports that tell us where we've been but cannot offer a root cause or any control over the development process.
If I enlisted a chief systems engineer, I would have the missing component. My SE would work with the customer to create and document the needs and capabilities. The capabilities would then be analyzed against multiple concepts that could satisfy the capability (DOTMLPF). From the concept that would provide the best value to the customer, the SE will create the specs and requirements that design engineers need to build a specific product.
As the product gets developed, I will always have my SE to help me manage customer expectations, integrate engineers and their components, and consider the entire life cycle costs of development, deployment, sustainment, and disposal. Who was doing any of this before? Everyone was operating from within their box and there were no liaisons.
Ok, problem solved. But, ... where do they make SEs?
It seems that the demand for SE is far greater than the supply. Researching "what is SE" on INCOSE, an analogy was used to demonstrate the excessive learning curve for developing an SE.
INCOSE says that a disciplined engineer who is mentored by an SE will only be 70% effective after 10 years!
Further, you can't provide SE training in an undergrad, because the level of experience and education is far greater than the scope of a 4 year program. An SE is multi-disciplinary and should be experienced in the fundamentals of mechanical engineering, electrical engineering, software engineeirng, business management (operations management) and process improvement (lean six sigma).
This confusion is compounded when the SE term is overloaded and used in want-ads to seek UNIX administration positions (those who maintain a computer system). What is SE? 12 SE roles (or what SE is and is not).
What SE can do for me:
- Transforming needed operational capabilities into an integrated system design through concurrent consideration of all life cycle needs
- Integrating the technical efforts related to system and software development, manufacturing, verification, deployment, operations and support, disposal and user training for systems and their life cycle supporting products and services
- Developing credible and timely technical information to support the program management decision-making process
SE tools:
- http://www.dtic.mil/ndia/2006systems/Wednesday/rassa5.pdf
- http://en.wikipedia.org/wiki/Department_of_Defense_Architecture_Framework
- http://en.wikipedia.org/wiki/IEEE_12207
- http://www.12207.com/Spice.htm ISO/IEC 12207 to ISO90003 and ISO 15504
- This standard (ISO/IEC 12207) defines the best of practice for developing software.
- Maturity ISO/IEC 15504
- Lifecycle ISO/IEC 12207
- Quality ISO 90001 & 3
- DOTMLPF
- examples of systems engineering process standards and models include the following:
ISO/IEC 15288, Systems Engineering-System Life Cycle Processes
ANSI/EIA 632, Processes for Engineering a System
IEEE 1220, Application and Management of the Systems Engineering Process
EIA 731, Systems Engineering Capability Model
CMMI SWE/SE/IPPD/SS, Capability Maturity Model-Integration for Software
Engineering, Systems Engineering, Integrated Product and Process Development and
Supplier Sourcing
In a CMMI lecture today [presented by Stephen Randolph], he pointed out that SE derived from the specialty area of integrating the "ilities" into the design solutions created by the computer scientists and mechanical engineers of the day (thinking of the 1960's era). Large scale solutions were built and then modified by industrial engineers to be more reliable, producible, integratable, testable, sustainable, disposable, and human interfacing. As this liaison engineering discipline grew and the costs of adding it to the design afterwards became known, efforts to identify the "ilities" and human factors in the requirements phase and throughout the design were cost-effective.
Today SE provides the biggest bang in managing requirements to various engineering departments in order to provide the best valued product to meet the customer's needs that is within the programmatic constraints of cost, schedule, and performance. Without this balanced approach, you will agree that every engineer wants to design/build the 'gold-plated Cadillac,' which may not be appropriate on the 'VW bug' budget. Focused design engineers do not build solutions for 'the big picture' or the Integrated Product Team, there must be an engineering-minded check and balance to validate the solution and consider things like contraints, interfaces, and quality/test.
In an ancillary discussion, a manager gave me general and valuable advice pertaining to presenting the SE findings of an upcoming risk assessment. He warned of how to be diplomatic and pay attention to the culture and the feedback from the presentation.
While this is valuable information, we converged on another interesting trait of a systems engineer. There is a built-in self-actualization, diplomacy, and coaching manner that is inherent. SEs have become successful and established through many projects of communication of a vision and strategy, while providing objectivity to trade-offs, and much negotiation. It has never been easy to say 'no' or provide balanced solutions and split up the pie amongst team-members such that every one is pleased and continues to contribute.
No comments:
Post a Comment