- Before you dive headfirst into collaboration,
I believe there is some homework that needs to be done.
As with any project, changing the way things are done
has the potential for causing disruption.
Now, some companies brag about disruption,
and I'm not saying that it's a bad thing
to introduce change.
But disrupting things without having
a pretty clear idea of how it will
disrupt the lives of the employees
and making plans to help them transition,
well, it's pretty stupid.
So before you go off making decisions
on which direction to take collaborative tools
or redesign workspaces, or any of the other elements
that go into the modern workplace,
I believe it is absolutely crucial
to understand your current landscape.
What is the work the various teams
in your organization are doing?
How do they do that work now?
Are there processes which are overly complicated
which can be streamlined?
Are there clunky systems that create log jams?
What are the pain points that workers experience now?
Where are the gaps in information processes and tools?
What I'm talking about is basic
business requirements gathering,
but you'd be surprised how often this doesn't happen.
Unfortunately, a lot of decisions
around converting the modern workplace
are made because it'll be cool,
or because other companies are doing it,
or because someone in a position to make changes
is personally excited about it.
Now, none of these make change invalid,
but they're also not good enough reasons.
You have to do the hard work of knowing
how change will affect your business
before you start doing things willy-nilly.
Once you understand what the requirements are,
you can start evaluating the different solutions.
And, once again, although this might seem obvious,
if you've made a decision
to go with a certain tool or process already
and you're going through the requirements gathering process
just to tick the box,
you're doing a massive disservice to your company.
Not only are you wasting everyone's time,
but you're setting the stage for failure,
or at least a slow and painful transition.
Now, I'm a big advocate for transition management
being a part of any introduction of tools,
processes, or environments that affect end users.
Transition management is the people aspect
of change management.
It's focused on helping people
understand the change ahead of time,
understanding what's in it for them,
and helping them to move faster
through the inevitable dip in productivity
that comes with any change.
And I include changing physical environment
in requirements gathering too.
Example, say your company wants to move everyone
into a flex environment with no assigned seating.
What will people need to make this work?
Does everyone now need a laptop?
And if yes, how many do you need to buy?
And what about phones?
And what are your tester and coder contingent?
You know, those guys with three computers on their desk
and four monitors because they're running multiple scripts
and monitoring multiple systems?
Is it even possible to move them?
Or are you going to need to make an exception for them?
Who else will you then need exceptions for?
Given the different job duties
and the workspace needs of different teams,
does it even make sense to proclaim a universal change?
Bottom line, if you don't take the time
to thoroughly understand your requirements before you start,
your transition will be messy, painful,
and have a much greater likelihood of failure.
And every bad transition makes the next one worse,
since your user base will not forget,
and will resist a little harder next time.