Advice for Program Managers: 5-PMO Role

Summary: PMO behavior to achieve Program Management effectiveness, specialized to its environment, managing PM practices in the organization, including PM development and advancement and connection with organizational management.

This Series, “Advice for Program Managers”: Modern Program Management requires skills and methods specialized to characteristics of its industry; to technologies of its produced products and services; and to management of its organization. In execution, Program Management envisions, creates, organizes, and rationalizes information and leadership across all these domains. The leadership and information created make Program Management an integral part of management of a majority of work flowing through an organization.

BACK to Series Start —Advice for Program Managers: 1-Program Management Opportunity

The Series also solicits contributions to this Blog site, to extend coverage of PM Best Practices and Core Program Structure to a broadening set of industries and technologies.

Program Management Office: Behaviors

A PMO is strategic to Program Management Staffing and Capabilities: This includes acquisition of PM staff, Skills development of PMs, career development of PMs, and day-to-day management and support of PMs. More detail at Advice for Program Managers: 3-Program Management Career Skills and Advice for Program Managers: 2-Program Management Career Path.

A PMO is strategic to creating and executing Organizational Work Culture: This starts with organizing product requirements and technologies, with organizational capabilities and processes, into revenue-producing products and services. Execution includes managing cross-functional interactions and merging and managing across PM methodologies appropriate to technologies. More detail at Advice for Program Managers: 1-Program Management Opportunity and Advice for Program Managers: 4-Program Management Specialization: System Programs Phased Methodology.

Manage PM staff: Acquire, manage, and develop PM staff with PM skills, and continuously develop new soft and hard skills. Assign and manage PMs to programs from proposal to closure.

Cross-Program Oversight of Program Planning and Execution: Management review, peer review, coaching, and alignment whether PMs report to PMO or to other organizations.

Don’t Cause Bureaucracy: Focus on effectiveness of work effort of PMs, and of effect of PM within the organization. Work to actively mitigate bureaucracy in the organization.

Cross-Functional Program Issues for the Organization: Lead periodic review of Programs with Senior Management, Line Management, and Thought Leaders. They’re all going to be interested in the product technology; but PM reviews must prioritize the Program plan and current state of schedule, logistics, finance, resources; and any current or anticipated issues and mitigations.

PMO provides information for decision support, but beyond that, identifies and brings forward decisions that need to be made and wherever possible, describes paths to resolution.

Cross-Program Finance for the Organization: Through the PMO, Programs are principal drivers of information in cross-Program reviews with Finance and senior management. The PMO can drive rollup and review across Programs of all Program Fiscal Year budgets, and all Program Fiscal Quarter Outlooks and Actuals. PMs and PMO are responsible for data availability, Finance may drive rollup and review meetings.

Define PM Career Path: With senior management and HR, define and manage a Program Management career path. More detail at Advice for Program Managers: 2-Program Management Career Path. Characteristics seen to have been successful:

• Manage available Career Path for Program Managers and manage individual PM progression through that.
• Hire for Hard Skills. You want PMs to have knowledge of the thinking and program elements. Hire toward your technology.
• Promote successful first- and second-line managers into PM positions. You want PMs to know how to get work from other people, and through managers responsible. Make PM experience a benefit to success in higher positions.
• Program Managers best report to a Corporate-Level or Business-Unit-Level PMO who can rotate assignment of Program Managers among program types and organizations, to build PM skills and to foster organizational knowledge by and of individual Program Managers.
• Ensure that PMs develop and demonstrate professional behaviors described, leadership, skills, expertise, and successful execution as they progress to programs key to the business of the organization; to the same degree as for Line Managers.
• Through PM Best Practices and Core Program Structure, and rotation, PMs develop rounded-out skills, organizational knowledge, visibility within the organization, and visibility by senior management of PM current work or for career progression.

Executive Contact: Keep Program Management, and PMs as individuals, visible to management. Invite managers and execs as guests to PM staff meetings, from Manufacturing, Supply Chain, Support, Development, CTO, Product Management, Marketing, and Sales. Prepare both the Execs and the PMs with relevant discussion points in advance of these meetings.

Internal PM Conference: Hold an internal annual or semi-annual Program Management conference. Cover PM topics, PM presentations on best practices used or discovered; PM tools and methods; etc. Invite all PMs (Dev, Ops et al.), product management, line management and senior management. (Microsoft does this semi-annually and it’s a great asset). Include guest presentations on technology, business etc.

PM Blog: Create and maintain an internal site for PMs to post practices. Limit to internal PM subjects only. Ability to pin topics and vote up/down is desirable.

Improve PM Methods and Tools.

PM Methods

Capture: PM Best Practices and Core Program Structure. Document them into an archive structure accessible into the future. Publicize via proposed Internal PM Conference described above. These may come from ongoing retrospective activities, and posts in the internal PM blog proposed above.

Capture and archive Program planning and execution documentation including plan/schedule, logistics, and finance; formal program documents; and Retrospectives. These are useful in providing data to subsequent programs on planning, lessons learned, assessment of processes used, etc. Include actual data on allocation and distribution of program artifacts, planned and actual costs, planned and actual time elapsed.

Capture material proposed by others, from conferences and social media, into the same archive, and adapt and incorporate meaningful improvements into organization methodology.

Contribute: PM Best Practices and Core Program Structure cleaned of proprietary information, into the common archive proposed above, to conferences, and to social media. Build a reputation for effective Program Management in your organization and help build PM as a profession, within the organization and publicly.

PM Tools

Work Platforms: Office vs Google Tools, Project vs. Smartsheet, Power Query vs. MS Access vs. SQL Server, Windows vs. Mac vs. multi-platform. Make sure PM tools are powerful enough. Power vs. Security, privacy, interoperability, access.

Tools, licenses, database access and security for data structures used with partners, contractors, CM, JDM.

CMS and Repo integration or coordination plan for multiple/distributed/remote cross-functional teams.

JOINs and other capabilities. MS Office-native vs. development on Google Database, Big Query vs. Azure.

Agile Tools Jira/Basecamp/Asana, many more. Base tool plan on functionality, and integration with other tools in use vs. integration of proprietary function. How do your adjacent organizations share data among tools? Shared data begets automation. Automation can prevent errors and omissions, and enable rapid planning and update, facilitating agility.

MS Project now supports Sprint planning especially for Hybrid Programs, linking your Sprint plans with the rest of the hybrid program plans – MPUG (MS Project User Group) has an informative article about this. You can then link all of that into the rest of your Program planning tools for schedule, logistics, finance – see links below for tools to do this.

Incorporate and Execute PM Methodologies Across the Organization.

Besides PM methodologies, what methodologies and tools are in use across stakeholder organizations, why is each used, and how do they interact? Are operational requirements imposed by interaction with these onto the PM methodology understood by both PM and the adjacent organizations? If a new PM methodology is introduced, what should be its scope on adjacent organizations and their processes? If multiple methodologies are in use or adopted across the organization, how can they be used together? This is the Process Integration question. These, and similar questions must be managed across the whole organization, and the PMO is well positioned to do that.

Agile and Phased: Technologies involved may direct PM methodology: Software and hardware in hybrid programs have different requirements on PM methodology across the organization. When to use Agile methodology, when Phased methodology is required, when program quantification is required, when to manage Agile programs with Quantification, practices to manage across multiple PM methodologies. PM methodology to be used must determine how to interface to other organization methodologies, probably requiring adjustments to PM methodology, adjustments to organization methodologies, or adjustments to both.

Program Quantification: Determine Program Management methodology to use for System programs, i.e., Programs incorporating development of hardware AND software, if those are adopted. Quantification could also be required for interfacing with methodologies of other organizations.

This blog Series includes a post on Phased development of System programs, and a post on adapting Agile methodology to manage Quantification required by hardware and the processes of organizations around it. These programs involve mixed methodologies of hardware and software, and at least because of hardware technology implications on PM, impose necessary quantified boundaries and methods.

Transformations: The PMO is well-positioned to handle PM methodology requirements across the whole organization. It’s often the PMO who are advocating transformation. As a “user” of transformed organizations, here’s what I see as desirable characteristics.

The PMO should be knowledgeable of organizational processes and requirements, interfaces among the organizations and processes direct and adjacent, and should integrate those into the transformed organization such that all continue to function.

Does a methodology to be adopted support needs of functions and processes across the organization to the extent that they can make decisions with accustomed data? Or else, can a new well-defined path be provided? Was care taken to handle dependency management within and across development and operational domains? Specific examples: were operational requirements of material logistics and financial methods handled, including time, schedule, and partner requirements? If a corporate organization supports a multiple-BU company, what must be done so that a single BU can go about changing its methodology or toolset affecting that corporate entity? Alternatively, can Program elements that are managed by methodology intended for adoption be wrapped inside mechanisms that adapt it to requirements of other framework domains?

Start small and focused – Transform one project and get that working. Then let others pick up from that successful instance and make further enhancements. See this and other assessments on Reddit r/projectmanagement.