Simulation Stakeholder Bill of Rights

The people who request, pay for, consume, or are affected by a simulation project and its results are often referred to as its stakeholders. For any simulation project the stakeholders should have reasonable expectations from the people actually doing the work.

Here I propose some basic stakeholder rights that should be assured.

1. Partnership – The modeler will do more than provide information on request. The modeler will assume some ownership of helping stakeholders determine the right problems and identify and evaluate proposed solutions.
2. Functional Specification – A specification will be created at the beginning of the project to help define clear project objectives, deadlines, data, responsibilities, reporting needs, and other project aspects. This specification will be used as a guide throughout the project, especially when tradeoffs must be considered.
3. Prototype – All but the simplest projects will have a prototype to help stakeholders and the modeler communicate and visualize the project scope, approach, and outcomes. The prototype is often done as part of the functional specification.
4. Level of Detail – The model will be created at an appropriate level of detail to address the stated objectives. Too much or too little detail could lead to an incomplete, misunderstood, or even useless model.
5. Phased Approach – The project will be divided into phases and the interim results should be shared with stakeholders. This allows problems in approach, detail, data, timeliness, or other areas to be discovered and addressed early and reduces the chance of an unfortunate surprise at the end of a project.
6. Timeliness – If a decision-making date has been clearly identified, usable results will be provided by that date. If project completion has been delayed, regardless of reason or fault, the model will be re-scoped so that the existing work can provide value and contribute to effective decision-making.
7. Agility – Modeling is a discovery process and often new directions will evolve over the course of the project. While observing the limitations of level of detail, timeliness, and other aspects of the functional specification, a modeler will attempt to adjust project direction appropriately to meet evolving needs.
8. Validated and Verified – The modeler will certify that the model conforms to the design in the functional specification and that the model appropriately represents the actual operation. If there is inadequate time for accuracy, there is inadequate time for the modeling effort.
9. Animation – Every model deserves at least simple animation to aid in verification and communication with stakeholders.
10. Clear Accurate Results – The project results will be summarized and expressed in a form and terminology useful to stakeholders. Since simulation results are an estimate, proper analysis will be done so that the stakeholders are informed of the accuracy of the results.
11. Documentation – The model will be adequately documented both internally and externally to support both immediate objectives and long term model viability.
12. Integrity – The results and recommendations are based only on facts and analysis and are not influenced by politics, effort, or other inappropriate factors.

Note that every set of rights comes with responsibilities. The associated stakeholder responsibilities are discussed as part of the Simulationist Bill of Rights.

Give these expectations careful consideration to improve the effectiveness and success of your next project.

Dave Sturrock
VP Products – Simio LLC

Well – Managed – Agility

In previous articles we discussed a definition of agility and the potential oxymoron of managed agility. I coined the phrase “well managed agility” as part of the solution. I was asked why I used the word “well” in that phrase. The short answer is that anyone can say they are agile. And anyone can say that they manage agile. But doing both and doing them well is the key.

Good management in general is a topic I’ll leave for later. Today, I will concentrate on managing the process of change.

The most important part of managing agility is to have a single person (or a small team that works cohesively) responsible for the agility. Ideally this person, who I’ll call the agility manager, should be knowledgeable and sensitive enough to understand:
1) What the stakeholders want,
2) What the stakeholders need, and
3) The issues involved in delivering the above two items.

The project demands a lot from the agility manager. It demands the ability to get inside the heads of stakeholders and really understand not only what they want, but what they really need. Sometimes even the stakeholders don’t know what they need until they see it (or miss the lack of it). The agility manager must also understand the issues and tradeoffs on the development side of actually meeting those needs (including deadlines).

Some common agility challenges include:
• The system being modeled changes (perhaps the design has evolved, or “assumed” aspects have just come to light)
• The stakeholder objectives change (date, modeling details, purpose of model)
• Modeling problems are discovered (modeling or data collection may be more difficult than expected)
Often changes like these make current plans invalid. Of course the stakeholders want it all and many conscientious modelers will want to say yes to satisfy the stakeholders.

To do the job well, the agility manager must be someone who understands all the above aspects and who can take the broader view to determine what action best serves the stakeholders? Choices like adding feature A versus doing a more thorough job implementing existing feature B, when you don’t have the time or resources to do both. Or when a project is running behind schedule, is it better to schedule extra effort, remove some features, or postpone the delivery date? Only a very knowledgeable manager can correctly make these decisions by carefully weighing the benefits/rewards of each action.

Even better, the most effective manager will try to avoid having to make big decisions like the ones above, by instead making correct calls on numerous similar small decisions that arise on a routine basis. In a future installment I will discuss managing the “routine” and some tools and processes to facilitate that.

Dave Sturrock
VP Products – Simio LLC

Well Managed Agility – Start With No

Last time we talked about a definition of agility: The capability of being flexible and responsive to changes in the world around you. And I suggested that Well Managed Agility is one part of the solution for the question of “How much agility is enough?”

Is Managed Agility an oxymoron? It can sound like one. And some people equate agility with a lack of management, a free-for-all. That can be true when agility is taken to the extreme and poorly implemented. But agility certainly can be managed in many ways.

The first step to managing agility is simply acknowledging that agility can and must be managed.

I once joined an organization where there was major project in process that was getting later every day. The later it got, the more the stakeholders realized that the originally planned results would no longer meet their needs. So the stakeholders insisted on changes. The organization, who felt bad about the late delivery, almost always said yes in a futile attempt to placate the customers. Unfortunately, the more changes that were accepted, the later the project became. My job was to bring the project back on schedule.

One aspect to getting a project back on schedule (we will discuss others in future blogs) is learning to say no. In this case I changed the process so that all major decisions, and all communications with the stakeholders, went through me. This was not because I was any kind of an expert. Quite the contrary – I was a novice at the subject matter. But I did know how to get the right people involved to exercise good judgment. And I did have the guts to say no when it needed to be said.

The salesperson involved was livid – “You CAN’T say no to a major stakeholder.” My response: “Watch me!” The alternative of saying “yes” with the knowledge that delivering is not possible, is just flat out lying to your stakeholders. While no one wants to be told no, I think that most people would prefer an honest “no” to a dishonest and meaningless “yes”.

As expected, the primary stakeholder was initially angry when he was first told no. But he soon realized that this was the first time he had been given an honest answer. And this was actually the start of what later became a great and very positive relationship. The salesperson also became a friend for the same reason.

Next time I’ll talk about other steps to managing agility. In the mean time, if you are working on a project that is behind schedule, start practicing the word “no”.

Dave Sturrock
VP Products – Simio LLC

Just Enough Agility

Agility is the capability to be flexible, responsive, and adaptive to the changes happening around you. When a stakeholder asks you to deliver something you had not planned on, your response is a measure of your agility. But how much agility is enough?

I was once part of an organization that was extremely agile. Whenever anyone in the organization had an idea, it would send the developers off in a new direction – quite often before they were half done implementing the previous idea. It was like a rudderless sailboat. Although we had an intended course, we never followed it and were instead at the mercy of the wind to see where we were headed that day.

I have also been in an organization where they wanted detailed plans for two years ahead, and any deviation from the waterfall plan required an “act of God”. In this organization we generally knew exactly where we were going. Unfortunately, we also knew that if and when we eventually got there, we would be in the wrong place. The world never waits. A goal set to satisfy stakeholder needs today will rarely match stakeholder needs two years from now.

Obviously each of these extremes has its pros and cons. I often wonder why so many organizations seem to live at one extreme or the other. I think neither is the right answer for most organizations.

So how much agility is enough?

There is no absolute right answer. Each organization and project will have its own right answer, and even that is likely to change over time. But I believe for most organizations and projects, the answer should involve what I call Well Managed Agility.

Next time I’ll talk about what I mean by well managed agility and how you can achieve it. In the interim, I’d love to hear about your experiences with agility or lack of agility.

Dave Sturrock
VP Products – Simio LLC

Project Objectives and Specifications – Driving your Customer to Success

Most projects start with a concrete deliverable date, but often only a rough idea of what will be delivered and only a vague idea of how it will be done. But as the old saying goes “If you don’t know where you are going, how will you know when you get there?”

To start with, I’ve learned over the years that you need to know your stakeholders. Who is funding the project? Who is using the model and its results? Put yourself in their positions and determine what their concerns are and what they would like to see from this project. What is the real motivation for this project? How will they measure success? After all, they are the passenger(s) and it’s their desired destination.

You need clear objectives as early as possible. In order to help find out what these are, you must ask these questions:

  • What do they want to evaluate or hope to prove? Short, concise goals are best.
  • What is the model scope? What system aspects must be considered?
  • How much detail is anticipated for various system aspects?
  • What input data do they anticipate being used and what is its availability?
  • How much experimentation will be required? Is optimization required?
  • In what form do they want results (detailed numbers, summaries, graphs, textual analysis, …)?
  • Do they want animation, and if so how will it be used? Animation for validation is often quite different than animations presented to a board of directors.
  • TIP: One way to enhance early clarity is to create a mockup of the desired final reports. Doing this as part of the specification phase can clarify many aspects of the project. Possible questions to ask would include: What items do they want to see? What alternatives should be compared? What statistical measures are they comfortable with?

    Getting lost before you even turn over the engine?

    Sometimes the desired project clarity is not there at the beginning. If this is the case, you are just fooling yourself if you plan the entire project including deliverables, resources, and date. Lack of early clarity is a key indicator that a project should be done in phases. I have found starting with a small prototype often helps clarify the big issues. Based on those prototype experiences, you might find that you can do a detailed plan for Phase 1 and a rough plan for any subsequent phases.

    An alternative approach is to start by doing a full functional specification. Some organizations spend the first 5-10% of anticipated project effort creating a functional specification. Your functional specification should describe all of the objectives discussed above in enough detail that the project approach and effort can be accurately estimated. While this effort may seem high, it generally pays off in a more robust, predictable project and deliverables.

    I plan on sharing more about functional specifications in a future blog. Until then, Happy Simulating…

    Dave Sturrock
    VP Products – Simio LLC