- The one thing that I hope like heck
is happening in your organization
is that you've done your requirements gathering before
you start on your journey to a collaborative workplace.
You'd think this was a no-brainer, wouldn't you?
Unfortunately, I have seen repeated cases
where changes were decided on by a small group of people
without any attempt made to understand
current workflow or pain points.
And guess what?
Typically, these wind up badly.
The people in your organization have
the best idea of the work they do,
and may have some terrific ideas about
how to collaborate better.
Provide the opportunity for them to give input.
Now, in an ideal world,
this should be happening before any decisions
about tools or technologies are made.
Surveys and focus groups are the two most
popular ways to get information from the community at large,
and they are absolutely worth
their weight in gold if done right.
Take the time to draft survey questions well,
so that you're not directing responses artificially.
For focus groups, stick with small groups
of less than 10 people,
and keep the number of questions down.
And let them be open-ended enough
that the participants can have some space to elaborate.
Try to put together enough focus sessions
to get a pulse from all affected areas of your organization.
Talking to a group of admins is gonna get you
an entirely different point of view
than talking to Java engineers.
Now, what happens if you start getting feedback
that indicates a problem?
Or on the flip side, that highlights a missed opportunity?
Well, if you're smart, you share that information
with the decision-makers, and start readjusting the plan.
Like I said earlier, ideally you're doing this before you've
made any final decisions about tools and technologies.
But I know the world's not a perfect place.
What do you do if you've already released your changes?
Well actually, I recommend doing the same thing,
especially the focus groups.
Even after your new program is launched,
you need to be getting input from the people affected.
Now there are two big reasons for this.
Number one, if people are dissatisfied,
you need to know about it so that you can come up
with some kind of remediation.
Dumping a change in people's laps
and walking away just doesn't cut it.
And you need to be honest when talking to the organization.
You need to acknowledge problems and tell people
what you're going to do about them.
Failure to do this will result in decreased morale,
decreased productivity, increased cost,
and a big waste of everyone's time and effort.
Now the second reason for continued engagement
is a lot more positive.
As your employees start using new tools and processes,
I'll bet they'll start seeing places where
they can be used to improve conditions.
You wanna make sure that you have an open line
of communication so that feedback can be shared widely,
along with any success stories.
The more good news you can share about the changes,
the more likely doubters are to start participating.
And the more people in the collaboration rowboat,
the more hands there are on the oars,
and the faster the boat will go.