Home / Blogs

Standards and Projects: Separate but Connected

Has a client ever told you, “We would like to develop our standards while executing this project?” This statement is usually followed by the assertion that the project timeline will not change, and that improved standards will in fact speed the project toward its deadline.
Nothing could be further from the truth. Projects have an installation target date, while standards development requires many levels of discussion, agreement and buy-in. The standards development team is then challenged to meet their timeline for definitions and sample code.
It’s true that once standards are developed, an efficient path toward a project due date can be developed utilizing these standards. However, when you mix the two, the standards become less defined and more subject to changes while the concentration of development efforts eventually are pulled into the race to complete the project on time.
Astute technical managers realize the two worlds are very connected, but at the same time must be managed differently. Standards development should be separated from the project itself; then all parties can decide if the project deadline will be determined upon standards approvals, or if the project can proceed without full standards.
Trying to manage standards and projects simultaneously can lead to murky standards and a rushed project. But you’re too sharp to let that happen to you, aren’t you?

5 Reasons Why Workplace Humor is a Necessity

The fact that I, the company accountant, was assigned to write this blog is humorous already. Jokes aside though, why put people and not humor to work? I mean, hard work never killed anyone but why take the chance?
read more…

Whatsamatta U: 8 Components of Successful Training Courses

I’ve recently been refreshing some internal training content for our Avanceon University and I wanted to share some items that we have found to be key in developing adult learning courses, whether the intended audience is our own staff or our customers. These eight design points help organize an effective training course and provide a framework for how to train and evaluate individuals.
1. Overall Training Objective – What is the training’s singular purpose? As an example, let’s talk about an overall training objective of providing controls engineers with basic System Platform troubleshooting tools.
2. Target Audience – Who is the training targeting? What is their background and experience level? For our example, this might be engineers who have not yet or just recently started with Wonderware.
3. Pre-requisites – What would attendees need to already know before attending this training? In my case, I would have wanted them to go through the prior training class, which is an Introduction into System Platform class.
4. Training Elements – What are the individual skills, tasks or activities that you want participants to learn? Make sure you break down the items as discretely as you can so that you have a more comprehensive offering and evaluation. There may be just a few or there may be a whole bunch. For this training example, I have a number of training elements. For the following questions, we can focus on the element of utilizing Object Viewer for detailed script execution information.
5. Objective Statements – Turn each training element into an objective statement. Objective statements are structured as follows: People (A), given (B), will do (C) to a level of (D) proficiency. For our example here, we might say Junior Wonderware Engineer, given an issue with a script, will utilize Object Viewer to ascertain the execution details of the script including, but not limited to, number of times executed, last date/time executed, average execution elapsed time, last execution elapsed time, number of times executed in error and did the last execution result in an error.
6. Resources – What item(s) does the attendee need in order to learn and demonstrate a given training element? These are typically things that need to be prepared in advance and given to the attendee during the training of that element. For my example training element, I would need a galaxy setup running a script that had a known error that I could point the engineer to troubleshoot.
7. Performance Indicators – How will you evaluate the attendee and know that they have mastered this specific element to the given proficiency? This might be demonstration, a written test or some other method. You should have an answer key, rubric or other scoring method to determine success on a given element. Here I would maybe create an answer key that would have what was wrong with the existing script and at least one acceptable correction to fix the issue.
8. References – What information needs to be provided for the attendee to accomplish a given element? This is especially important if you are creating self-paced training, but also if additional references might be helpful in developing a further understanding of an element beyond what is discussed by the instructor. For this example I might refer to specific sections in a training manual, user’s manual and/or deployment guide pertaining specifically to how to call up Object Viewer and what properties exist for scripts.
Have you found these to be important factors? What have you found is key to your training? Drop us a note and let us know. And don’t forget to tune in next time for another exciting adventure entitled either “Ar-‘Test’-ed Development” or “Classes with Curly”.

#PlantLife – To Beard, or Not to Beard

There comes a time in every man’s life when he must grow a beard. Within Avanceon I primarily work within the food and beverage business unit, but since Good Manufacturing Processes frown upon exposed body hair, a conflict with the aforementioned call to the wild presents itself.
So why beard? To some, facial hair is more than a style; it is a rite of passage. To others it is an act of self-expression. The act of not shaving also saves precious morning minutes. Above all else, though, it keeps my face warm during brutal winters. I’ve been growing an annual winter beard for the 3 years I’ve been at Avanceon (a previous employer disallowed any facial hair, blasphemers). I typically like to grow into a lightly manicured lumberjack beard, just enough insulation to protect from icy gusts of wind while not long enough to be mistaken for any cast member of Duck Dynasty. The perfect balance.
So why not beard? Good Manufacturing Practices must be executed while working in food and beverage facilities, which requires proper PPE, hair nets, and for those with facial hair to don a beard net. Beard nets, while protecting the quality of the product, can be irritating. Unlike the hard hat/hairnet/safety glasses, you never forget that you’re wearing a beard net. On more than one occasion I’ve sat down for lunch at a restaurant while wearing my safety glasses and hair net, simply forgetting that they are on. Such is not the case with the beard net. Other cons of the beard include food crumb accumulation, babies pulling on them, and the one month embarrassment period known as the “proto-beard”.
In the end, it’s all a matter of preference. Personally, I get more benefit from the warmth giving of the beard during winter months, so I tolerate the beard net. Once the weather warms up I reject the beard net and sport a naked face. How do you beard?

How I Learned to Stop Worrying and Love InBatch

Do you remember the now classic scene in The Lion King where a group of hyenas are saying the name of the king, “Mufasa,” to each other and the mere mention makes them shudder? “Ooooh! Do it again!” In my experience, there is an automation product that has the same effect on engineers and customers alike. What product is that? Wonderware’s  InBatch! No other software product has made my friends and colleagues shiver and shrink.
So why does InBatch instill “Mufasa” level dread? Oddly enough, the main reason InBatch is feared is the same reason it’s worthwhile. It’s powerful. InBatch is an incredibly flexible product that can do just about anything imaginable in automation and recipe management. But the only way to make it so powerful is to make it incredibly configurable. And that means that InBatch requires a pretty steep learning curve before that potency is accessible. People just don’t know how to use it. And when they try, their efforts often go poorly. It has taken me years and multiple projects to really get my arms around this software and figure out all the ins and outs and how-tos and what-to-dos. And now I feel like I am there. I am on board. The power is mine!
Over the past year and a half, I’ve been working on multiple projects with one of our partners who has had a long history with InBatch and has solid standards regarding how their installations operate. Their standards are highly integrated with System Platform, InTouch, and all the other Wonderware products. Their visualization approach prominently presents what is running and how efficiently without having to use the standard Environment Display tools. And the best of all, it works really well.
So for a year and a half, I’ve been living and breathing InBatch. I’ve been leveraging what we’ve done in the past. I’ve been learning from what our partner is doing. I’ve been adapting what I know for new project challenges. The thought of the next InBatch project no longer fills me with terror. I’m looking forward to the next opportunity to use this powerful software.
So do you fear InBatch? Tell us about your experience!