Planning Around Scarce Expertise (RPA & OCM)

From the Eye on the Workforce Blog
by
Workforce management is a key part of project success, but project managers often find it difficult to get trustworthy information on what really works. From interpersonal interactions to big workforce issues we'll look the latest research and proven techniques to find the most effective solutions for your projects.

About this Blog

RSS

Recent Posts

Planning Around Scarce Expertise (RPA & OCM)

Beware Haloes & Courtesy Copies

Communicating the Vision (RPA & OCM)

Communicate the Schedule Early (RPA & OCM)

Worth Hiding: Valuable Stakeholder Analysis



This is the third post in a series related to Robotic Process Automation*, begun in association with PMI's Information Systems and Technology Symposium, June 14, 2017, where I presented Becoming an RPA-Ready Project Manager. You can filter posts in this blog to find all related to "Robotic Process Automation". You can also watch that presentation for PDU credit.

Communicating the vision and the schedule were the two organizational change management success factors covered in previous posts. They are very important pieces in the change puzzle. But let's get a little more practical. Successful change management also requires having the right project resources with the necessary skills in time for project start, does it not?

Here are two scenarios that you could encounter in an RPA situation. One is what might be experienced in a group new to RPA projects. The other is what might be experienced in an RPA shop that is a little more mature. Each illustrates the importance of managing project resources to the success of the organizational change as a whole.

In an organization just starting out with RPA, preparing for the first project, few or none of the resources may be familiar with agile methodology or the general process for short RPA projects. The resources are not fully prepared for their roles. Training and preparation activities delay the start of the initial project and likely the end of the project. Leaders, expecting fast financial results as per the business case for RPA, are suddenly questioning the RPA group's ability to execute. Non-supporters in the general organization's workforce suddenly see a reason to become more vocal against the RPA-based organizational changes in general. The new RPA is team is frustrated that they are off to a bad start and will not find it as easy to drive forward in an environment of skepticism as they would have had if they had better managed resources.

Avoid this scenario with more precise planning. You must avoid underestimating how fast you can produce a ready team.

  • Use "left to right" schedule planning for this. Include all activities, especially because you may need to justify a long period before the first project can begin. Think you can produce a full task list? Be sure to add these: expertise gap analysis, create job description for brand new specialist role, recruit needed specialists, interviewing, hiring, wait for background checks, wait for other HR activities you're not sure about but always cause delays, orientation, special new RPA training, team formation. Remember that RPA teams are small. Every unfilled role is a critical problem.
  • Make a conservative estimate as to the time it will take to obtain and prepare the specialized resources you need. Don't even think of scheduling your first project start until all activities are completed.
  • Create a contingency plan for not being able to find the expertise you need. For example, you may have to identify and poach expertise from other organizations. You may have to wait for someone newly trained to get up to speed. Either way, alternatives will take a little extra time and attention than using the standard recruiting group.
  • Consider delaying certain communications about project start if you are not sure of being able to execute on your resource plan. Treat as a high impact risk.

The second scenario is when you are in a more mature RPA shop (as in the Establishing Phase as described in the presentation), you cannot hire new resources with the necessary agile or RPA expertise causing a set of projects to be delayed before they really get going. Organizational leaders, made more hungry by your initial success, desire the same cost-saving benefits coming at a faster rate. They are frustrated by your lack of ability to scale operations.

The point when you start to scale up your RPA operation is significantly different from when you have one or two teams.  (Refer to presentation for details if you like.) The problems with resource management are multiplied.

  • Include in your scaling up plan a tightly-bound recruiting function. Use the corporate recruiting function if you have one. Spend time training these recruiters on what skills you need and why. Describe the needs of your small teams and their short intense agile projects.
  • If you have to use outside recruiters, do the same but also remember to meet often to provide feedback on quality of candidates. You need to get what you ask for. The timing is also important so provide feedback on how fast they are finding experts. Use their info to set expectations on the rate of scaling your team. If you can't fill a role, the whole team has to wait. Your schedule must be set accordingly.
  • Don't suggest to leaders that you can move faster than you can clearly prove through action. We are in a time of high growth for RPA work. That can easily lead to a shortage of talent when you need it. Set expectations accordingly - with everyone involved.

Making sure you have the resources you need when you need them to complete projects is always important for successful organizational change management. With RPA, a new, fast-growing specialty, resource availability presents a significant risk. Don't it be your weakness.

Note:  There will be resources that are not involved in specific project work that will need to be covered by an organizational change plan. These will be covered in other Change Management posts.

 

* Robotic Process Automation:  For our purposes, configuring a software robot, using one of the relatively new tools available, to complete a certain part of a work process formerly completed by FTEs. RPA is not Artificial Intelligence, but simply a way of automating the execution of well-defined business rules. Projects are short and bring quick benefits to the organization.

Posted on: December 29, 2017 02:07 PM | Permalink

Comments (9)

Please login or join to subscribe to this item
An exciting domain to get into. Thanks Joe for the article.

RPA is a domain I am yet to experience. To my knowledge, it is a software bot which is programmed to capture and interpret applications for processes that execute transactions, trigger responses and communication with other digital systems within the domain. And has advantages of cost savings, quality, better control, consistency and is faster.
Thank You Joe for sharing an informative article.

Very informative and thanks for posting.

Thanks for posting

Thank you for the valued information!

Thanks

Thank you for the article, nice insight

Quite informative.
Thank you for posting.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"I never thought much of the courage of a lion-tamer. Inside the cage he is at least safe from people."

- George Bernard Shaw