We have already covered the importance of project objectives and specifications. Of course setting those objectives requires knowing your stakeholders and getting their involvement. In this and other articles I use the term stakeholders to represent the set of people who care about this project. It could be your customers, your manager, people who work in the systems being modeled, or others.

Step 2 – Creating a Project Plan

When creating a project plan, two adages come to mind.

“Expect the Best; Plan for the Worst”

I think it is fine to be an optimist and hope, maybe even expect, that things will go well. But I don’t count on it. I don’t base my plan on optimistic assumptions. I like to start with what seems to be a reasonable estimate, then double it to account for all the things that I know will go wrong. This may seem like “padding” but the objective is to determine an achievable schedule. I have seldom, if ever, found what seems up front to be a “reasonable” schedule to actually be achievable in the end due to the large number of unknowns in a typical project.

Of course you can always spend more time up front studying the problem to reduce the risk to an acceptable level and possibly improve the accuracy of your estimates. But by that time the project has often become irrelevant because the decisions have already been made. Time estimates are always a guess and always wrong, so find a method that works for you and move on.

“Under Promise, Over Deliver”

To me this means be conservative. I try to avoid over-committing and, when possible, avoid sharing my optimistic intentions. For example, while I may have every expectation of creating a compelling 3D animation, I might only guarantee 2D animation or simple 3D animation. Or while I might intend to model some secondary applications so that I might explore some potential system improvements, I would not guarantee that in the project specifications.

In fact, my project specifications usually include three categories:
• Guaranteed Deliverables – No matter what happens, the project is not considered done without them.
• Likely Deliverables – I intend to complete these, but if things go poorly, they may be cut. Often the stakeholders do not even know this list exists, depending on their tolerance for flexibility.
• Wish List – In the rare instance when the project goes exceptionally well, I implement tasks from this list. This list never makes it to a public project plan.

This approach provides me some flexibility to:
a) Avoid disappointing the stakeholders in case the project goes poorly, and
b) Retain the opportunity to delight the stakeholders if the project goes well.

What Comes Next?
These first two steps are just the start of a project. In future articles I will discuss prioritization, agility, communication and many other topics that contribute to making the date and making a successful project.

How many times have you shown up late to an event? Perhaps something came up at the last minute. Perhaps you encountered road construction. Or maybe you just failed to think ahead. Sometimes it all works out. But sometimes you miss something important – like your sister’s wedding vows or your child’s big performance.

In an earlier article, we talked about the importance of project planning and management. Although there are many aspects to success, let’s concentrate on the completion date for the next few minutes. A project that produces results after the decision is made has little value. And a project running over budget due to lateness may be cancelled before completion. Success requires appropriate attention to completion dates.

Late projects are a chronic problem in all types of software development. Let’s start by exploring some of the causes of lateness.

Expectations – Planning the Journey

In software development the constraints of Date, Resources, Features, and Quality are well known. You can specify or mandate any one, two, or possibly even three of those factors, but if you try to mandate all four, you will almost certainly fail. For example, I can say I want all features completed with high quality, in 90 days, but then I have to be prepared to allocate resources as necessary. Or if I want it done with a maximum of 3 people, then I must be prepared to slide the date or other constraints. These same aspects apply to most simulation projects – perhaps substituting the word Comprehensiveness for Features and the phrase Validation/ Verification for Quality.

Since many projects start off in an urgent, budget-constrained status, management often tries to mandate all four constraints. But can I really specify all four constraints (e.g. all features completed with high quality, in 90 days, with a maximum of 3 people)? NO – not unless I have started with a very loose schedule (unlikely with an urgent project). I have generally found that attempting to do so will just mean that I will have no idea, until near the end, by how much each of the constraints will be missed. Note I said “by how much”, not “if”. As the anticipation of missing the date approaches, the pressure will increase at all levels to “cut corners”. Then, to save the viability of the project there is often a last-minute attempt to add resources to “save the date”, but that attempt is usually too late to have much impact.

Road Construction Next Million Miles

Assuming that we have reasonable expectations up front, what are some of the other problems that can hijack the schedule?

Objectives – Poor project objectives, as we discussed last week, is a huge potential problem. If you start with a missing or inadequate functional specification and a poor understanding of project, it is unlikely that you can develop a realistic project plan.

Optimism – I like to be guided by Murphy’s adage “Anything that can go wrong, will.” Many people think that it is safe to base their project estimates on “reasonable” effort estimates. But “reasonable” often becomes highly optimistic when adjusted by real world situations.

Stakeholder Involvement – First of all, you need to know who your “customers” are. If you are working for a large organization it might be difficult to determine who all the people are who have a stake in your project. If you are a consultant, this may be a bit easier. But after you identify them, the stakeholders must be involved. If they are not involved then you may be missing the important resources and information, and your project priority may suffer.

Skills – We are all smart, resourceful people. We all like to believe that we know, or can quickly learn, whatever we need to know to complete the project. But quite often there are many things we don’t know. And even more dangerous, there are things that we don’t even know that we don’t know.

Of course there are many other areas where you could go wrong – I’ll talk about them in future blogs. For now, maybe give some thought to these concepts and in a future blog we will talk about dealing with this first set of pitfalls.

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…

On my second professional model, now that I thought I was an expert 😉 , my manager came to me and said “Prove this…”. He had the very common situation where an associate wanted to make a major investment, but could not convince upper management. This is a perfect application for simulation – a model can provide objective information on which to base such a decision.

This was a much better situation than my first experience. This time I had a motivated, involved stakeholder. I had a clear objective. I had important meaningful work. Life was good.

For a while.

Until the model started to “dis-prove this”. Experimentation led me to believe that other alternatives might be better. I told myself that I must be wrong. I double checked but I could not find any errors. Then my boss and the stakeholder told me I was wrong. I triple checked but I could still not find any errors. Life was no longer so good.

What went wrong?

We started with the result. When I set out to prove a conclusion, I put my integrity at risk. The best I could hope for was that the model actually “proved” what they wanted. A typical client reaction to that situation is an empty “I already knew that!” feeling and the perception on his part that I provided very little value. Worse is when the model contradicts their conclusion. It does not support a “known fact“. In that case, stakeholders might think I am incompetent or that simulation offers no value.

But the worst case of all would have been if the model disproved what the stakeholder wanted, but I kept “fixing it” until it supported their conclusion. My client may be satisfied, but do you think he will ever bring me real work? Unlikely. I would have just proven to him that a model can be made to produce whatever result you want, and that my integrity is low enough to do that.

When similar situations arose later in my career, my responses were:

–I will be happy to evaluate that situation for you, but I cannot promise what the results will be.
–If what you really want is just a supporting statement, I cannot provide it without objective criteria on which to base it.

While the above does not always create good will, it does allow me to keep my integrity. As much as I hate to admit it, intentionally misusing a model to create invalid results is often easy. Integrity is often the most important thing that you and I can provide as simulationists. A simulationist without integrity should look for another line of work.

When I first started modeling, my boss came to me and said “Model this…” and then proceeded to describe an area of the plant that he thought “might benefit from having a model”. Unfortunately there were no specific objectives beyond that.

To me, a new simulationist, that sounded like an ideal project. Nothing to prove… Nothing specific to evaluate… No one waiting on specific results (because none were asked for)… It even sounded like a good opportunity to learn how to model. But it was not.

“Model this” generally results in a useless project. A waste of time. Without clients or clear objectives, I could not know what to model. Without clear objectives, I had little motivation to learn how to model tricky situations; I instead tended to bypass them to work on aspects more fun or interesting. In fact, for the same reason I often did not even recognize modeling challenges, so I never learned to deal with them.

Moreover, when it was all done, what did I have to show for my time? Perhaps a cool-looking animation. It probably did not have many aspects of reality to it. Reality is driven by close interaction with the stakeholders – oops, I did not have any of them. Why should anyone waste his or her time sharing domain knowledge with me, when I was basically just modeling for fun?

And worse, after I “finished” the model, I was overconfident of my modeling skills – after all, I modeled everything I set out to model, right? Of course I was never forced to really verify and validate against the real system, so I never really had any idea how good the model really was.

Avoid “model this”. Always push for clear project objectives. More on that next time.

This article continues a brief exploration into how you can be more successful in your simulation projects. (Look here for part 1.)

Here is a second set of important issues that should be considered.

Agility – You can count on the fact that what you are modeling will change. If the system itself is not changing, the detailed project objectives will. Use a technique that allows you to stay agile enough to cope with the inevitable changes.

Solve Problems – Don’t see yourself as just a model-builder. See yourself as a problem-solver. Think outside the box. Recognize opportunities. Don’t simply provide a service, add value.

Software – Software selection is often difficult, particularly if budgets are tight. Domain-specific or generic? Easy to use or flexible? Established product or state-of-the art technology? Many factors must be considered.

Know Your Stakeholders – Who is funding the project? Put yourselves in their position and determine what their concerns are and what they would like and need to see from this project.

Credibility – While simulation provides a degree of objectivity, to many it is still a “black art”. At the end of the day if you don’t have personal credibility, all the backup data possible will not be able to sell your ideas.

Certainly this was a very brief treatment of only a few key factors to success. Future articles will discuss these and others in more detail.?