Tech Manager—Standards: Keys to Collaboration
World Standards Day is celebrated in most countries on October 14 -- so have plenty of time to make plans for your Standards Party. Let’s see… chips, dip, process statement… appetizer, drinks, procedure review… this sounds like so much fun. Gather all your buddies and let’s celebrate.
Standards are key in your efforts to increase collaboration. Whether it is in your office, or between contractors or client. We all need to get along. One way to do that is with standards. But standards need to be understood and not just dictated.
It’s our Policy…
I had a brief conversation with one of my team members who helps support end users. He was trying to get someone to understand why we did something is a certain way. He wanted to just tell the person, “It’s our policy.” I told him to hit pause and discussed it with him prior to his marching off and expecting positive results from his proposed conversation. He was “telling” and not “selling.” He was passing on the “what” but not the “why.”
Never Stop at a Statement
I think you should never make a policy, procedure, or standards statement and then stop talking—especially if the statement is just left hanging in the air like a dark cloud waiting to rain down on the hearer. So, I usually lead with a statement, followed by an explanation. Policies are great and you should have them. Just don’t take a stance, like a menacing parent, making statements like “Because I said so.” It will not be received well.
When confronted with someone who does not want to “color within the lines,” you may need to go deeper. That is when I suggest talking about why you need the common guidelines in place. Standards, just for the sake of making people comply, has never been my focus. I tell people if they can get the project done quicker and more stable without policies or guidelines or standards, then I will throw these out. The people appear to be happy, and then they realize that they need to share work with others.
They need to collaborate. They, along with those they will work with, need to agree on some ground rules and assumptions. When they open someone else’s files to find a jumbled mess of layers, blocks, and who knows what, they soon understand why the standards need to be in place. When working with teams, common ground is crucial—and policies, procedures, and standards lead the way.
Lead with “Why”
Take the time to discuss the “why” of the policy or standard. You should know why things are structured as they are if your guidelines are good ones. The standard should be written down and you may want to keep a record of the reasons “why are we doing this?” as you create the standards. It is not part of the printed standard, but can be used in training and explaining to others the rationale for doing things in a specific manner.
You should be able to defend why you are doing things in a specific way. It might be that you have to comply with a client’s standard. You may have found that doing it another way causes more problems. You may have times when collaborating between disciplines on design means that one group may need to give a little so others do not have to do more work. Your overall goal is to make the entire project team work better and faster, not just one department. If one discipline saves an hour on a file, but another has to work three hours longer because of the file structure, then you have lost two hours. If the first discipline adds 30 minutes to their work and it saves an hour in another, then you have reduced the total work effort. So some might have to work a little more to save others time in the file.
Rethinking the Standard
When people start asking again and again about the why, it may be time to rethink a specific guideline, or even the entire standard. It is good to review your standards when you get a string of frustrated looks from the teams that have to follow the processes in place.
Does the standard still fulfill its purpose? This will most likely not end in throwing out the entire book, but it might mean a review of pain points to see what might be done to streamline the annoyances that seem to provide few benefits.
Is it too cumbersome? Are you trying to force users to do things in a way that was abandoned by the software three releases back? Are there better ways of getting things done now? Can you move the old methods out?
Does it provide benefit to anyone? In my past there have been times when we discovered we were straining to fulfill the standard, but not getting the expected benefits from it. Sure, it may shave off a few minutes for one group, but the others were forced into doing something that did not balance out when comparing time saved to time spent overall.
Is it not needed? Has a client standard been followed even when the client no longer needs it? Check to make sure that you are working with the latest version of client standards and requirements.
Does anyone even follow it? This is a tough one. Sometimes users just do not follow the standard. You are probably not shocked by this because it happens all the time. They did not know, did not care, and did not even think about the standard. But sometimes it is because they know it is not needed and causes frustration with little profit. They have, in practical terms, changed the standard for you. You need to find out where that is happening and either get them back on track, or jettison the outdated and unneeded guideline they have been avoiding. I have done this in the past.
Has someone come up with a better way? This is the best reason for modifying the standard—there is a better way now. You or others have found an improved method to create items or a new better location/layer/level for the entities everyone is using. People may have even started using this new way and the standard has been changed for practical purposes. Time to update the documentation to match.
Keep an eye on the standard for small changes you can make to improve collaboration. Keep it locked in enough to unify production, but fluid enough to make improvements that might be needed. It is the roadmap that we all must develop together so we can keep our eye on the real target, which is productivity through unity by following a standard that allows all of us to collaborate.
