Listen to Cassandra! The Diversity We Ignore
Modern discussions of diversity focus on demographic diversity when what organizations need for innovation is diversity of ideas. It is easy to assume that racial and ethnic diversity generates the ebb and flow of ideas that allows businesses to improve. But like the office filled with a rainbow hue of Ivy League lawyers that can’t imagine how anyone could disagree with their assumptions because no one in the room had a contrary view, diversity is far more than skin color, race, religion, gender and other outward characteristics.
What are the types of diversity we tend to overlook?
We ignore diversity of opinion, too readily suppressing it instead of welcoming it, even when we say we are looking for good ideas. How does taking this diversity into account improve project management and employee engagement?
He’s Not One of Us
It is all too convenient to dismiss someone’s opinion because they are not from your department, not a member of the team, coming in from another company or don’t share the same educational background. We lose out when we dismiss new ideas from outside the group and outside the organization, and when we fail at true diversity when we assume a rainbow of people in the room counts for diversity while ignoring a variety of perspectives and opinions.
Adding a woman with the same skillsets and who attended the same schools as everyone else in the work group won’t add the same variety of perspective as the programmer who worked his way up from machine language in a group of objective oriented programmers, the manager who started on the shop floor in a room full of MBAs who stepped into management from elite schools, the product designer who started as a product user in a group of artists. When everyone has the same ideas, values and opinion, something is wrong.
John Stossel says innovation occurs when ideas have sex. It is the outside perspective that brings in fresh ideas that, when mixed with your own ideas and current practices, that can lead to innovation and general improvements.
Too many six sigma projects and process improvement projects focus on buy-in as a sales pitch, and they reject the naysayer as a depressing holdout, the negative nelly. However, you should listen to the nay-sayer without simply throwing their opinions out the window. The last thing you want is a disaster because the naysayer was right. Listen to Cassandra, instead of ignoring her. Your risk management plan, at the very least, should take their concerns into account and mitigate them.
Likewise, don’t silence the dissenting opinions and contrary views. The ancient Jewish Sanhedrin courts used to say that if the ruling was unanimous, the verdict was wrong and had to be overturned. Only if at least one person had a dissenting opinion could the group be known to have truly analyzed the situation and fully considered it.
If your group is seemingly in 100% agreement, something is wrong – whether you lack diversity of perspective in the project team or have silenced dissent through fear is to be determined.
Many systems are designed with several classes of users in mind. There are the general users who access reports or process information on a daily basis. There are configuration managers, data managers and other managers who approve document changes, approve time cards and regularly access upper level functions. System administrators and application administrators tend to get the most attention during project requirements and testing, since they are seen as experts in the system and the most important users.
Don’t neglect the group I call the interlopers, the ones who rarely use the system but have priority when they do. This could be the customer representative who only accesses the system when the customer demands to know the status of a project. It may be the low level employee who rarely receives delegated administrative work to sign off change notices but has little margin when they receive the notice to do so. It is the configuration manager who accesses your product data management system every day but only runs product verification reports right before a batch of deliveries.
Plan for these irregular users with high priority when they need to use it; they need to be accounted for from training plans to security rules.
“Back in my day, we used to do it this way.” While new is too often deemed better, the old ways are usually seen as the better way to those used to it – and their input is not to be disregarded in a society that assumes newer is better, but if it doesn’t work, it is because the old timer didn’t buy in.
Review the process flow and interface. Designing new processes and tools to work like the old ones reduces training time. You’ll reduce error rates, the number of changes to your documentation and general resistance because people have to learn something radically new.
Likewise, listen to the voice of experience. This is why we pay those with more industry experience more – to learn from their failures and mistakes so we don’t repeat them. If someone suggests not doing something due to a risk to the manufacturing line or the employees, heed the advice. There’s always room to make brand new mistakes, but at least listening to the old timer reduces the odds of repeating the old ones.
More by this Author
What are some of the major issues crowd-sourcing and its supporting platforms create for intellectual property?
What is change management in relation to the engineering and design process? How do you literally manage changes, such as document change requests?
How do you calculate safety margins? How do you calculate the safety factor or factor of safety? What is the difference between a safety margin and a safety factor, and how are they related?
No comments yet.