1. Visualize success.Try to visualize what a project would look like if it were a stunning success. Take note of how it will affect all the people involved and write down any others you think it might touch. Take all of these people and put them on a spreadsheet column. Now in rows across, write down the attributes they need in the machine/process. Use this when evaluating solutions and communicate shortcomings to those affected. Come up with workarounds or throw out the idea if the results won’t be acceptable.
2. What’s driving the project?You need to understand what is the most important motivation for doing this particular project and use that to guide your decision-making.
3. Helping people.Automation can do many things, but one must be aware that its purpose is to do real things in a given ecosystem. Keep in mind that the goal is to have systems engineered to serve humans, not the other way around.
4. Project definition is critical.Without doing true engineering work, everything you learned in school and in your career up to this point, you are not doing any project properly or professionally. By creating definition for the project and then verifying that the project will answer the need, you are on your way to successful project management. It is only the start, but without a properly defined starting point, it is difficult to complete (or defend) a meandering, ill-defined project that is meant to resolve a problem, address a challenge or complement your company's engineering resources.
5. Start with the objectives. Don’t even begin to select suppliers and service providers until you’ve established a project’s objectives. Make sure everyone on the team agrees on what the project needs to achieve before it starts. If you don’t know where you’re going, you’ll never get there.
6. Get a second opinion. It pays to get a second opinion from an informed outsider like a systems integrator or machine builder before finalizing project objectives—they’ll often do it for free. If you bring them in at this stage, so that they understand the history of the project, they can contribute to decisions that will improve the chances for a successful project.
7. Set rules for communication. Define what communications are expected at the start of the project – what is to be communicated, how it is to be communicated, what the milestones of the project will be and how often things should be communicated.
8. Talk to everyone.Interview the stakeholders from various factory disciplines, such as operations, maintenance, quality control, supply chain, shipping and management. They always have a stake in every automation project.
9. Never assume. Don’t make assumptions about the ground rules--spell everything out in advance and define who is responsible for doing what.
10. Create a chart to keep objectives clear.Define the expected performance for each subsystem, and the expected steps to get there. Use Excel to list the task steps, and the hours/$ across a time matrix. Then that becomes a calendar for the schedule, sort of a compressed MS Project. If you color the boxes, it becomes a Gantt chart. Putting all your objectives (the completion of functioning subsystems, integration) into one simple chart keeps those objectives clear to the whole team.
11.Spell everything out.If you want drawings in portrait versus landscape mode, for example, or want certain brands to be used, such as for wire or PLCs or other components, state that up front. If a requirement is not written down, then it likely will not happen.
12. Scope!Nothing is more important than a scope that reflects both the well-defined areas of the project and the grey areas of the project. The grey areas should have a general framework put together by the customer and the implementer, with benchmarks that clearly indicate when project re-assessment should occur. This way scope creep can be managed to the benefit of both parties.
What do they really want, and why?
It’s essential to understand each person’s expectations before a project starts. There are three parts to this definition process:
- What outcomes or desired results does the project team want to achieve?
- What do they want the project experience to be like (for example, no production line shutdowns during the project or communicate updates by email)?
- How will they define quality, such as on time/on budget or increased production volumes or zero downtime, at the end of the project?
Different people will have different expectations and they all have to be satisfied.
Liked this article?Download the entire playbook here