6.31 Communicate with Stakeholders

This is a continuous requirement from first client meeting to presentation of intermediate or final results. Model development inevitably encounters surprises. Anticipated, required data may not be available when needed, or trustworthy, or expressed in immediately useful form. The stakeholders may include not just the client, but also representatives of other interested groups (for instance consultants, domain experts, regulating agencies, and others). If the modeler has prepared well, successful presentations based on concrete model outcomes are the ideal outcome. There will likely be presentations for planners who deal with the problem and others for the executives who pay the bills. For each stakeholder, one must carefully adhere to the lexicon worked out in the five-step preparation (see prior definition of such) for the modeling project.

Managing relationships with multiple stakeholders, and following their multiple, possibly conflicting, objectives is beyond the scope of this introduction. But suffice to say, if you have scrupulously followed the five-step preparation above, you are as well situated as possible.

Most contemporary models are used via agraphical user interface(GUI), and in many cases the GUI consumes more development effort than the model. This is to be expected. However, the GUI developer(s) and modeler(s) are not necessarily the same individuals, and this calls for constant, careful coordination. There are wonderful models with poor GUI's, or none at all, and fantastic GUI interfaces to terrible models. Better to sort out which is which. Some of the most successful GUIs have appeared (though is has some vexing bugs traversing the International Dateline) for mobile applications on portable devices. Google Earth⁸¹is a superb example.

Although there are a host of commercial GUI developer kits available, some particularly successful applications have been developed quickly, and on the cheap, by co-opting, for instance, the Microsoft Office suite of applications (Excel, Access, Project, etc.) These packages represent hundreds of millions of dollars of development, all aimed at the sort of system operator the modeler is likely to encounter. Despite all the criticisms of any particular software suite, such as this one in particular, it presents a huge opportunity to develop a model, supporting data base(s), and GUI, with the reasonable expectation that the planners will already be quite familiar with the tools employed.

6.31.1 Training

Training for model use can involve elaborate, formal courses, including not merely model options and controls, but material on any underlying theory, and interpretation of model behavior. Training materials can range from manuals to pop-up windows on screen displays. If the model is supported by an elaborate graphical user interface, videos with voice-over instruction can be very effective.

6.31.2 Report Writers

Report writers are designed not just to convey the "what" of a solution, but also to lead to recognition of the "whys." These are not as attractive as a well-designed GUI, but offer much richer detail. They create detailed accounts, frequently in a tabular format. Alternatively, report writers can populate a database invitingad hocqueries and planner-designed custom reports and graphics. Report writers typically get more sophisticated with model use, as successive questions arise inviting additional solution analysis and diagnosis. It is not uncommon for report writers to consume much more development time than the model they support.

One effective means to communicate strategic business results is by generating a set of forecastoperating statements.^82,83Nothing grabs a senior executive's attention more than details that follow all the way to projected influence on shareholders' equity. Gordon Bradley [14] and Art Geoffrion [15] did this for General Telephone and Electric (GTE) Corporation in the early 1980s.

Sometimes, a model represents a problem well, but not the way the decision must be made.

6.31.4 Persistence and Monotonicity: Examples of Realistic Model Restrictions

Now suppose we have briefed our solution, and the client admits that the maximum weight budget was an estimate, that there may be some variation in the true maximum weight, and asks us for aparametric sensitivity analysisof possible maximum weights ranging from 95 to 105kg. The client wants to be ready to brief for these contingencies.

The 11 rows following "optimal" inTable 6.10show optimal selections as we vary maximum weight from 95 to 105kg.A reasonable client will hate these optimal results.How do you explain a selection portfolio that exhibits so much chaotic turbulence as one simple parameter, maximum weight, is gradually, systematically increased? Well, declaring "this is optimal" will not likely suffice.

Clients expect parametric transitions that are intuitive. Here, the client might prefer abase portfolio, say the one we produced with maximum weight 100kg. Then, each time we reduce the weight budget, we only permit deletion of a single item from this base portfolio when we must, retaining the rest. Conversely, as we increase weight budget from base, we only allow a new item to be selected in addition to those already in the portfolio. This is intuitive. Less weight budget, fewer item selections, more weight budget, more item selections, while always preserving all but one item in the portfolio. This is concise. These are calledmonotonic parametric solutions. InTable 6.11, you will find "monotonic" results for the base portfolio with maximum weight 100kg.

The client may be disappointed that from 100-105kg maximum weight budget, no new monotonic item is selected. This is because the area constraint requires that we make room for a new selection by deleting some existing ones, and the client told us not to do so. The monotonic solution is a restriction of the optimal solutions that did make such substitutions (with excess gusto) and with respect to the base portfolio, this restriction reduces our maximum total value selected.

A reasonable client might then agree, "OK, you can make room for a new item selection by deleting an existing one, but never more than one of each to keep things simple to explain." This is an example ofpersistentparametric solutions, here limiting the changes to at most two per adjustment of maximum weight budget. These results are shown in the "persistent" section ofTable 6.11.

These persistent results are a restriction of optimal ones, but not as restricted as monotonic selections. Note the maximum total value selected is no better than optimal, and no worse than monotonic.

A reasonable client may ask for more variations like these, seeking insight, but more important seeking some way to understand results in order to persuasively convince others to change policy and follow our advice.Figure 6.15shows portfolio values as we vary our maximum weight budget.

"A manager would rather live with a problem he cannot solve than accept a solution he cannot understand,"

G. Woolsey

Figure 6.15The base portfolio here is for a weight budget of 100 kg. This shows the trajectory of optimal portfolio values compared with persistent and monotonic ones as weight budget is decreased, or increased from this base portfolio. (The connecting lines serve merely to highlight each discrete series of solutions.) Persistent solutions here permit at most one item to be deleted for each one added to the base portfolio as we decrease or increase weight budget by 1kg. Monotonic solutions permit only one item to be added or dropped from the base portfolio as we, respectively, increase or decrease weight budget by 1 kg. These three trajectories diverge from the base portfolio weight budget as we decrease or increase this budget and eventually meet as the weight budget decreases so much that no item can be selected, or increases so much that all items are selected.

6.31.5 Model Solutions Require a Lot of Polish and Refinement Before They Can Directly Influence Policy

Solutions must have the following attributes:

Understandable. Is it clear what our item selection advice means?

Actionable. Do we have authority to select these items in these numbers?

Legal. Are we allowed to choose this portfolio of items?

Monotonic. See prior.

Persistent. See prior.

Robust. How good is our solution if our assumptions are wrong?

Resilient. How good is our solution if some selection is thwarted?

We don't have space here to develop all these points in depth, but each of them arises constantly in real-world practice. Be reassured they can and have been addressed successfully in many commercial, government, and military venues. Just be ready for surprises from your client, listen well, evaluate, and brief with clarity not just the restricted advice, but the costs these restrictions have inflicted. Some restrictions are laws of physics, others "email from God" policies, but many are flexible preferences, thumb rules, tribal wisdom, or conveniences that may inflict punitive penalties. With diplomatic caution, try to expose these penalties.

6.31.6 Model Obsolescence and Model-Advised Thumb Rules

It is time toretire a modelwhen the problem it addresses is solved by other means or replaced by other concerns. However, it is premature to retire a model after it has lent so much insight to planners that they can solve the problem without model help. In such cases, continued model use can alarm when some condition has changed that the planners have misdiagnosed. Even for very successful models, looking back five years, you will see few of these are still in use. Creative destruction is a fact. Model obsolescence is the rule, not an exception.

A most impressive recent example of technical obsolescence has been replacement of legacy enterprise resource planning (ERP) systems paid for by license fees based on possession and number of users, with equivalent functionality of applications residing and used in "the cloud," some with merely per-use license fees. This is a modeling revolution that has ERP industry giants scrambling for leverage and dominance, new entrants suddenly thriving, and some of the best-known legacy ERP providers trying to buy contemporary technology and keep up.

"The lowest level of understanding is when you convince yourself you know the answer;

the next level is when you convince a colleague; and

the highest level is when you convince a computer."

R. Hamming

6.32 Software

An analyst generally needs familiarity with and access to a number of software tools: text editor, presentation slide maker, spreadsheet, graphics, statistics, simulation, optimization, general-purpose programming, and geographic information system. If you are affiliated with an educational institution, you likely have free access to a wide variety of software packages that would normally cost a lot more than your portable workstation. This provides a great opportunity to try a variety of packages.

Even if you are not affiliated with an educational institution, there are a number of excellent, inexpensive, or free software packages. For instance, the Microsoft Office Suite⁸⁴includes thetext editorWord, thepresentation slide makerPowerpoint, andspreadsheetExcel, which includesgraphicsfeatures. Thestatisticspackage R⁸⁵is free and well documented. Manysimulation packages⁸⁶are freely available, offering libraries of random statistical generators and live animations. Someoptimizationsoftware⁸⁷is available in Excel, and a large variety of other packages are available.General-purpose programminglanguages such as Python⁸⁸are available and well documented. Google Earth⁸⁹provides a globe, map, and ageographic information system; a user can mark points, draw objects, and make animations on the Earth's depicted surface, political and geographic features can be depicted as the viewer's perspective moves over, toward, or away from the surface, and these displays are portable between computers via simple email attachments. Somegraphicssoftware⁹⁰is embedded in the preceding suggestions, but more general utilities can be used to make still images and movies.

When choosing software, make sure each package can be added to your modeling federation as a compatible component. Look for examples of, for instance, a spreadsheet that can invoke a simulation as a subroutine. If you suspect you'll need some help, check for online blogs and a users' group that supports a package. Also, be mindful that the more existing users there are, the less likely the package is to exhibit annoying bugs. It is said that Microsoft Excel has more than a billion users worldwide: that's a lot of experienced potential users for anything you make with it.

Question:

1. I need to get some clear idea about this topic since I need to make some presentation slides on this and talk for 30 min on the above topic.

You can include anything from other sources too and help me to make a content so that I can make my presentation with different key points to talk about and explain the given topics properly and talk for 30 min at least.