The Do’s and Don’ts of a Business Analyst Venturing into an OCM Role

Having been a Business Analyst (BA) for many years, I was given the opportunity in 2015 to step into a role that I considered new territory. I accepted a project assignment as an OCM Practitioner/Analyst for a multi-year program, with multiple projects, that was introducing massive changes to the client. There were both enterprise-wide changes and cultural shifts that were required to support the future growth of the company.

For any analysts who are contemplating stepping into OCM territory like I did, here's a list of Do’s and Don’ts to help get you started. These are based on my experience as a newcomer to the OCM practitioner role.

Don't

... claim to be an OCM expert.

Your goal in this new role is to build your credibility. Don’t exaggerate your OCM experience as people will inevitably find out and you will lose credibility with your client. 

Do

... share your OCM related experience on previous engagements.

Introduce yourself as the OCM practitioner assigned to the project. When people ask about your background, share your years of experience as a BA and other roles you’ve done as a consultant.

Share how you participated and contributed to OCM activities and deliverables in other projects and testify to the value of OCM based on your previous project experience. Also share any OCM training you have completed.

Don't

... attend all project meetings.

As much as you may want to, you don’t have to be in every meeting where the assigned BA’s are having workshops with subject-matter-experts.

Remember that you are wearing a different hat. You definitely do need to know the future state changes, but attending all BA meetings is not the best use of your time.

Do

Carefully select the meetings you attend based on the value you can add or receive.

Early on in a project, have a discussion with the project sponsors, managers, and leaders about what meetings you, as an OCM practitioner, need to attend.

• Attend meetings where project updates and changes are discussed.
• Attend meetings where project team members escalate their issues and identify risks.
• Attend meetings where project leaders review project scope and timelines.
• Attend meetings where project team members present future changes to impacted stakeholder groups.

Don't

... focus your attention on finding ways to improve the assigned Business Analyst’s deliverables or technical documentation.

Having been a BA, you’ll likely have the tendency to read and even comment on the assigned BA’s deliverables (e.g. process documents, use cases, data dictionaries). The problem is that by spending time reviewing their deliverables you’ll fall behind on your own OCM responsibilities.

Remind yourself that you are NOT the assigned BA on the project nor the assigned peer reviewer of BA deliverables.   

Do

Read project documentation and focus on what’s changing and who are impacted.

As an OCM practitioner, you consume the BA deliverables for a reason. You are looking for (1) what is changing and (2) who is impacted by the changes.

Ask questions to clarify or understand the change. The BA’s are great allies to the OCM effort as they are the people who work closely with the impacted stakeholder group representatives. Partner with the BA and let them understand how you consume their documentation. 

Don't

... limit yourself to a meeting room.

Having been a BA for a long time, facilitating workshops and meetings has been the norm on how you operate. As an OCM practitioner, our output is different. Understanding the people side of change does not always require a meeting room and a defined meeting agenda.

Do

Explore other ways to operate.

Understanding the “people side of change” means spending time listening to people. In most cases, this means large groups of people. Based on my own experience, a group of people contained in a meeting room is not the best approach to get their honest feedback about change. There are other ways to get this done:

• Invite individuals to go for coffee or a walk.
• Meet them for a few minutes at the start or end of the day.
• Make a quick call and limit your questions.

Seeking feedback like this becomes easier as you build relationships with people. You will adapt and learn how best to communicate with your target audience. As people start to trust you, they will directly come and tell you about what they think and feel, even without an invite.

Don't

... put yourself on the frontline.

As BA’s, we consider ourselves the frontline workers. We author a ton of documentation, make presentations in front of leaders and subject-matter-experts, and answer most of the project questions related to the future state.

The OCM practitioner role is not a “frontline” role. We work behind the scenes, as you’ll see in the “Do” entry below. 

Do

Identify and support the people who can best represent the change.

One of the many responsibilities of an OCM practitioner is to identify and support the people who can best represent and champion the change. These champions of change work hand-in-hand with the OCM practitioner who is working “behind the scenes”. So what does working behind the scenes mean exactly? It means:

• Providing content to leaders as they present and communicate the change to staff.
• Ensuring the subject matter experts are armed with the right information to present and communicate to their respective groups.
• Making recommendations and coaching leaders to help them become effective champions of change.

These are only a few of the Do’s and Don’ts I’ve encountered as a BA who moved into an OCM role. While the roles clearly work hand-in-hand, there are distinct functions of each that you’ll need to adapt to in order to ensure both you and the project are successful.

Have you worked as both a BA and OCM on projects? Do you have any other Do’s and Don’ts to add to the list? Feel free to leave a comment below, I’d love to hear from you!

To learn more about Online’s Business Consulting practice, click here.