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…