Clear objectives in modelling
This week, I want to start my series on 12 core points that a simulation modeller needs to keep in mind when working with clients. These points were formulated by Dave Sturrock on the Simio Blog. The first post is on clear objectives:
“Clear objectives: A simulationist can help stakeholders discover and refine their objectives, but clearly the stakeholders must agree on project objectives. The primary objective must remain solid throughout the project."
I will pick out two themes from this statement: First, objectives need to be clear. Second, they must remain visible throughout a project.
There was a clear objective in this project...
There is a good reason why this is the first item on the list: clear objectives are critical. It’s self-evident that you need objectives to agree on a project. However, the very first step to ensure project success is to make those easy to understand, follow and agreeable. I find that a good marker to check if your objectives are clear is to put yourself into the position of the boss that did not attend your meetings: She is aware of your project and found some time to review the initial meeting minutes where you agreed objectives. Will she be able to understand them without all the implicit communication that occurred in your meeting? Check the two statements below:
- Simulationist Inc. will provide a model of factory X of ClientCo Ltd.
- Simulationist Inc. will provide a model that comprises the new layout of factory X (level 1) of Client Co. It includes the machinery of type Y but excludes other floors and machines of type Z.
All too often, the former statement prevails. The reason is that implicit communication and agreements are very powerful. It is so easy to agree without noting it down. Make a conscious effort to overcome this bias.
Let’s examine the second theme: your clear objectives must remain the central pillar of your project. To some extent, this is a truism but all too often, they are the first to go. I found it is good practice to do a weekly review of what you did towards your project and align it with your agreed objectives. By that, I mean to go through each piece of work and ask yourself: Did this move the project towards its objectives? And if so, how?
What happens when you loose sight of objectives...
Consider the example we talked about above: Last week, you started to develop the model and draw the factory layout. Did this go towards your objectives? I’d say so. Now say, your client asked you to do some research to see if machinery of type Y (we agreed to exclude it) might be useful after all. With clear objectives, you will easily judge that this work did not help achieve your agreed objectives. However, had you only agreed on the non-clear objectives, you might be tempted to count this research to help your objectives, right?
This is not to say that you should be a machine that is totally focused on your objectives. Your overarching objective is to help your client so by all means help in investigating that other machine type if the situation allows for that. But in your weekly review, be clear that this activity did not help you in your project objectives. This will help focusing your efforts and improve communication with your client.
Clear objectives are critical. Ensure you focus on precise formulation and revisit your objectives at least weekly.
This post is part of the blog at www.benjamin-schumann.com/blog/ .
Hi Ben, Good post and nice illustrative pictures! On that subject, I just wanted to add a very important insight and opinion related to the objectives. I would formulate the summary at the end like this: Clear objectives are critical - and will almost inevitably change and evolve during a modeling endeavour. Ensure you focus on precise formulation and revisit your objectives at least weekly. The thing is, you very rarely see all the objectives during the "project specification phase", since they will evolve during the work - and they should do so and be allowed to! So quite often the most important clarity at the beginning of a project is to be clear about this - that the objectives will change ...!!! As the objectives portfolio evolves and changes, it is of course very important to continuously update it - but one should not see these updates as exceptions, but rather as the rule - and prepare for it from the start. So therefore I do not fully agree with Dave Sturrock's last sentence in his first point (a good list of points by the way): The primary objective must remain solid throughout the project. No it mustn't (at least not necessarily so), even though it of course is simpler if it does! This can quite easily be compared with the view of Strategy within management. According to the "Classical scholl" (Ansoff and others), a strategy is something that is thoroughly planned in advance and followed. According to other authorities (Mintzberg, ...), strategy emerges and changes must be handled - so the original plan must be reformulated if needed! Of course - summarized by me in very simplified form! The challenge with this - evolving and emerging objectives - is of course evident from a consultant versus customer perspective. In these situations - when one deems that the "risk" of changing objectives is present - several "tactics" can be used. One is to divide the project in 2 or more phases, to be able to reevaluate the objectives for each state. And there are others. So my point is, a project where the objectives do not - in some form - evolve, is either very clearcut, quite basic - or unusual! The rule is rather that they do, we should be prepared for it, and we should embrace when it happens (since it often is proof that our work-in-progress is bearing fruit!) :-)