Organizing Program Communication

Complexity of Moving Parts

These figures show several views in varying levels of detail, that a Program may include. (My programs are hybrid hardware-software system development efforts. Many projects that spend effort, time and money will see analogies to their own situations.) The complexity shown illustrates why a Program needs good communication on every aspect.

Principles Of Complex Hybrid Programs

Many Moving Parts – And Everything Doesn’t Go Right By Accident.

• PM Is Responsible to See the Future, And To Make That Future Happen.
• Continuous Update: PM Constantly Determines Best-Known Path From Here. Tools!
• Program product technologies drive complexity of process; rather than Program complexity driven by chosen process.

PM gets work done through others in the organization. So Effective Communication Underlies EVERYTHING.

• Appropriately delivered, to All Involved Domains.
• Received, and Mutually Understood.
• Agreed, Accepted, Acted-Upon, Consistent With Involvement.
• Practiced Pervasively.

PM Creates/Collects Directions, Communicates Integrated Direction, Facilitates and Reports Work. PM is Only One with Quantified, Integrated View.

PM Creates, Organizes, Facilitates Communication in All Dimensions

• Cross-Functional, Management-Level, Cross-Profession, Cross-Product, Cross-Project.

PM Organizes and Quantifies Program/Projects for Communication.

• Program-Level Organized Communication.
• Project-Level Organized Communication.
• Negotiating: PM often moderates negotiations among Program stakeholder entities, or Program’s place in the organization.
• Ensure alternative positions are well-presented, avoid bias that may include incomplete exposition, exaggeration, deprecation, biased case comparison (e.g. optimistic case of preferred outcome versus pessimistic straw-man).
• A good decision is based on understanding the Best Outcome and actions that could maximize that outcome and likelihood; and Worst Outcome and actions that could minimize severity and likelihood of that outcome. Such a decision then can rule out cases with an unacceptable outcome, and choose the case with the best outcome with an acceptable worst outcome. A likely outcome will be between those extremes, improved by taking the actions to maximize best outcome and minimize worst outcome.
• Decide based on merit. Thorough evaluation compares optimistic vs. optimistic outcomes among contenders, likely vs. likely, pessimistic vs. pessimistic and includes situational differentiators, risks, and mitigations. From these, choices and trade-offs can be determined among greatest-good and least-harm.
• PM Identifies and Trains Leads/Communicators as Manageable-Entity SME Leaders for Leverage Within The Organization. Load Share Distributed Communication Throughout the Organization.
• PM Advocates Communication Style: Organized Agenda, Notes Distribution, Project Repository.

Formal Program Communication

Business Plan – Product, Market, Customer Value, Revenue / FCS, ProdCost, DevCost: NPV-ROI. Know how to accomplish NPV.

Product Requirements Review – Partner With Product Management, Development, all Stakeholders, And Negotiate Agreement On Practical Delivery of Features and Characteristics, Required or Desired.

For Program Commit.

• Quantified Specifics: Product Technicals, Architecture, Execution Plans, Financial Plan.
• Due Diligence: for Use of Resources, Commitment of $$ Over Time, NPV Adequacy.
• Show Realistic Path For The Program To Succeed.

Program Execution.

• Organization of Program into Projects/Manageable Entities.
• Organizes Project Meeting Structure.
• Day-to-Day Project Interaction, Mitigation, Opportunities.
• Program Quantification, Tracking, Reporting.
• Manage Toward NPV (= Program Commitment).
• Plan, Quantify, Execute Program Change.
• PM Tooling – Quantification, Program Execution Structure – Sprints, Phases, Major Test.
• Know, Guard and Mitigate Changes on Critical Path.

Release Commit.

• Meets Product Requirements and Financials.
• Meets Standards and Compliances.
• Production, Support, Customer Readiness.

Communicate a Vision for the Program

The Program Manager should create, communicate and project a Vision for the Program. It should include exposition of the product to be produced in terms of its structure of Program-Manageable Elements, and of sub-project organization of Elements and program management methodology for each; and especially should convey the quantified path to successful delivery of agreed-upon Program deliverables. You as PM are the Principal responsible for translating the organizational dream into commercial reality.

By analogy: The Program Manager can be seen by Program team members to be like the pilot of an aircraft. You know where you’re going and how to get there, and have created a flight plan satisfying many requirements. You are prepared for diversions and changes. You’re in communication with Air Traffic Control (ATC). You have a ground crew, a gate crew, a cabin crew all executing tasks to perform the flight. You have passengers and management, all of whom must be satisfied. Each person involved understands relevant objectives and details of the flight, sufficiently to determine for themselves what they should be doing at each moment or even when and how to correct or mitigate an issue should one arise.

It helps to state a Vision including visual figures showing relationships among elements of the Vision. This conveys substantial information quickly and intuitively, which helps people to act. Such images should reflect relevant quantifications intuitively, representing size, flow, time; and all relevant factors. The Vision should be continuously updated to reflect current realities, integrating all elements of the Program. Following example images illustrate this from the type from programs I’ve participated in.

I suggest two levels of Vision.

First, a top-level Vision describing the quantified path to completion, broadly integrating all program elements. This would be reviewed with management in formal reviews and at periodic update and demo reviews, and should also be visible and presented to all Program team members. This vision shows a rational and current due-diligence plan to success, and where we are in achieving that. It provides an objective basis for forward-looking plans and decisions that extend well past the short-term. The object of the program is to realize that projected future, while also incorporating studied opportunity, change, correction and mitigation as necessary.

A second Vision, more detailed and at a lower level of abstraction, should focus on what we are doing today and what’s next. That would include plans, tasks, and results for current activity toward next major milestones. I suggest focusing on Integration Points, or equivalent for your program. This second Vision also would be up-to-date, and pieces of it likely are useful in project meetings and decision points. Senior management may be less concerned with this level of detail, but they surely want to know that you have such vision for operational reality.

Objects of these levels of Vision include instilling confidence that we know how to make the Program successful; projecting a framework that helps individuals determine their own course of action; coordination of scope and timing among program elements; communicate and coordinate change; and communication of progress, current state, and upcoming plans. This is the part of leadership that includes people and their work, showing how they are a part of the whole, and shows them where we are going and how we will achieve success.

Program Management Communication With Customers

Of Course, The Product of the Program Is For Customers!

• Know how Customers will perceive its value. Monitor that, and guard it through Program execution.
• Establish active interaction with Customer-facing personnel – Marketing, Sales, Support. They should participate in regular Management meetings for the Program.
• Develop interaction with Customers, internal and external and as appropriate, through deployment of internal prototypes, Alpha/Lead Customers, and Beta Production Trial Customers. Solicit feedback, and stay tuned to providing value to them in the product.
• Keep in mind that the policy of most organizations is that only Sales/Marketing can make commitments to external Customers.
• There is more detail on PM Customer interaction, in Post Advice for Program Managers: 3-Program Management Career Skills.

But Who Are the Customers?

• So, that advice is for working with external customers. But many projects and Programs don’t interact with external customers, at least not directly. Consider projects developing an internal transport mechanism, a processor blade, a media stream transcoder, supply chain yield enhancement. There are many internal Program entities to be managed. Do they have customers?
• Let’s think about the concept of customers in a broader sense. There are customer-supplier relationships throughout most Programs – they are called dependencies and deliverables, and they are often the basis for development sequencing of the whole Program.
• For these, it’s important that the Program Manager work with the team to ensure that these relationships are identified early, and planned-for. Then, throughout the duration of execution of the Program, that awareness and agreement are sustained, updated and executed to maintain flow and timeliness of the Program.

Communication Is Not Just About The Program Manager

Organize the whole Program for Communication.

Formal Program Communications Involve Big Meetings.

• They Involve Business, and Cross-Function Senior Management.

For Execution, Smaller Focused Meetings

• The PM Creates and/or Communicates Direction Into the Program.
• The PM Reports Issues and Status From Throughout the Program to Leadership at All Levels.
• But Communication Happens Throughout the Program, Not Just PM.
• The PM Can Organize the Program for Focus, and Effective Communication.

Project And Communication Hierarchy

For Execution, a Hierarchy of Small Meetings Beats Large Meetings

• Each Meeting Has a Focused Participation and Topic (Clearly Identified Project of One or More Elements).
• Participants More Engaged.
• More Interaction on topic.
• Less E-Mail, Browsing, Chat in the meeting.
• Each Meeting is Useful. Decisions Can Be Made.

Hierarchy Of Meetings

• Entity Development Project Meetings (Weekly, or Agile Cadence)
• Integration Meetings (Weekly)
• BU Management Meeting (Bi-Weekly)
• Senior Demo and All-Hands (Quarterly)

Organize For Communication! A Typical Hierarchy Of Projects

Entity Development Projects – Projects Driving Program Element Design/Test Progress/Issues.

• A Project for each major Program Element or collection of smaller Elements.
• Hardware Elements: Board, Assy; DevLeads, PM, EE, ME, FW, Test, Driver, Supply Chain, Mfg Ops.
• Software Elements: Major Function/Blocks, Management; DevLead, Devs, PM, (ScrumMaster), SQA Dev.
• Typically one Line Organization has primary technical responsibility for each of these projects. Program Management manages cross-functional aspects, and integration into the Program, assisted by Dev Leads.

Integration Projects – These Add An Additional Layer of Cross-Abstraction Across Elements Integrated, Requiring PM Planning and Management.

• SW Integration: SQA Execution, DevOps/Branch Management, Bug Track, CI/CD. PM, SQA Lead or DevOps Leads.
• HW Build/Test (Supply Chain, CM), HW/SW Chassis Integration, System Integration: PM (Leads), Supply, Ops, IT, DevLeads.
• Qual Projects: System-Level Compliance, Environmental, Safety, EMI et al. SME or PM Leads.
• Program Management: Quantification: Schedule, Alloc, ProdStruct, Builds, Supplier/Cost, Supply/Ops/Finance; PM (Leads), DevLeads.
• System Architecture (SME Leads).
• Typically NO single Line Organization has primary technical responsibility for each of these projects. Program Management manages cross-functional aspects, and integration into the Program, assisted by Dev Leads.
• Because Integration and Qual projects are cross-cross-domain efforts, comprehensive management is likely inherently slim. That’s even though cross-domain expertise is required to test and notice any issue, and to diagnose, fix and test it. Issues in these cross-cross-domain projects are often persistent and difficult to remedy. For these efforts Program Management must ensure organized management with active communication crossing all involved domains.

Management – Major progress, Issues, Variances. PM Leads.

• BU-Level Review: DevLeads, Cross-functional BU Management – Approx weekly/bi-weekly.
• Demo to Senior Management, Product Management & Finance with Business Outlook, Program Review approx. quarterly.
• Couple Senior/Demo Meeting With All-Hands. Awareness and Team Togetherness, cross-Org, Food, T-Shirts.

Communicate to Future-You and Other-You: Document APIs/Structure, Dev Plan/Actual, Financial Plan/Actual.

• For Product Maintenance, Feature Add+Later Releases, Next Program, Adjacent/Derivative Programs.
• Immediate and Later Communication to Technical Users.

Organize And Communicate Data Too! (Tools)

The Program Manager collects data on the Program from throughout the organization and creates data that structures the program.

Detailed structural data must be communicated in usable form too, to coordinate multiple efforts. These efforts are often executed in parallel, and often have mutual dependencies and deliverables.

The Program Manager combines and integrates the data, organizes it, and provides Reports specific to organizations and processes advancing the program, to guide their work throughout the organization.

These or other tools can significantly organize and coordinate a Program, and make it possible to keep plans updated and coherent in all dimensions with limited effort.

That makes it possible to always know and communicate detailed aspects of “The Best Known Path From Here”, and to implement Agile, or Agile Mindset, with Quantification particularly for processes involving tangible artifacts and finances.

This process in turn keeps the Program on-track, guides coordination of all organizations and processes keeping the effort lean and efficient, helps to mitigate change impact and coordinate its implementation, to meet the business objectives of the Program.

Take-Aways

Advice for Program Managers: The Blog Series

1-Program Management Opportunity
Introduces a vision and framework for development of Program Managers and PMO, for Program Management specialization to its environment, and for improved effectiveness and integration of PM with organization
operational management.

2-Program Management Career Path
Describes career path thinking for Program Managers including sourcing, progression, advancement, and connection with organizational management.

3-Program Management Career Skills
Career path thinking for Program Managers including skills and behaviors that develop Program Manager capabilities and leadership and pave the way toward advancement.

4-Program Management Specialization: System Programs Phased Methodology
PM Best Practices and Core Program Structure for Hybrid integrated system programs using Phased HW – Agile SW, mixed-technologies. Full-Program agility via automated plan tools with continuous plan update.

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

5-PMO Role
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.

6-Quantified Agile for Hardware
Program Quantification applied to Phased and Agile methodologies to deal with organizational quantitative requirements.

More Articles by this Author

PowerQuery Tool
Logistics Tool using MS Excel Power Query.

Quantitative Management
Tool methodology for agility with continuous plan update: Program BOM, Tie to Dates, Builds, Element data.

Complex Programs: Structure
Structure Program with Parallel Phasing. Describes coordination of EE/ME, FW, Test, Supply/CM, Driver/Kernel, Transport, Management. Scheduling, Integration points, scaffolding, and starting work. Hybrid Program Cross-Domain Coordination of dev frameworks, including Phased and Agile/Scrum where appropriate, via integration points and scaffolding. Software Integration Sequence and Dependency Planning.

Managing Complex Projects
Problem Statement. PM responsibility for Program Management drive throughout an organization, also includes schedule, budget, integration, critical path, logistics.

Link To Free Tools To Manage Schedule, Logistics, And Finance

Author’s softtoyssoftware.com website with articles on Program Management and Program quantification tooling using Excel, MS Project, and MS Visio with SQL databases PowerQuery, SQL Server, and MS Access. Articles describe how you can use tools available from the website, or develop these capabilities yourself using commonly available tools.

Tools available from this website are free. They can handle small to large programs, limited only by your imagination. Using the included Program Template to envision, organize, plan, and run a large program puts me in mind of unleashing a Roman Legion to a sure outcome. Veni, Vidi, Vici! – Julius Caesar.

• https://www.softtoyssoftware.com/dbnet/programmingprojects/powerquerytool.htm
• Details on design of Structured Tables, JOINs, Reports/Pivots in Tools.
• Schedule, Visualization, Reporting.
• Hybrid program agility with continuous plan update.
• Microsoft 365 Desktop – based.