In an earlier article, we dissected the project scope and explored the work breakdown structure (WBS). The WBS is the disaggregation of the scope into the work products that are required to meet the defined scope. Now, we are going explore setting about doing the work, from a schedule, or perhaps we will not even build a schedule.
The fundamental start of any project is a scope of work document, which specifies what we want the project to achieve. The project scope may start out broadly described based upon business objectives, but it will become increasingly detailed over time.
In my first postcollege job, I was a manufacturing engineer for Cummins Engine Co. in Columbus, IN. Two weeks into the job, my boss came to me with a project to purchase an industrial wash system, and I leaped at the opportunity. It was a disaster.
When manufacturing engineers are tasked with automating a process that is currently done manually, their main question for an automation supplier is, "Have you ever automated this specific process before?"
Your company has just decided to add a new product to the lineup, and now it's up to you to purchase a new assembly line. No worries. It's just like buying something on Amazon, right? You search for a product with at least a four-star rating. You browse a couple reviews. A few clicks later, you're all set.
Project quality and product quality are different things, but they are inextricably linked—or they should be. It is possible for a project to seem successful and deliver the anticipated result, only to find out later the product is not what was expected.
With the cost of automated assembly systems running six or even seven figures, choosing the right integrator and establishing a good relationship are critical.