A project management blog for manufacturing and engineering
Use your voice to control timers when tracking manufacturing work orders.
Yep, voice control over work order timers. Now!
Let’s say you’ve got twenty work orders on the shop floor at any given time. Or fifty. And, you want to measure how long they take. Turns out, you can start a timer using voice control, and stop the same timer at a later time, also with voice.
The video below shows how.
If you’re a manufacturer using Standard Time® for your time tracking needs, it is significant to your business. You can affix barcodes to the products that will be manufactured and be able to follow it in every aspect of production. Know how long the assembly took to produce and also know which employee was working on it.
Scroll down for video.
Scan a barcode on each item during manufacturing, and you will get the following information:
With this information you can:
Standard Time® lets you see revenue estimates for your projects. Project revenue estimates are like Win/Loss charts. Another analogy is the traditional sales funnel. You win some projects, you lose others. And when predicting, you set a percentage of likely win. This chart shows the possible outcome over the next 12 months.
Has a customer of yours ever forgotten to get back with you about a feature you were developing for them? They were hot to finish, but then weeks went by and no word. Maybe the feature was almost finished, and you just needed a little more information to complete it. One phone call or email and it would be finished.
But guess what happens when these delays occur?
All the feature nuances you kept in your head are now slipping… A week goes by… Two weeks… A month… By now you’ve forgotten some of the little details that made finishing the feature so simple. You’ll have to relearn some of those and get the feature back on track. What would have taken a short time to complete will now take four times as longs.
When this happens, you are essentially reallocating resources to complete the job. In some cases when too much time has elapsed, you might just as well restart the project and reschedule hours to come up to speed. All that admin scheduling take time too.
Moral of the story: Don’t let these little delays creep in in first place. Stay on top of your dependent resources so they don’t leave you with a long forgetful delay.
Here’s just a quick reminder that homemade products stick out like a sore thumb. Have you ever encountered a product that was clearly not professionally produced? They just look awful, and one look at them screams, “Homemade!” or “Unprofessional!” It doesn’t take long for consumers to sniff you out and flee.
This past weekend, my wife and I stayed at a little ‘mom and pop’ motel in a little town in Colorado. With one step into the room, I got a good reminder of this issue. (See the pics below from my crap phone) The entertainment cabinet was hand-painted, and looked awful. I nearly fled the room, but decided the cost was cheap enough to entice me to stay. It turned out fine. But ugly little piece of artwork really drove this point home to me.
Consumers do not like hand-crafted products.
Let’s face it… we live in a consumer-oriented world. Almost every product we touch is machine made, and professionally crafted for maximum emotional indulgence. Think about the indulgent products you use on a daily basis: $50,000 automobiles… iPhones… stylish eyeglasses… jewelry… and more. Every product we use it slick and well-designed. So consumers are used to those kinds of products. Now slap and homemade software product in front of them, and watch them flee! Or a poorly polished plastic drinking cup… or any other product you can imagine. Consumers expect high quality.
This issue is especially true in software, where programmers are sometimes responsible for developing the entire product from code to help files to graphics. Software developers just don’t have the talents for all those jobs, and it’s very obvious when they try. The results are a lot like the Riviera Motel. Can you guess where it’s located?
While camping this past weekend, I noticed a bunch of new broken stuff on our 1990’s pop-up camper. It’s seems everything is broken nowadays, but a new travel trailer is not in the budget, so we’ll make due. But still lots of stuff is broken.
And that got me thinking about engineering…
I told my wife that engineering schools could benefit from a class on “engineering for longevity.” Students could bring in broken consumer items and analyze them for possible improvements. In other words, figure how they might have lasted longer with a little engineering foresight.
Students could identify stress points in plastic parts. They could find wear surfaces on moving parts. They could analyze fabric tears. Just picking up a broken twenty year old part instantly makes you think differently. It’s a very impressionable moment. It makes you wonder what could have been done to make a more reliable part. Perhaps nothing can be done, but at least you are thinking in those terms.
I remarked to my wife that a lot of consumer items are nothing but cheap crap. They have obvious design flaws, bugs, and limitations. You can tell the manufacturer hired an engineering intern to develop the items. Things don’t fit right, or could easily be optimized. There’s just very little “fit and finish” any more. And since engineering interns are young and don’t realize that stuff breaks, they produce shoddy products. It takes somebody with experience to know where the obvious break points are.
My wife pointed out that there’s no money in consumer items to hire experienced people. The engineering apprentice is all the company could afford, so this is what you get. But that goes back to my original point, which is… if engineering schools had a class that familiarized students with the issue of engineering for longevity, some of them might produce better products. Not all students would get it, but some. And that’s worth having a class for.
�
I was talking with a senior software developer last week about the importance of early prototypes to define products. We concluded that it is pointless to begin developing any real architecture or engineering until the prototypes are finished and signed off. You must put your ideas into tangible form before you can trust them to the discipline of engineering. And customers must see examples of the finished product before you can move forward with deep development. Here’s why:
Under-the-hood engineering depends entirely on what you plan to sell. Notice I did not say what the developers thing might be cool or trendy. It’s what you plan to sell. Period. It doesn’t matter if you are selling transmissions or skyscrapers or operating systems; you have to know what the customer wants before you can build the most efficient version of that. Just try to dream it all up alone on a deserted island – without any input – without customers telling you what they will pay for and what they will not. That’s a lot like what you’d get if the developers in their Tommy Bahamas island shirts said, Oh, yeah! That’s so cool. Let’s make that!
Take the automobile transmission for example. If you designed it on a deserted island, and sent the designs straight into production, the risks would be enormous. The finished product would likely have extra gears, “cool” new ideas, and “special” modes that the customer never asked for. And won’t pay for. All those extras make the product less efficient, more costly to manufacture, and more costly to maintain. You probably can’t afford that. Only the most efficient and cost effect designs survive. In other words, only what the customer asked for – nothing more.
Sure, you can get creative and throw in some extras. I call that “programmer candy.” The product doesn’t have to be a total bore. But make sure your core competencies are taken care of first.
Also, it should be understood that prototypes can rarely be morphed into shipping products. (Managers don’t get that.) They are usually throw-away models, so expect to add that extra time to your overall project schedule. For instance, take the old clay automobile models as an extreme example. Remember them from the 1950’s? Even after sanded and painted, they still couldn’t serve as production automobiles. It’s almost humorous to imagine. But still, it has always been a strong desire in engineering circles to go from prototype to shipping product with the stroke of the pen. After all, the prototype looks so real, why not just clean it up and ship it! That’s what the manager usually ask for. Actually, that goal is not far off in computer-aided design, like software development, because editing is so easy. Not so with clay models.
When you watch the old Westerns like ‘3-10 To Yuma’ you are usually treated to a Main Street with old-time businesses and homes on it. Horse drawn wagons lumber by. Victorian dress is on full display. A child taps an iron barrel ring down the dusty street with a stick. There’s the obligatory livery station, bank, gunsmith and hardware store, and cobbler. They all sport a nice tall false front, as the turn of the Century buildings often did. It’s exactly like “real life” in 1880.
But what you don’t see is the backs of those buildings. The Hollywood cameraman never goes back there. Guess what? There’s nothing back there! The buildings are literally just false fronts. You couldn’t actually live in one of those houses or do business in one of those stores. Sure, there are a few sets where you see characters going into and out of those businesses, but those movie sets may be in a completely different sound stage. Nothing is as it seems; it’s all staged for the camera.
Got your attention? Now consider how this happens in engineering…
In engineering, we build prototypes to help people see what a finished product will look like. What people? Customers, potential investors, buyers, company executives, project stakeholders. Everyone needs an idea what a product will look like when the engineering is complete. It gets everyone on the same page, and dispels misunderstandings. Sure, the prototypes have a few warts. It can have reduced functionality, but it must *look* like the finished product, and must allow the sales force to tell the story and make the sale.
The problem with these prototypes is that they have almost none of the proper engineering – much like a Western movie set. Sure, they look good, and may even appear to work. For the purposes of a First Look, they satisfy everyone curiosity and need to see something tangible, and they get everyone thinking in the same vein. But they may not have any of the correct functionality! That fact alone leads to a false sense of completion.
Project managers, engineers, project stakeholders, and everyone alike can be lulled into a false belief that these systems are just a step away from completion. In actuality, they are like false front Western movie sets. You could never consider actually using them for everyday purposes. But after looking at them for an extended period of time, you come to a false belief that you could. You forget how far they are from reality.
It’s that “one step to final product” illusion that gets everyone into trouble — especially the engineers. They are the ones tasked with readying the product for release. Everyone around them believes the product is almost there – almost finished. But it’s not. The stakeholders have big money riding on a swift move from prototype to production. Customer expectations have been set, and they are waiting – sometimes not so patiently. Problem is, there is no swift move. The prototype must be thrown away and the “real” engineering begins. It’s like throwing away the Hollywood false front hardware store and building a real one. You can’t just build onto the false cardboard buildings. They have none of the real factors that go into a real building. Real hardware stores are expensive! And they take a long time to build! They are nothing like the quickie cardboard movie sets.
�
Project quality has many facets depending on the type of project and the quality objectives. A few common metrics used are guidelines and standards. Most people understand the difference between the two. However, guidelines can be confused with standards. Guidelines are just that, an idea or parameter to stay within. Standards are a more exact objective to be met. It is well worth while to make sure people are clear on the differences and expectations of each. Otherwise, a small misunderstanding can be costly. As an example, a sorting team was tasked with looking through thousands of figurines to inspect for defects. The guideline says the figurines can have up to 3 blemishes on the front portion, no larger than 2 cm each as long as they are not on the face. The Standard stated if there is only one blemish allowed in the facial area and they must be less than 1 cm. Well, an entire shift didn’t understand the difference between the guidelines and standards and inadvertently allowed figurines to pass through that had single blemishes on the face up to 2 cm…double the allowed size. This was caught during a random audit and thousands of figurines had to be re-sorted costing the company hours of productivity, not to mention money. As cliché as it may sound, never assume anything. Communication is vital. A simple misunderstanding can cost an entire project.
For our company, great features rarely come from high-octane project brainstorming sessions where the heavens open to reveal the glory of God. Instead, they come from lowly customers here on earth.
Here’s how it happens:
A customer calls up and says, “Why is your product so lame? Why doesn’t it do such-and-such?”
“That’s none of your business!” cries an eavesdropping passerby.
Oops, no. Not the correct response. Instead I ask, “How would you like it to work?”
Nine times out of ten that question turns into a great new feature. We discuss the business case and work out an alteration that fits the common usage much better. Customer is happy; we’re happy. Now we just need to sell it to the executive management and development team.
Why is this exchange so valuable? Because it comes from an actual customer with little vested interest in the product. They just want it to work better so they can get their work done faster.
BINGO!!!
That’s the key. Anytime you can reduce admin time or improve product usage, everyone wins. Nobody likes a hard product. Dreaming up great new features in a boardroom rarely accomplishes those basic goals. Talking to customers is where it comes from.
Problem is, who’s talking to customers? Tech support, sales, and maybe a marketing hopeful willing to mingle with the great unwashed. These are the lowlife employees nobody listens to. So how does the customer need get filtered up the channel to executives and then back down to the development team?
Give them a database. Let them submit feedback from the trenches. If they can articulate the business need clearly and effectively, people will listen. The best features always come from customers.