There’s a lot of market discussion now about business agility. My colleague Craig Le Clair just published a key report on the topic today. He also blogs about it. Craig defines agility as: Business agility is the awareness and execution quality that allows an enterprise to embrace market and operational changes as a matter of routine.
Think about that definition for a while and it quickly becomes clear that contingent labor is key to agility. What’s contingent labor? In Forrester’s view, any worker that isn’t a long-term part of your workforce — permanent employees or long-term outsourcing contracts — is considered contingent. For example, independent contractors, resources engaged in a six-month application development project from Cognizant or IBM, or people hired through an MSP or staffing agency are considered contingent. Even within a large offshore master service agreement, the individual workers are brought on and off the client’s engagement with some frequency. We’d consider those workers contingent also.
And why are contingent workers so critical to agility? Because your existing permanent staff will not suddenly develop new skills overnight. Nor will your long-term outsourcer suddenly change the resources assigned to your account without a (sometimes) extensive renegotiation of your contract. For example, if you decided to build a Portuguese-language mobile app for a new Brazilian customer segment, it’s likely to take you months to move someone internally off an existing project, hire a new staff member, or call your outsourcer and change directions on your current maintenance contract.
However, relying on contingent workers is not a panacea for agility. In fact, the rise of a contingent workforce poses a significant danger to agility efforts: it hinders a firm’s ability to disseminate knowledge quickly and effectively across the organization. In Craig’s report, he outlines market dimensions, organizational dimensions, and process dimensions. Knowledge dissemination is one of the organizational dimensions of agility. Relying on contingent workers currently slows down knowledge dissemination in all three phases of work:
· Onboarding. Most companies have weak onboarding processes that don’t provide proper domain and contextual knowledge transfer to the contingent workers. So it takes the workers longer than necessary to become productive.
· On assignment. Again, most firms spend little time making sure that the knowledge gained by contingent workers is shared with permanent employees or documented in any systems. Institutional knowledge no longer exists, as any lessons learned walk out the door when the worker leaves.
· Offboarding. When a contingent worker leaves, there are few good approaches to ensuring a formal knowledge transfer back to the company. The next contingent worker to come on board starts at the same point as the last one, rather than being able to build on the prior person’s experience.
But what if you found a way to increase the speed of their content onboarding and also gained more expertise for your internal team before they left? That’s where a better knowledge transfer approach comes in to play. Start by asking yourself, what information does a contractor need to get up to speed? Beyond the traditional orientation we might provide, firms that rely on contingent workers should think about what knowledge needs to be disseminated at each of the three phases:
· Knowledge transfer to the new worker. What information do we need to provide the new contingent worker to help that person be productive as quickly as possible? What domain expertise is available for us to share, and what contextual knowledge is there (about our project, company, or market) to help the worker integrate into the team faster?
· Knowledge sharing during the engagement. What kind of information should we share during the project? Who will be responsible for sharing that information? Do we have a clear process and expectation of what we want the worker to document while on this engagement? What do we need to learn from this person while he’s here?
· Knowledge transfer back to the company. What do we need to know before he leaves? Can we access all of that information after the person leaves? Which person on the permanent team is responsible for receiving that knowledge transfer? Have we interviewed the worker to gain any contextual lessons learned that we can use to help our next worker become productive more quickly?
There aren’t simple answers right now, but as agility and contingent workers become bigger corporate priorities, you need to spend time thinking about how to make knowledge transfer a more systematic and two-way process in your workforce management.