Do your projects have a clear strategy? Are they linked to the true needs of your organization? And are you prioritizing them accordingly?
You can answer in the affirmative to each of these questions and do so confidently by adopting a technical program management office (TPMO).
To better understand how you can plan and implement a TPMO at your organization, we’ll break down how Teresa Eng, a Sr. Business Technology Analyst at BBAM, convinced her c-suite to adopt one by presenting them with a well-thought out plan!
You can learn more about Eng’s presentation by watching her entire session at this year’s Biz Systems Magic Conference.
Business, System & Technology Alignment
Create a baseline architecture diagram
A great baseline for your technology projects is a formal architecture diagram.
Eng explained that this type of diagram showcases the landscape of your application databases, key processes, and the upstream, downstream, and outbound flow.
During her first few months at BBAM, she focused on creating these types of diagrams first.
This involved spending time talking to business stakeholders and different teams to learn about the different systems, data elements, and processes at BBAM, and then capturing them in her diagram using a metadata template.
She explained that this type of diagram is especially important for when you make changes in the future—like a refresh of your infrastructure, a data center upgrade, or an augmentation of a process.
Additionally, Eng emphasized the importance of continually reviewing the diagram and vetting it when you have new systems or processes coming in so that you can do a proper impact analysis.
Document the systems each line of business uses
Going a step further, you’ll also want to talk to your stakeholders across lines of business (sales, marketing, finance, and so on) and find out what systems they are responsible for and use daily.
You can then create a visual diagram with the names of each of your lines of business on top, the corresponding systems they use below, and lastly, holding those all together below is your TPMO practice.
Eng explains how this is a good exercise to help you understand where they are today, if they need to scale, as well as learn about their goals and what they’re looking to accomplish within their verticals.
Project Planning & Prioritization
Formalize how you get feedback
Before BBAM, Eng had experience with a formal business council that she could meet to discuss progress and prioritization.
Now that she is at BBAM, they use sharepoint for communication and one-on-one monthly meetings with their cross functional team in order to make sure they’re on track.
No matter which approach you choose, make sure to check in with cross functional teams and leadership to make sure you’re prioritizing the right projects.
Find repeatable processes that you can improve
Additionally, when Eng collaborated on a program called Fly Forward with her accounting and finance teams, they wrote down all of their processes and their dependencies (such as if the process requires reviews and external data support).
She explained that this exercise can help you see what processes are constantly being repeated and are good candidates for process improvement.
For example, they came up with labels to help determine what projects could be automated: repeatable/scheduled, repeatable/unscheduled, and non-repeatable/unscheduled.
When mapping out their use cases, they could look at repeatable/scheduled tasks as strong contenders for automation and process improvement.
Coordination and Communication
As you build out your TPMO practice, you’ll want to be transparent with both your stakeholders and your entire business.
That way everyone is on the same page with your technology programs (as you gather requirements, complete different exercises, etc.), they can give feedback, and even see where they can lend a hand.
Content and Knowledge Management
Her last building block is content and knowledge management.
At the overall program level, Eng recommends capturing metadata, your program progress score card, and any storytelling you’ve collected; while at the project level, Eng makes a site where all the information, use cases, etc. live. After the project, they transfer that information to the actual team site. Then, the specific business team can refer to their own site for foundational information and training. That way the team has the documentation they need even after the project has closed.
These insights are just the tip of the iceberg. You can watch her whole session to learn more about building the case for TPMO.
