The PMO Digital transformation Journey — Glossary and defining the processes
Stage 1
Glossary
Why are we starting talking about Glossary in Stage 1?
The below set of formulas might look familiar to you…
· EAC = AC + (BAC — EV).
· EAC = BAC/CPI.
· EAC = AC + ((BAC — EV) / (CPI x SPI))
· or BAC/(CPI x SPI).
*1 (pmi.org)
Sorry if the formulas reminded you of the certification test :-)
In a digital transformation journey, changes often take place across countries or continents — where common sense becomes not that “common”. Also beware: In the as-is process, the gap may not be visible because there is always a “manual work around” that can magically tie the results. Another possibility is people are using terms and acronyms without seeking for clarity themselves — hence, when you start to “Digitize” it, build the logic in a tool and push it through to other systems, the inconsistency will emerge & expand.
So why are we talking about Glossary in stage 1? The answer is clear: People may think differently when they say the same. The later stage you are in, the higher cost it takes to drive alignment and fix the process. —10 months later, when India team has a 100% pass for UAT, the last situation you want to be in is that Singapore team still keeps submitting defects, you have to trace backwards in thousands of records to find they have a different definition on one calculated field, and call the champions back again to agree which one should be the “Standard”.
Building a Glossary in early stage could help to a great extent to avoid the Tower of Babel effect. Here are a few best practices that may help in your daily work:
- Start building the list early.
- Something like below will only help to a limited extent:
- On the opposite, you may want to prepare before your first workshop an initial template like this:
- Establish Documentation Protocol: Could be on SVN / Git, Confluence, or simply a SharePoint List. Once determined, the link for the Glossary should not be changed — although snapshots can be taken (Another question that usually brings headache is “Which folder? / Which Version?”). It applies to all other deliverables, formal or WIP, in your program. Doesn’t it feel good when you are facing 500 end users and find majority of their inquiries can be fulfilled with this single source of truth?
Discovering As-Is Process
As-is and to-be process is a big topic. The PMO journey does not intend to have lengthy talk on BA or solution architect methodology — Don’t forget, one of the PMO principal is to setup a proper RACI and give the experts the best support to do their job, hence, here I’d just like to share some best practice from past observations — Find the right person, Obtain the document in advance, do your homework before workshop, be curious, ask guiding questions, ask follow up questions, and take meeting minutes.
Think about the conversations below:
Business Analyst: “Upon goods delivery, what will you do to financially close the project?”
Process owner: “We manually obtain client sign off, upload e-docs & transaction details interfacing to e-invoicing systems. Once completed, update Actual amounts in ERP and mark the project as complete. The amounts will be reflected in month-end closing.”
Business Analyst: (Taking notes on the as-is diagram)
v. s. below:
(First set Q&A remain the same.)
Business Analyst: “Thank you. May I please make a few clarifications from here?”
Process Owner: “Certainly.”
Business Analyst: When we say Completed, does it mean the timing for delivery sign off or after the invoice has been sent?”
Process Owner: “Usually after the invoice is sent.”
Business Analyst: “Is this common for all countries? Is this a standard Rule?”
Process Owner: “I’m not quite sure, maybe you can re-validate with other countries.”
Business Analyst: “How many times do you update Actual amount in ERP system, is it possible to take a snapshot, for example, as end of the previous month, or the baseline (When the deal was initially confirmed)?”
Process Owner: “It is possible to trace by versions. Currently we define version by ourselves.”
Business Analyst: “Would it help if we standardize it and determine the rule for a baseline so that it could be compared it v. s. on closure, to measure margin variance?”
Process Owner: “Yes, this is one expectation for the new system.”
Business Analyst: “The duration for month end closing is xxx ~ xxx if I remember correctly.”
Process Owner: “You are right.”
Business Analyst: “What will happen if you close your project during month-end period?”
Process Owner: “This is a good question to ask our Finance partner, actually.”
Business Analyst: “May I confirm if he is the controller, Mr. A, in the team?”
… (Conversation goes on until all key points got clarified.)
Bring in the Champions, designing to-be process
One critical outcome from the above workshop is, of course, the as-is process. But the other outcome, equally important, is the list of your Change Champions.
Change Champions are not necessarily the same group as key users. Key users should be an exhaustive list, you must ensure the list covers every affected process, every BU / region, and these people are truly experts in their domain; Change Champions can act as your shadowed project team member. They have a high motivation to adopt the transformation (As PMO, at this time, you should have also shared, effort wise, approximately when, for how long, and how many hours per week you would need from these key users and Champions). They may be the first small group of people reviewing your Sprint demo and provide feedback, acting as protocol between the team and outside experts, contributing to your Organization Change Management Plan.
Again, a few observations during the design and review process for a to-be process:
Evaluate the level of maturity — Tools are available to evaluate your maturity level from all aspects: Technology, Organization, Corp functions, Domain Functions… etc. In most Digital transformation, the final to-be process, aka the “Proposal”, will be a Roadmap based on the position of your organization. That is also why we say this journey is a good playground to apply Waterfall-Agile methodology: Evaluate the state, build the foundation, consistently adopt, and evolve.
Be very clear on Data flow and Data visibility — The first thing end users will see from your final product, is nothing but the UI, process flow with data. A lot of rework and even delays we saw in the past are due to data from multiple origins not matching. “Who needs to see what” is also important — it is tightly associated with the way you design your user profile.
The “auto-import, auto-fill” feature — There are certain types of features that can save a lot of labor efforts and always welcomed by the users. Such requirements, if not captured in the beginning, may emerge later as a “Scope Creep”. :-) But as a transformation Lead, it will really be helpful to think ahead. After you figure out the above question on Data Flow, Is there any opportunity for automation — to improve efficiency, accuracy, and finally, boom the user .. adoption rate (It’s true!)? If it’s expensive, at least have an answer prepared on “how much does it cost” before your next review with the Sponsor. This applies to some other types of features, such as Analytic (AI) & ad-hoc reports.
See you in the next Chapter.
Stay tuned. TriTech Advisors — Your IT partner for a dynamic world
