Eye on the Workforce

This is the fourth post in a series related to Robotic Process Automation* (RPA) and Organizational Change Management. The purpose of the series is to provide support for project managers during this age of digitalization. You can filter posts in this blog to find all related to "RPA".

Do you feel it? We are in the age of digitalization. Manual processes are being automated at an ever faster rate. So you, as a project manager, should be ready to manage automation projects. To be ready, you need to know something about how the technologies work and something about how the organization adapts to the changes brought about by the automation.

One of the technologies used to automate work is robotic process automation, a relatively simple technology that allows automation of repetitive, rule-based, easily defined manual steps in a matter of days. A developer programs a software robot to follow the steps a human would make to move files, fill out online forms, write standard reports from existing data in multiple applications, and more.

Organizational leaders tend to see repetitive, simple tasks as low value and so do workers who do those tasks. Everyone would rather be doing direct customer service or other tasks that are high-value for the organization, saving money, increasing revenue or building customer delight. Yet a project manager coming in with the ability to make fast changes in multiple areas still may not be successful - without a broad knowledge of organizational change management.

One of the success criteria for effective organizational change management is that workers and their leaders are provided the new skills that are necessary once the automation is established. This usually entails

• What steps are being replaced and will not have to be completed
• How to manage the workload that remains
• How to identify and handle exceptional cases that the automation cannot complete
• How to find and interpret periodic reports that the automation creates  to summarize
• How to identify and report when the automation is not functioning or not functioning properly
• How to maintain the automation and request updates/improvements.

When workers do not have the necessary skills, when they conclude that they are not going to be trained or prepared properly, they resist the organizational change. Leaders are the same way. If they do not see that they will be able to manage properly once the automations are in place, they will resist. Resistance to organizational change is one way otherwise impressive improvement efforts fail. Even though there is a strong business case, even though the organization would advance in the marketplace, organizational change will fail if there is resistance on the part of workers, stakeholders or even leaders of the workers.

Here are examples of how resistance can kill an organizational change management effort:

• Workers make it difficult to transition to having the automation take over
• Stakeholders, not confident that the change can be executed properly, resist actual implementation of the automation
• Workers complain to leaders that the automation does not appear ready or the organization does not appear ready to make the change delaying implementation of the automation

Example:  Automated Archivist

Take for example the situation where you are a project manager for an RPA project that is automating a manual process for archiving files for the enterprise that will be used for financial recordkeeping. The process entails moving files from certain shared spaces to a secure archive, allowing for data collection and analysis. The team that does this currently does not like the low value work and would rather spend time on data collection which is highly valuable in their "big data" initiative. The business case also listed reduced risk from human error in the archiving process.

But you do not manage the skills gap properly and then your project bogs down.

• You find out that workers tell their supervisor that they are not sure this can work. The automation appears to "take over" and not let them do their data collection as usual.
• Managers raise issues and require additional meetings to address how they will know that the files are archived properly, which they are responsible for.
• Finance stakeholders want a separate meeting to address their fears that financial records could be mismanaged and no one would know about it. You find out that this fear has been communicated to high levels.

That could get ugly. To avoid this resistance, you have to plan in the beginning to address the skills gap. You must put in place the communications and meetings necessary for workers, leaders and stakeholders. You must make time in the schedule for the training or other activities for the organization to adapt to the change.

So for your stakeholder management plan, add in the groups involved, including the workers, their immediate supervisors, other leaders and stakeholders. Specify what communications are expected. You should have early communications to describe the general scope of the effort, but go further. Include deliverables, such as a "user guide" for the workers and supervisors and stakeholders who will be looking at reports generated by the automation.

And for your schedule, block out time for "organizational change activities" that should be completed before you put the automation into production. That way it will be easier to organize everyone involved to be ready on time.

That wasn't so hard. Once you know more about Organization Change Management, the more you can use your existing tools in a way that will make your automation project successful. Remember, there is more on OCM and RPA in this blog. Filter on RPA. And happy automating!

* Robotic Process Automation:  Configuring a software robot, using one of the relatively new tools available, to complete a certain part of a work process formerly completed by humans. 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.

This is the fourth 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 "RPA". You can also watch that presentation for PDU credit.

Without the right prepared resources during organizational change, frustration will be the order of the day. Deadlines will cause conflict. The much-touted vision will ring hollow. Success will be difficult.

In an initiative where organizational change is brought about by automation, including rolling RPA projects, resources have to be available at certain times to complete specific work. If they are not available, then the frustration spiral takes over. Examples below from such a hypothetical organizational change show how to identify and deal with resource problems and how to avoid errors managing resources over which you have control.

Organizational Change Effort Role: RPA Project Team Business Process Specialists

Potential Problem: You lead an RPA project that will be completed within a couple of months and representatives from the business that know the process to be automated are not available or not assigned near the point at which you are to start. This could be due to:

• Group’s lack of knowledge of the commitment required in such a project. The work is rapid and agile-like if not agile, and the significant time involved for many days is not familiar to some.
• Group does not have firm acceptance of the vision of the organizational change.

…or other reasons

What You Can Do as Project Manager:  No matter what the reason that caused the problem,

• Ask advice on how to proceed from your peers in the organizational change effort. Nuance is critical for your success.
• Attempt to contact the individual in charge of assignments to understand what the situation is and resolve it quickly.
• Log a risk or issue if you don't have name(s) on time.
• Talk directly to assigned specialists and explain what specific time commitments are required. Identify any lack of availability during project.
• Communicate to stakeholders any availability problems. Again, log a risk or issue to manage this formally. In a short project, any small delay hurts.

Organizational Change Effort Role: Change Specialists

Potential Problem:  Your project is dependent on a separate effort to communicate about the change in advance and to get general agreement with the vision but evidence you see does not indicate that the communication has occurred, or the vision has been accepted. This could be caused by:

• Too few change specialists
• Badly managed change communications
• Change specialist (or change manager) role given to some who did not have time or ability to do it correctly

…among other reasons.

The result is that certain project team members, partners, stakeholders are not hurrying to work with you. They do not know what your project is. Or they are avoiding your project.

What You Can Do as Project Manager:  No matter what the reason that caused the bad communications, you must act when the environment is not conducive to success. In any organizational change effort,

• Attempt to contact change specialists who can remediate the problems with communication/training. Be positive, but don't hold your breath waiting.
• Raise a risk if there is a pattern of non-participation or obstacles related to lack of communication. Be specific about who has not committed as expected by a certain date and what the consequences are to the project. Do not exaggerate. Clarity on your part minimizes ugly drama that can be involved in resolution.
• Look for change-related communications sent (or that should have been sent) by change specialists, explaining what the organization is doing for automation and the benefits being sought. They may also include success stories from elsewhere in the organization. Integrate key principles and points in your communications for your specific project for continuity of message.

There are many other roles in an RPA project, but the example of business process specialists is good to address because success of the project is mostly dependent on their availability.  Likewise, there are many roles in a large organizational change effort, even one that is solely built around continuous automations. Change specialists are key to setting up a positive environment for you to manage your project. Unfortunately, you as a project manager have less authority to manage problems associated with roles outside the scope of your project. Still, your usual tactics of (a) direct communications with constructive problem-solving and (b) risk management are useful there as well. Using those tactics will make you a positive force against frustration in organizational change.

(If you are thinking that Resources needs certain skills for automation projects and organizational change then you are correct, but we will deal with the issue of skills in a future post.)

* Robotic Process Automation:  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.

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.

This is the second 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".

Another component of organizational change management that you will need to monitor as a project manager is that the vision for the change has been communicated. Generally, you do not have to personally manage vision communication. It is the job of senior leaders to define and sometimes a special group helps to formalize the actual message into emails and intranet web pages. Still. it is wise for you to make sure it is going to be done properly or the tasks you are accountable for will not likely be successful as planned. You just have to love those out-of-project dependencies!

How do you know the vision of organizational change? It is a clear description of the target future state of the organization and the benefits that will be expected. Don't settle for anything less. For organization-wide RPA efforts, where the vision includes software robots doing some of the work previously done by most human resources, the description must include a more satisfactory workplace where workers complete less tedious, more valuable work.

If the vision is not communicated to everyone, your project gets run off the rails by

• Conflicting interpretations of what the end point is leading to
• Differing senses of impact by individuals or groups, differing senses of urgency
• Ability of groups or individuals to promote their own agenda or pressure for certain changes
• Changes occur, but not exactly what is needed to meet the vision. Interpretations change over time, or other factors.

Don't wait for these symptoms to occur, unless you are a masochist. Treat proper organizational communication as an Assumption, Dependency or something else formal and reportable. My paramour Amelia was wisecracking at lunch the other day that if you publicize a dependency for vision communication, then you might spur "someone" into action to do it!

What about the rollout of that vision? You will know effective, broad communication of the RPA effort vision is occurring when great practices for organization-wide communications are implemented. That includes:

• Multiple channels used, such as email, dedicated intranet area, town hall sessions
• Initial communications and ongoing updates
• Executive participation
• Q&A sessions with leaders

Make a note to look for these great practices to monitor your Assumption or Dependency. Don't see them? Consider managing as a Risk.

The communication should be continual and take many perspectives, such as

• The importance of the organization's ability to succeed or avoid failure in marketplace, improve customer satisfaction. This addresses concerns of those who always ask the question "Why are we doing this in the first place? Everything was fine before."
• The new structure to support better employee satisfaction
• The new more productive and profitable business processes

Per member Philippe Schuler responding to the first OCM post, success stories are also important in organizational change management communications. In RPA projects, workers (users) will be expected to be skeptical of the changes, but evidence that it has worked well previously will help calm fears. Especially useful stories for RPA will include any that show the workers who have robots working for them are more productive and happy with their now more valuable work - and thus making the vision manifest.

If you start to see a lot of push-back to your RPA projects, it may not be your teams' fault, it could be inadequate organizational readiness for your projects. Consider escalating with that as a potential cause. The solution to that problem should be different than having you just push harder yet again. It could be resolved as a management problem beyond your role. 

* 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.

This is the first 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 will be able to filter posts in this blog to find all related to "Robotic Process Automation".

It's a couple of days after my presentation at the Symposium with an energetic crowd of attendees from all over the world. The chat stream was at times very funny. In addition to being a potential career path for us project managers, Robotic Process Automation lends itself to really humorous comments and interpretations. That will make it fun to talk about. Maybe we can all discuss it with my new girlfriend Amelia.

Let's get started.

As I said in my presentation, the first RPA-specific posts will be about Organizational Change Management (OCM). Organizational Change Management is a critical component of projects that require new work processes for people, on the business side or the technology side. RPA efforts are a perfect example. Unfortunately, the details of how this component integrates with project management is not always clear. It is worse when the organization in which you work does not have a mature OCM process to follow or a specific team that handles the OCM functions.

Picture it:  Your new work process project is chugging along. The technology is near to being deployed. Quality of the new technology looks very good. The budget did not go over too much, thank goodness. You are planning to transition the final resources out of the project. You will be able to take a few days off finally.

But wait! Alarms are going off! In emails at least. Not everyone is ready. One of the unready groups is the Help Desk team. They have not finished their training and other preparations. You also hear there is a similar situation with the users on the business side.

Fast forward to the lessons learned session. It's a bit awkward when the training issue comes up. The actual lesson earned cannot be immediately agreed to by the attendees. You have to wonder, "What happened?"

It could have been any number of factors, all within the OCM component. In this special series of posts, I will go over as many of these factors as I can, all in context of Robotic Process Automation (RPA) projects. These projects present good examples albeit with the increased need for urgency that RPA demands.
Adds to the drama.
And you love the drama.

Now back to OCM: One success factor for organizational change is that there is a general schedule communicated to all those affected by the change generated by your project. Not just the stakeholders. Not just the supervisors. The communication must be to all who are affected. They just need a summary of what will happen and when. They don't need your entire detailed work plan. This part of OCM has many benefits, including

• Making the change appear more "real"
• Building trust by showing that planning by multiple teams has gone into the effort
• Providing everyone a consistent go live date
• Building a sense of urgency around actions leading to the go live date
• Showing specifically what leadership has agreed to
• Helping the planning effort of other teams that may not be closely controlled or monitored by you

For RPA projects, specific target dates may be given for the following activities

• Process re-design around use of the software robot
• New definitions of roles (typically occurs if multiple roles can be consolidated once the software robot is in place)
• User training (targeted to those who previously did the work previous to having the software robot as a support)
• Support staff and supervisor training (help desk, supervisors of users, control partners)
• Go live date

"Target dates" are fine, especially since it is best to communicate the high-level schedule as soon as possible. Later schedule revisions can be communicated in a timely fashion.

Communicating the general schedule of the steps leading to a work process and workforce change is just one part of managing that change. All together they will keep all teams associated with the project aligned, on time and with les resistance. Future posts in the series will cover other components of OCM and their relationship to RPA projects.

* Robotic Process Automation:  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.