All Admins Should Be End Users
The following is based on material that I originally wrote for, but removed from, the first edition of “Top Down Design in Creo Parametric.”
As an administrator, it’s too easy to become removed from the pains and struggles of the end user. You can advocate rules, processes, and workflows that are confusing, cumbersome, and impediments to progress.
As a result, your end users might not follow those rules and processes. Ask yourself, are these rules or recommendations? Are these “shoulds” (advised) or “shalls” (required)?
Also, by not being the end user, you risk losing credibility among your end customers. How can you make the rules or tell the internal customers what to do, when you don’t design parts, release drawings, or use the tools you manage? Your internal customers can quickly tell when you don’t have the bona fides to back up what you’re talking about.
Even worse, you can make the end user hate CAD, or at least your CAD system. (I’ve spoken to end users who hate a CAD or PLM system because of the policies and processes imposed upon them, not because of the system’s interface, picks and clicks, or workflows.) Remember, end users are customers. You don’t want your customers hating your product.
I went from end user to instructor to consultant to admin, then back to end user. Going back to being an end user helped me see the policies and rules in a new light. When I was in the Army, I was fond of the saying “Regulations are for the guidance of the commander in accomplishing the mission.” After creating, releasing, and revising project work on a schedule, I have that same feeling about the “rules” around CAD and PLM.
So what do admins have to gain by being end users?
They will gain an understanding how design fits into the larger picture of the product development process, including analysis, manufacturing, and downstream processes such as supply chain and inventory.
They will learn how the tools work best for your products, how you manage data, and how you build, procure, and assemble. Believe it or not, how you use the tool depends on things like geometry complexity, number of components, materials, manufacturing processes, and even the physical size of the end item.
They will gain empathy for the struggles of the end user and the necessities of schedule.
They will be able to test changes and enhancements in real scenarios.
They will feel the pain of the shortcomings of the tools and the processes and policies implemented around them.
Therefore, I propose that all admins be allocated and dedicated to a minimal amount of project work. I recommend at least 10 - 12.5% of their total time. At 10%, that could be one morning or one afternoon per week. At 12.5%, that’s one hour per day. And it needs to be real project work – on a schedule with deadlines, with deliverables that have to be released and managed, and make it into the final product.
Why the picture that accompanies this post? I was discussing this with a co-worker, and he reminded me that you have to “eat your own dog food.” In other words, administrators have to be end users and customers of both the tools they oversee and the policies they implement.
Along these same lines, I have a future blog post that covers the two things more important than Design Intent. Stay tuned…
