What is Your Telehealth Roadmap Strategy?

There is no doubt that COVID-19 has been a major catalyst in accelerating telehealth solutions. Many medical care institutions have had some flavor of telehealth prior to COVID-19. For some organizations the telehealth capability took the form of provider to provider consults. In other cases it could have been a simple portal where patients login and provide some basic information about their vitals and how they are feeling. COVID-19 however pushed the boundaries on every provider to find out ways to provide virtual encounters via video and audio remotely as both providers and patients have been quarantined and stay-home orders were in effect.

As healthcare organizations scrambled to deploy quick solutions which in some cases were not HIPAA compliant, and were far from fool-proof, leaders have to the realization of the need to operationalize the capability, as well as develop a vision for what it would look like over the short term, next 12-24 months. This need becomes of a higher need as regulations undergo some changes, compensation models innovation are occurring, and patients expect the service, not to mention potential subsequent COVID-19 waves as witnessed this morning in California as it re-enters into a State of Emergency.

So what are some considerations for a sound telehealth roadmap?

I like to break down the strategy into two distinct areas; the first is what I call the foundational phase, the second is the deployment and roll-out phase. Telehealth capabilities are more than technology. The successful realization of telehealth capabilities requires addressing culture, business rules, workflows, technology security, data analytics and operational key performance indicators (KPIs) in the clinical, revenue cycle and supporting operations areas.

Setting the foundation is the main focus of the initial component of the roadmap, and involves these activities:

1. Establishing a well-oiled enterprise portfolio management office. A group that can facilitate C-Suite discussions to define key business KPIs, and define approaches to track them on a daily basis, and view projects as investments translating delivered work into measurable value that can be translated into financial and operational metrics that the CFO and COO can appreciate and utilize. To maintain autonomy the group should have the empowerment to coach chiefs on thinking outside of their areas and think strategically. In some models the group would report to the CEO, or to all chiefs, but have autonomy to make decisions based on sound approaches and documented rules. Another common model is to have the group report to the CIO, as almost all solutions today are data-driven and technology enabled. Today's successful CIO's are those who speak in the language of the business and are empathetic with the needs of clinicians and their patients.
2. Fostering and nurturing an organizational culture of accountability, patient value proposition and organizational mission. Unfortunately, not too uncommon is many organizations in the industry suffering inefficiencies. Examples of these inefficiencies are clinician controlled organizations which tend to prioritize physician convenience over patient care reflected in scheduling rules, availability, triaging rules, decision making, patient volume accountability and documentation maintenance. Another common inefficiency is tactical leadership in the C-Suite that fails to think strategically across the organization, unable to define heat maps, or poorly identifying existing and needed business capabilities and lack of prioritization of initiatives, losing track of meaningful KPIs and creating silos. Focus should be on business rule simplification, process streamlining, capability and asset inventory, architecture documentation, and change management and enablement processes.
3. Investing in a strong supporting infrastructure represented in IT security, network and server technical capability, enterprise architecture, project management office, talent development, compliance and a legal support team. Unfortunately many healthcare organizations view their IT departments, legal team and HR recruiters as cost centers, rather than value development centers. Together these supporting teams can strategically build and support a strong value stream by weaving a strong strategy map in conjunction with the operational leaders of the organization, mainly in the clinical and revenue cycle sides. The formation of these guiding teams and the chiefs engagement directly with these teams is a key requirement for success. Chiefs shouldn't be immersed in fighting daily fires, leaving strategic growth initiatives to become second priority.

Next comes the deployment and roll-out phase which focuses on two main components

1. Problem Definition and needs analysis coupled with a visioning exercise checking its alignment to the organization's mission has proven very powerful to validate the scope of the telehealth roadmap and it's capabilities.
2. Solutioning and a strong market research of offerings, comparing off-the-shelf products and their fit to the healthcare organization's environment and configuration at a feature and use case level is the next value-add activity. This can be achieved through vendor presentations, RFPs, in person demos of well-defined use cases reflective of the organization's workflows. This piece of work should include integration concerns across vendors, and how the integration will address the organization's specific business rules and the level of adaptation of the technology to the changes in business and clinical operations.
3. Building a strong partnership model internally and externally with key stakeholders and vendors to implement the solution and telehealth capabilities under the oversight of the guiding team, utilizing the enterprise portfolio team and project management office as the internal auditors of the roll-out, providing continuous feedback and opportunities for process improvement.
4. Once these high level stages can be put into place, the problem of defining which telehealth model to deploy (virtual health, peer to peer consultations, third-party contracted services) becomes a simple task, followed by a more detailed definition of telehealth capabilities and types of clinical encounters and a roll-out plan across the various specialties or a big-bang approach.

In summary, before worrying about COTS vs inhouse implementation, or Electronic Health Record (EHR) and Practice Management (PM) embedded vs integrated solutions, or the features a doctor can perform, the organization needs to think strategically at a macro-level to build a solid foundation in an agile manner to ensure a valid business and revenue model. This will ensure a scalable roadmap that can be incrementally implemented providing value realization to both the organization and the patient, focusing on what matters and what makes the organization unique and well-positioned for longer term growth.

For more information on telehealth advisory services visit carefinitive at https://www.linkedin.com/company/68234600/admin/. Ayman Nassar is an industry expert in project and portfolio management with over 25 years experience in architecting business solutions through optimum alignment of technology and business to achieve meaningful results. He can be reached at anassar@anassar.net or https://www.linkedin.com/in/aymannassar/

The Most Important and Most Neglected - Business Rules

Over the years the most important issue I have seen neglected on a transofrmation project is an honest thoughtful discussion on Business Rules. What should the process look like under the different conditions. Business rules come in all forms and levels of complexity. I share a few examples below for the purpose of clarity.

 

A healthcare provider member who wishes to renew her policy for her 7 year old child and 19 year old college student. The business requirement can have different rules, here are some:

• Rule A: Income Level: Family is low income and hence have an extra 10 day grace period
• Rule B: Residence: Family lives in rural counties of the state and hence is eligible for a 45 renewal window, versus same family living in the major cities of the state which has only a 30 day window for renewal.
• Rule C: Age: 19 year old child reached his 19th birthday less than 90 days prior to his policy expiration is treated differently than more than 90 days prior to expeiration date.

 

An example from the supply chain vertical related to demand forecasting and planning could be dependent on order cancellation business rules, for example:

• Rule A: Orders returned due to defective items that are reordered on the same order, should not be removed from demand
• Rule B: Orders returned due to defective items and are reordered on a new order, should be removed from the demand of the month of order, and reapplied to the month of the new order.

 

Projects of all sizes usually neglect business rules when designing and delivering a system. Business rules are the most important part of the process, for indeed that is where decisions are made. Decisions are where the bug are found in the system. Poorly thought through business rules automatically equates to bugs, miscalculations, data quality issues, rework, frustration and utlimately redsign and worse sometime a compelte overhaul of the architecture

 

 

Patterns: What Are They? Part 1

Literally patterns are defined as a combination of qualities, items, objects, behaviors, or other which form a consistent or characteristic arrangement. We observe dozens of daily patterns every day. Examples are teen behavior, the movement of the earth around the sun, the blooming of flowers and hundreds more.

"A combination of qualities, items, objects, behaviors, or other which form a consistent or characteristic arrangement"

Patterns are not new to man-kind, the Creator has informed us about patterns in the Quran and other earlier revelations. Recently system developers started to analyze the concept of patterns, pioneered by Christopher Alexander in his book, " A Timeless Way of Building", he defines a pattern as a three-part rule, expressing a relation between a certain context, a problem and a solution.

Patterns are a first step in understanding root causes of the problem within a specific context. It also allows the development of architectural and solution building blocks.

"In systems realization, patterns express a relationship between a problem and its solution within a given context"

For a software designer some pattern examples are: Message Translators, Process Managers, and Proxies to mention a few. A process manager pattern for example will comprise of a sensor to detect an incoming message which initializes the process manager. The process manager in turn executes a set of rules stored in the process manager memory implementing the processing rules, and detects the subsequent steps through a status feedback detector/analyzer.

Considering a different domain, take the example of a group that does youth trips, examples of patterns could be: Headcount Process, Critical Supplies, Meal Managers, Activity Itinerary Manager and many more. An Activity Itinerary Manager pattern will comprise of an input process to capture developmental and coaching themes/needs of the youth trip, a search process to match the theme to a group of activities that meet the objectives of the theme from a repository of activities, the selected lists of activities could then pass by the activity processor which breaks down the activity into steps, each assigned to resources, a lead, a cost structure, risk factor and plan of action. Feedback from the actual deployed activity is then finally fed back into the activity manager for updates to the activity definitions and other relevant areas, within quality expectations.

_____________To Read More _______________

(1) Hohpe and Woolfe, "Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions", Addison Wesley signature Series, 2004.

(2) Haskins and Raveh, "Introduction to Patterns Through Writing Systems Engineering Patterns", 16th Annual International Symposium, 2006.

(3) Gross and Yu, "From Non-Functional Requirements to Design Through Patterns".

The Demise of Quality - My Wife's Friend, British Airways and Air France

I was vacuuming the living room last evening, when my wife told me that her friend arrived safely in Egypt after a long flight from Washington with a connection in London. She then added that her 10 year old son is walking around in his swimsuit at home and her friend is wearing some old maternity clothes she had from a decade ago. I asked my wife "Did they lost their luggage?", she replied that no a single bag of the eight pieces her friend and her three kids had arrived.

It has been two days since my wife's friend family had arrived on board British Airways with no luggage. I mentioned to my wife that her friend should request a compensation of some sort, may $100 per passenger, so they can use this modest pocket money to go buy some clothes until their bags appear. My wife's response was "we are thankful that they arrived safely". Well, yes of course compared to Air France's latest flight that plunged in the Atlantic, the losses and inconvenience is minimal, and one should always be thankful, regardless of what one goes through". The point however is that the passenger's (customer) expectation is be transported safely along with his luggage from point A to point B. If customer's start changing their expectations, quality will automatically by definition change.

An attorney would seize the opportunity and ask the passenger to file a suit against the airline asking for some ridiculous amount of money as a compensation for damages. Maybe $1 million dollars per lost bag, or the highest that the court will allow. We have various mindsets of customers when it comes to settling disputes with a service provider. At one extreme a client will say no problem, just get me my bags if you can, when you can. On another extreme another customer will say meet me at court, and then there are infinite of perspectives in between.

What would you do? What would a good system's engineer do? Share your thoughts in the comments below.

Two Approaches to Use Statistics on Your Project

Most people don't like statistics, and most decision-makers make wild guesses when they need to take a decision. Statistics might not be the most straight-forward science during the college years, but it has tremendous value in providing insights and guidance for making rational decisions.

Using statistics one can show various properties of a set of data such as the mean, mode, median, dispersion and distribution. These parameters can be represented graphically using histograms, charts and other visual illustrations.

Another approach using statistics is to develop inferences, test hypothesis and develop forecasts through the use of sample data from a bigger population. Relationships between variables can be developed and illustrated using a scatter diagram or a regression equation.

Six Sigma's DMAIC vs. Design for Six Sigma's IDOV / DMADV

Six sigma's success is mainly contributed to its DMAIC model. The DMAIC model focuses on defining an issue with an existing process or product, measuring the deviation from the expected behavior, analyzing the data for insights to root causes, improve the current process or product through minimization of deviations or improvements and finally controlling the system to sustain the gains achieved.

IDOV and DMADV which are two design-based models slightly differ from DMAIC as follows.

Objective and Approach: DMAIC views the current process or product as correct and economical, but needs to minimize some gap leading to inefficiencies. IDOV / DMADV view the current process or product as in need of redesign or design change to achieve customer satisfaction.

Process Capability: DMAIC views current process as capable of satisfying customer needs, whereas IDOV / DMADV views current processes as a candidate for improved yield regardless of volume and complexity.

Design: DMAIC views the current design as satisfactory for the client's needs, whereas IDOV / DMADV views the need to consider various drivers for design, such as cost, manufacturing, producibility, maintainability, robustness, usability, efficiency, security, agility, compliance and testability.

Flexibility: DMAIC assumes that the current design and processes are flexible to meet customer demands and needs, whereas IDOV / DMADV highly considers potential customer demands and forecasts newly developed needs

Validation: IDOV and DMADV both consider validation and verification of the outcomes of a design or process in meeting objectives.

To read more:
[1] Chrisitian Madu, "The House of Quality in a Minute", Chi Publishers, 2006.
[2] Rod Munro, "The Certified Six Sigma Green Belt Handbook", Quality Press, 2008.

Using the Theory of Constraints & Six Sigma to Fix Critical Components of the Economy

Constraints are all around us. The theory of constraints is a lean problem-solving concept based on a simple concept, that a process can not move faster than the slowest part of the process.

Our economy as a complex enclosed system has constraints and it will respond to stimulus as quick as the slowest link in the economy. The chart on the left illustrates some major components of the economy. They all need to be improved for the stimulus to realize benefits, otherwise it will be a temporary patch.


The root of the problem lies in three areas:

1. The concept of printing money and the process followed to release cash into the market. The Federal Reserve Bank - which is not a government entity - is provided the authority to distribute the nation's currency and supervise banks which are members in the system. When the US releases currency into the market it requests the Federal Reserve Bank to print dollar bills in return for an interest payment on the amount. No real assets are provided as collateral to backup the value of the printed currency. The value of the currency is only backed up by the reputation and promise of the US government to accept the currency as a form of payment. As users of the currency lose faith in the governments ability to keep the promise the value can drop significantly. One reason for the poor confidence in the currency, is the automatic depreciation of the currency the day it was printed. For every US dollar printed a small percentage is due to the Federal Reserve Bank as interest on that printed dollar, in a sense every dollar released into the market is really worth 0.98 of a dollar, if we assume an interest rate of 2%. Add onto this, the fact that the US government is running into a non-stop deficit in social security, and other areas leading to increase in bond issuing to countries such as China and India, further diminishing the value of the US currency.

2. Interest rate or usury is another problem in the overall system. The fact that currency value depreciates today based on some future value determined by an interest rate automatically leads to inflation, and future depreciation of natural resources. Charging interest is like pumping steroids into a body builder, eventually at some point the body will collapse.

3. Selling what we don't own. The idea that goods and services can be sold without actually owning them creates a virtual commodity system, not backed up by real commodities or assets.

Unless these areas are fixed no stimulus package can work on the long term. Some simple steps to address this issue are:

a. Identify the constraints of the financial and monetary systems
b. Exploit the constraint or re-engineer
c. Subordinate other steps in the overall process to the improved constraint
d. Revise the constraint if it has not been eliminated by steps b and c
e. Repeat the steps above for other constraints

Applying this into practice can be as follows:

a. Identify the constraints of the financial and monetary systems
- Currency not backed by a true tangible asset (some natural resource like gold or silver)
- Currency being depreciated the day it is printed, solely due to interest
- Distribution and sale of products that do not exist (example lending money to a business when the bank does not have the exact cash reserved, selling a commodity that one does not own and has not yet paid for)
- Using interest rates to discount projects, assets and commodities to a future value, leading to valueless future assets, commodities, natural resources

b. Exploit the constraint or re-engineer
- Re-engineer the monetary system that issues a currency based on a true asset and not just a promise
- Re-engineer the concept of future valuation
- Re-engineer the concept of wealth circulation

c. Subordinate other steps in the overall process to the improved constraint
- Use a sustainable natural resource to backup the value of an issued currency
- Use joint partnerships, gifting (0% loans) and entrepreneurship, moving away from interest bearing loans of money that is not owned by lenders.
- Base future valuation on true-value (value proposition) provided to global society rather than a discounted interest rate.

d. Revise the constraint if it has not been eliminated by steps b and c
e. Repeat the steps above for other constraints

3 Ways To Guarantee a Failed Product

I was at the county jail a few weeks ago coaching a group of young men on strategies to transition back into society. I asked them two questions, the first list 3 goals you would like to accomplish during your lifetime, things you will be proud of in the hereafter. They jotted down some goals on 4*6 cards. The second question was list 3 things that if you do, you are 100% sure that there is no way you can achieve these goals, it will be impossible to achieve them. I gave them a few minutes and they all had a few points to share.

One example of a goal that was shared was to get back to education and enroll in college, get a degree and be a productive member of the society. The young man noted involvement with illegal substance to be a factor not allowing him to realize this goal.

Developing successful systems follow the same pattern. We need to understand user requirements, the utility of the system, why is the system needed, what value is the system offering, the gap it is filling. Once that goal is clear and understood, we need to make sure we protect these requirements from "outside noise", what is also known as scope creep. Scope creep is for sure a main reason why projects fail, it is when we add requirements, remove requirements, or just change requirements in an uncontrolled fashion, without going back to understanding the rationale and true value for doing so and relating it to the project's objective, cost and schedule.

Reason 1: Low Quality Requirements and Scope Creep - Uncontrolled Changes

A second young man in the group shared his goal was to be a successful businessman offering valuable services to the society. He noted down that unethical dealings would be a reason to ensure he never accomplishes his dream. I advised him that to overcome this hurdle he needs to continuously gauge his relationship with his Lord and measure his values and ethics. If he notices that his relationship is getting weaker, he needs to take corrective actions.

In the domain of systems development we call that validation and verification. Is the project still valid? i.e. is it still delivering what it was originally intended to deliver. And is the work correct? Can we verify that the work is what was expected earlier at the beginning of the project, through testing, and if it is not correct, can we take corrective actions to resolve defects. This validation and verification needs to be conducted throughout the whole life cycle of the product, and not just near the time we turn it over to the client, otherwise the deviations from the expected results could be huge, leading to costly modifications, schedule slippage and possibly a failed product.

Reason 2: Not Considering Validation and Verification Early in the life cycle of the product - Developing the wrong product, or developing the right product incorrectly

A third person shared that his goal was to be a teacher, nurturing young minds not only with knowledge but the application of the knowledge and its purpose. I reminded him to share with his future students trace back the purpose of the knowledge they learn from him, to the purpose for which we were created. Everything we do needs to serve the purpose for which our Lord created us.

Similarly, in the domain of product development, we can that requirements traceability. How do the original requirements defined by the client relate to design work, development work, testing and final product features. It is important that throughout the life cycle of a product we maintain a clear trace of how the work we are currently involved in relates back to what the customer needs.

Reason 3: Poor Requirements Traceability - Missing some Requirements in Implementation, adding Features not Needed, or both


Make sure if your customer asks for a mule, you deliver a mule as expected, and not a cow. Although a cow has plenty of benefits and utility, it might not serve the need satisfied by a mule.

7 Tips for Engineering Students

I often get questions or concerns from engineering students about studying and being able to pull through college to reach their goals of becoming engineers. I have to admit going through engineering school is no light challenge, but at the same time it is an enjoyable experience.

Common comments are concerns of not being able to understand the questions in an exam, or not able to go through the needed steps, or just finding subject matter too complicated.

Here is my advice for of these folks and other future engineers.

1. Understand that engineering is all about problem solving for the betterment of humanity, through the use of scientific facts. This means that a good engineer must,

• understand what the problem is (how it happens, why it happens, when it happens, where it happens)
  
• analyze the problem - visualize it (use a pencil and paper to sketch, engineers are born to sketch)
  
• determine its scope - (how big is the problem, who does it affect, under which conditions)
  
• determine what information is given to us (data, assumptions, facts)
• learn the sciences (calculus, physics, chemistry, etc..) to use in problem solving
• apply these sciences to the appropriate solutions for the relevant problems

2. Never memorize, engineers are thinkers. Anything you learn must make sense to you. You must understand why a theorem or rule is the way it is, how it came to be so, this will help with critical thinking, and will enhance information retention.

3. Do not depend on calculators too much, understand how calculations occur, understand how the value for the various engineering functions are calculated, the meaning behind a differential, or integral, etc.. Then use the calculator to just speed up calculations - remember a fool with a tool is still a fool.

4. Develop mini-processes for yourself of things to do when you analyze engineering problems, make these processes adaptive to suit your thinking styles, analytical abilities and memory capabilities.

5. Practice makes perfect. Just like spending ours in the gym pumping those muscles up, or on the court perfecting those slam dunks. Engineers need to practice solving various types of problems (easy one, long, ones, short ones, complex ones, complicated ones, straight-forward ones, etc...).

6. Be organized - learn how to manage real-estate space on your paper. Organize data, analysis, scratch notes, results, conclusion in clear separate sections of your sheet. Be a good communicator, improve your writing and verbal skills, to allow you to effectively communicate your solutions to others.

7. Love the subject matter. You can never solve a problem, you don't care about. A good engineer can never design a bridge if he cares more or less of the importance of crossing the river. Love it, adore it, live it, immerse in it... be the engineer !!

Perfection Never Ends... KISS brings us closer

Last night I was chatting with a friend of mine who is working on the launch of a new project. I asked, "How far are you from launching?" His unexpected reply was "We will miss this year's launch and do it next year, I want to make sure everything is complete and people get to say wow"

The question we need to consider "Is it better to launch today when there is need, but have a modest service offering?, or to spend another year perfecting the service offering and miss the boat on this year's demand?"

KISS (Keep it Simple & Short) brings us closer to deployment and reality.. apply agility... get something working out the door, serve the need, use the opportunity to make further improvements in later releases... perfection never ends.

The Assertive Systems Engineer

So you are on a project to help the team develop a successful system. You notice things that don't make sense, or are not they way they should be. You raise your concern, "Hey, team we need a process to automate testing". Everyone looks at you as if you are some wacko, and then moves on with their business. Two weeks later and after 4 more team meetings you raise the concern again, and again. Finally one team member says "We always did testing this way, and we don't have the money or time to develop the automation, so don't keep repeating this".

What do you do? Shut up? Go with the flow? or be stubborn, resist to work in a chaotic environment? Actually the reaction should be neither. Smart systems engineers need to be adaptive, flexible and understanding of the business constraints and technical limitations. They also need to be assertive and counselors of best practices and approaches.

Document your technical opinion, the problem as you see it, the proposed solution, the rationale for the solution and consequences of not addressing the problem. Be assertive about your technical opinion, and also flexible to adjust the solution as needed to meet the laws of physics and constraints the team must abide with.

Remember systems engineering is all about engineering a system with the most optimum means, in accordance to sound decisions and rationale

Requirements: Engineering vs. Management

Which is a subset of the other, is the process of requirements management a subset of requirements engineering or the other way around?

To best answer this question lets get back to the basics. What is "engineering" and what is "management".

The term engineering is used to indicate an activity whereby an engineer utilizes findings of sciences to realize solutions which solve problems. To provide an example, a society which has a problem crossing a river asks a civil engineer to realize a solution to this problem. The engineer based on his readings and input from scientists in the fields of chemistry, physics and materials suggests using a steel structure which can withstand corrosion from the environment, and hot summer temperatures as well as extremely low winter temperatures. The engineer performs calculations to detemine bridge loads and how the structure will behave to cross winds and othe environmental elements.

So back to requirements engineering, it is the process used to determine how to best engineer (recognize, analyze and synthesis) a requirement.

Generally speaking management is defined as the activity of controlling, organizing, planning, and directing. It can be argued that planning and analysis do overlap and hence both requirements engineering and management overlap to some degree, and I would agree with this. However requirements management has a much broader scope than engineering, requirements management plans, organizes, controls and directs the processes related to requirements "handling", this handling includes engineering, development, maintenance and obsolecence. Changes to requirements are considered part of requirements maintenance which is part of reqs mgmt.

Requirements management involves developing a database to store requirements, a report from this database could be the RTVM, a list of configurable items (CIs), requirements management could also include tracing requirements to business requirements upward and to test and verification results downwards, it also ensures that the synthesis process in requirements engineering is sound and consistent and traceable to project work packages in the work breakdown structure (WBS) and eventually the statement of work (SOW). It involves establishing requirements baselines, negotiation with stake-holders and prioritization of requirements and changes.

We should not assume requirements management to be a phase in the system life-cycle, but rather a continuous process overseeing all the phases of the system, nor is it a subset of requirements engineering but rather a superset of the various system phases. This is illustrated in the chart below.

A few papers related to requirements management are listed,

[1] Ian Somerville and Pete Sawyer, "Viewpoints: Principles, Problems and a Practical Approach to Requirements Engineering", Lancaster University, 1997.

[2] James Martin, "A Process for Requirements Definition and Architecture Definition", Texas Instruments.

[3] James Martin, "Systems Engineering Guidebook: A Process for Developing Systems and Products", CRC Press, 1997.

Systems Engineering - Various Perspectives

We are familiar with civil engineering, electrical engineering, mechanical engineering and the many other engineering disciplines. Engineering generally speaking is the application of science and its concepts to solve society's problems. For example a problem of crossing a river can be solved using the sciences of materials, welding, concrete pouring, etc.. through civil engineering which makes it possible to realize a civil solution. Also we can develop a product that lifts people up into the air and cross the river - called a helicopter - through aerospace engineering which makes it possible to realize an aerospace solution. Similarly, systems engineering attempts to solve problems through the realization of a systems solution using the concepts of systems sciences. One difference in the case of systems engineering from other engineering disciplines is that systems engineerings is not only based on sciences of systems, but also on the art of systems thinking.

Here are some perspectives on what systems engineering is,

1. An Engineering discipline focusing on system realization using well developed scientific approaches such as requirements definition, engineering and management; feasibility and trade studies; system interfacing and integration; technical risk control and management; system optimization; system life-cycle management and system modeling and simulation. Systems Engineering has been offered as a post graduate degree in many institutions around the world, mostly at the Masters level. A handful of Universities also offer PhD degrees in Systems Engineering. I expect in the next 10 years we will see B.Sc. degrees offered in systems engineering as a new engineering branch of study, it could also be offered in specializations or as a minor at the undergraduate level.

2. An Engineering approach which combines both art and science. The science of rigorous well-defined engineering theories, processes and approaches, and the science of problem solving using systemic approaches. The art of systems thinking.

3. A management discipline controlling the total system life-cycle. In this case systems engineering is viewed as the interaction of science, organization and the environment and their impact on the system throughout all phases of its life-cycle. It is also viewed as the application of methods, tools and technologies across the life-cycle of the system products.

Performance: An attribute or a behavior?

Is performance of a system an attribute or a behavior? I guess the answer to this question depends on the perspective you are considering. Lets take the example of a Nissan Quest Minivan as a system.

According to its data sheet it has a performance of 235 hp @ 5,800 rpm and a 240 lb-ft @ 4,400 rpm. This data could be considered a system attribute at the time of design. These are the performance goals the design engineers are targeting in the product that rolls off the assembly line. One can argue that once the minivan hits the road and a driver presses on the gas pedal these numbers no longer become attributes but rather operational behaviors. As the system ages the numbers would change.

Decision Making and Systems Engineering

Systems engineering is an interdisiplinary approach to enable the successful realization of systems. Learning the systems engineering process is not a complex task. The tough part of systems engineering is making decisions related to trade-off studies, and balancing among the different requirements, which could at many times be orthogonal and conflicting.

An effective systems engineer is one who can provide insights and advice related to technical decisions. This would occur as follows,

1. Ensuring requirements are clear, well understood, correctly prioritized, and motivation well understood
2. Modeling and simulation and developing what-if scenarios
3. Conducting trade studies and parametric analysis
4. Clearly defining interfaces and boundaries, their requirements and impacts
5. Comprehensive risk management and optimum risk handling
6. Justify changes to requirements, design, scope, resource demands and technology
7. System optimization to develop a best solution in situation where multiple aspects of a system can be optimized
8. clearly defining dependencies, integration constraints and alternatives

The value of the system engineer is not only implementing the systems engineering capability pattern, but also ensuring that true value is being realized through the implementation of the SE capability patten. This true value will be achieved through solid decision-making.

Technical / Scientific Reviews Leadership

We had a guest speaker come in from Johns Hopkins APL to our leadership class at UMBC last night. He shared with us his career experiences and some tips.

One thought I got from his visit was the importance of teaching technical/scientific review meetings leadership. I did a search on the Internet quickly to see what is out there, but there is very little literature in how to successfully run and conduct a technical review.

I am not talking from a process perspective, like what the process for an SRR should be. These processes are well known and understood. But rather I am talking from the leadership perspective. Areas like

1. Tools
- What are the best tools to use during the review, slideware, spreadsheets, technical documents, etc..
- Can reviews be conducted remotely over collaboration S/W like NetMeeting, Notes
- What is more effective in-person or remote meetings? I did both each has it pros and cons

2. Negotiation schemes
- So the client PM takes over the meeting, how do you as the lead SE on the contractor side react?
- Just got into a project yesterday, you need to do a walk-thru tomorrow, who are players? how to run the review smoothly?

3. Time control
- Mr. chatter loves to chat, and whiner complains about each requirement, and repeater has to make sure we all memorize his statements before we leave, how to filter and weed out the garbage talk and retain the technical meat you are looking for?
- One big 8 hr meeting with 1 hr lunch and 2 15-min breaks, or 4 2-hr meetings over 4 days?

4. Scope control
- Ok, we are doing a use case review, but lets quickly go over the architecture, 60/40 opposition, what do you do?

I attended a workshop by Edward Tufte, the professor at Yale last Spring, he discussed some very interesting thoughts about how some organizations fail to conduct reviews simply because they use poor tools. He gave the example of NASA and the shuttle explosion. In his opinion as well as the many experts who evaluated the crash, the failure in the shuttle started not at launch, but rather way back in the technical review process. NASA was too heavily dependent on power point fluff. It was very easy to lose focus of the strategic technical issues and questions during the reviews.

This all needs more research...

New Product Requirements

There are various sources for requirements gathering for a product or service. Obviously the most important source is the customer who will be using the product or service.

Another valuable source is the environment in which the product and customer will both be surrounded by. A list of the most relevant environments that a product manager or systems engineer should take a look at are:

1. Technological Environment
Presence of new inventions, innovation, methods, processes, materials to achieve new tasks or perform older one better, etc...

2. Economic Environment
The cyclical changes in local and global economies, inflation (prices rising/lower purchase power), recession (trade down/employment down), unemployment, depression (panic), recovery, prosperity (employment up/trade up), off-shoring, debt/savings levels, income distribution

3. Competitive Environment
The landscape of competing (monopoly, perfect, oligopoly, monopolistic), competitors status, etc...

4. Sociological Environment
Cultures, changes in industries, religion, subcultures (teens, seniors), crime rates, etc...

5. Political-Legal Environment
Legislation, regulations, PACs, wars, etc...

6. Demographic Environment
Age, gender, customs, location of residence, etc...

7. Natural Environment
Natural resources, raw materials, pollution, etc...

Astute system engineers should research all these environments. The level of research might differ from on environment area to another depending on the product/service being developed. In some cases other environments might be considered and some of those listed above ignored.

Needs - Wants - Demands

Just like a smart marketer, an astute systems engineer knows the difference between the three:

Needs - are basic requirements, like eating and going to the bathroom

Wants - are needs that become requirements for fulfilling basic needs, for example people want education to find a job, to make money to buy food to meet the basic need. Wants are shaped by the environment the client is in.

Demands are wants for specific products coupled with an ability to pay.

Marketers do not create needs. Needs already exist. People need to eat, move, dress and learn. Marketers only promote the idea that a burger, car, Jeans and private school will satisfy the client's needs, by highlighting the benefits the client will achieve using the product.

Systems Engineers Don't Only Engineer Technology Systems

That is true... Almost all industries and discplines need system engineers, simply due to the fact that everyone needs something.

Traditionally we are used to seeing systems engineers working in the defense sector to define requirements for the next state-of-the-art missle, or at a high-tech firm developing and trackign requirements for the seemless e-commerce application.

Masjids, churches and synagouges need system engineers to articulate the needs of their congregations, define priorities and ensure that requirements add value. Schools need to develop effiecient operational systems, retail stores need to streamline their sales, and the list goes on...

Just like the following list of items could be marketed.. they could also be system engineered...

Goods - Technology products, consumer products, commercial products, etc...

Services - B2B, B2C, C2C (yeah myspace, blogs, etc..), C2B (resume websites, etc..), professional, educational, security, etc... the list services never ends

Events - Yes events which are complex could require the art of engineering

Experiences - Ever heard of Opera Aida..

Persons - We can market persons, can we system engineer a person.. sure we can define requirements for that person to reach certain goals.. we call that also coaching, mentoring, training, and many other things ...

Places - Engineer a downtown...

Properties - Engineer the Pyramids

Organizations - Build a non-profit systematically.. yes that also is systems engineering

Information - Indeed.. that is what we call IT system engineers...

Ideas - System engineers make not only great inventors because of their holistic views and ability to identify gaps, but also.. great value initiators .. very similiar to marketing slogans..

"Everyone can benefit from a little System Engineering"
Ayman Nassar

Simple Facts About Systems Engineering

I started my career as an electrical engineer, but I really leaned more towards the big picture. Once I solved a problem it would be very unlikely that I will find interest in solving it again or soliving a similiar problem. The engineer in me seeks new problems, gettign down to the nitty gritty details. However those I already solved would only be interested in overlooking them, giving advice on them at a high strategic level...

Some say systems engineering is really a management discipline more than an engineering science. I tend to agree, as systems engineers we are not neccessarily developing technological or engineering-oriented systems... what I mean yes most systems engineers out there are working on a project for a missle, a space shuttle, an enterprise information management system, and e-commerce application, etc... however a system engineer could be as well developing a human resoruce organizational policy, a school governance structure, a hospital management system, or a marketing strategy for a metropolitian city.

You might ask how, the answer is simply that systems engineers master methods and approaches for dealing with the development of complex systems. A complex system is one that flows from a complex process that converts organized human thought, resources and time into descriptions of organized sets of things that function together to achieve predetermined function. This is a slightly modified defintion from what Jeffrey Grady mentioned in his book, "System Validation and Verification".

A simple fact about systems engineering that Jeffrey Grady mentions in his book, is that the amount of knowledge that humans have exposed is far in excess of the amount of knowledge that any one person can master and efficiently apply in solving problems.

The development of any system is a problem-solving process that transforms simple statements of customers into a clear description of a system realizing a solution to the customer's need. Complex problems require the understanding of different perspectives, technologies and a very broad knowledge base that any one person can master alone, hence the need for specialists as well as generalists who could control, direct, organize and plan the various activities and outcomes of specialists work towards a unified solution, that is where the systems engineer comes in... So yes, I do agree a systems engineer is a sharp manager, with engineering background, who can engineer complex solutions and architect visions to problems solutions, who can become very technical and specialized not only in an engineering discipline what whatever discipline the problem seeking a solution for involves.

I do believe there will come a day when systems engineers will be developing government strategic plans, architecting hospital management systems, developing not-for-profit organizations' policies and service frameworks and a lot more solutions to areas which most engineers do not consider to be engineering, i.e not mechanical, electrical, civil or industrial systems.