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

    Tags: , , , , ,

    2 Responses to “Project Objectives and Specifications – Driving your Customer to Success”

    1. Doug Roberts says:

      I am a big fan of planning ahead and am 100% behind defining clear objectives before starting a project. The article gives two approaches how to begin working on your project – doing the work in phases or doing a full functional specification. I think that each one has its benefits but think that your level of experience and comfort with the project should dictate which one you choose to go with. I believe that someone with minimal experience would be better off doing the project in phases. A beginner will not be as comfortable doing a full functional specification and may leave things out as a result. By doing a project in phases they are able to still plan ahead but are able to get feedback on how they did on each step along the way, therefore building their confidence in how to plan ahead and define their objectives in the future. I am not disagreeing with the article, but as a beginner in simulation myself, feel that this approach would be of more benefit to me personally.

    2. I have a secret to share, Doug. Even most professionals are often not comfortable doing a full functional specification on a typical project and are likely to make mistakes as a result. So I agree with you that a phased approach is very often preferable for all but the smallest and simplest projects, regardless of the modeler’s skill level.
      But that doesn’t eliminate the need for a FS. It just means you have a solid FS for phase 1 and (initially) a much less detailed FS, subject to later revision, for each subsequent phase.

    Leave a Reply