Missing the Date – Arriving Late to the Party

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.

Happy modeling!

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