SVPM_rmbExpertise.jpg

Three Levels of Program Management

My work is on system development programs, which include a mix of hardware and software development, and associated process developments, across many organizations. I’m describing here Program Management methods used to develop these systems, with particular attention to disparate management methodologies used and integrated within those Programs. These systems are developed in a “Revenue on Product Delivery” business model typical of efforts that include hardware development. Many projects that spend effort, time and money will see analogies to their own situations.

I work at three levels that organize practice of Program Management: “Program Execution”; “Program Structure” and “PM Tools”.

Program Execution depends on Program Structure, and Program Structure depends on PM Tools.



Program Execution

Active and visible Program Management toward intended deliverables.

  • Lead the Program: through Definition of the Program, and execution of its Development and Delivery processes. Organize the Program for communication, and continuously manage its execution progress, crises, and change, through the Program leadership structure created for that purpose.
  • Overwatch: Know the program top-to-bottom, front-to-back, left-to-right, all radii, all angles. Ride shotgun. PM activity includes structuring, tracking, reporting, updating, recovering, adding, and changing.
  • Keep stakeholders continuously connected to the Program plan, its status, issues, and successes via face-to-face group updates (Zoom and Teams count too). Develop your alliances with the execution team. Stay active with Stakeholders and Core Team members for management leverage.
  • Know and actively manage the Critical Path through the Program plan. Intervene to keep the Critical Path on track as well as the Program as a whole. Provision it, foresee and remove roadblocks, prioritize Critical Path vs non-critical-paths. Watch near-critical-path tasks as well lest they become critical-path.
  • Make it your business to complete the program to its business objectives. Remember, it’s the Program Manager who’s making Program commitments to the organization.

All program managers do these things. But in managing them, your ability, credibility, and success will be greatly enhanced by the Program Structure competencies outlined in the following paragraphs. Better direction and decisions are made with quantified understanding of the Program.


Program Structure

Quantification is the crucial step translating Vision into Execution.

Develop a Program plan. Such a plan no doubt varies depending on particular technology, business model, and particular characteristics of program elements. For example, the plan could be based on GANTT-and-spreadsheet or could based on a PI (Program Increment) plan. The plan should apply appropriate methodology to each technology managed, keeping those methodologies synchronized.

The Plan is especially valuable when developing multiple elements simultaneously, especially if those element technologies require differing methodologies, different organizations, or remote sites, and if tasks must be synchronized and integrated to make a coherent offering. The more complex the Program, the more a useful a Program plan.

So here’s how such a plan can work for a complex hardware-software system development effort.


  • Envision the Program

    • Envision Program structure that includes product elements and integrations, process sequences, across organizations, through major tasks, and over time. Create a quantified representation of that.
    • Nobody else is going to figure out the whole program structure quantitatively, how the development pieces interleave, how the product elements, organizations and organizational processes should be sequenced and integrated to develop the target product. This leads to unparalleled knowledge of the program, and is major value the Program Manager adds to the organization.
    • We always remember to plan the visible development elements – boards, mechanicals, driver, transports, managers… but planning cross-organizational tasks, particularly integrations and system-level test, may be weak. Where everyone is responsible, no one is responsible.
    • Integration and Qual usually require multiple layers of synchronized effort – Supply Chain, EE and ME elements, assemblies, systems, software release, platform integration, Qual test, certification. Planning and executing the complexity of the entire sequencing of these efforts often falls to Program Management.
    • You’ll be able to see from the Post on “Complex Systems: Structure” how planned Program Structure knits together the many elements of a System program.

  • Program Plan

    • Create and continuously update a program Plan – major tasks with duration estimates, and dependency sequences, and resulting in dates. A PI (Program Increment) Plan counts here too; with dependencies, sequencing, and dates.
    • A Plan isn’t intended to be fixed, immovable, omniscient, inflexible or any of those things. The Plan is quantitative due diligence describing work to achieve Program objectives. The plan is used to guide and coordinate work and changes toward intended Program outcomes. The Plan incorporates dependencies and deliverables, long-latency and long-duration tasks, and resources.
    • If your plan is inflexible, you’re doing it wrong. The Plan should be updated continually (or for each Sprint) to reflect current reality with adds, updates, and changes. Long-latency tasks, coordinated development sequences, and spending all need planning. But that doesn’t mean you can’t change the plan. And when change is needed, an updated plan communicates and coordinates the change.
    • The trick is to make the plan update-able quickly and without massive effort – and that’s where tools come in – it shouldn’t be a manual effort. Design your plan such that you can use computers to plan, update and change quickly and with limited effort! There’s a section below on tools for fluid planning.
    • There’s great value to making decisions based on today’s known reality – and a Program plan is all about defining and making those decisions in the sea of otherwise unknowns, and with assessment of consequences.
    • At least identify and sequence major capability developments, integrations points, and logistics. No need to over-plan, but handle all integration points and major dependency sequences.
    • Identify the program Critical Path in technical terms (zero slack to specified endpoints). Focus on Integration Points, incorporating dependencies and deliverables along those paths.
    • Working-path-first: keep the organization working, take problems and mysteries off the critical path and re-integrate their solutions when they’re ready.
    • Iterate to improve the plan; don’t just accept the first try. You probably have to iterate a bit to fit within business requirements for dates and spend anyway.

  • Logistics

    • Determine prototypes, equipment, services, licenses, contractors; in fact all tangible assets for each organization, over duration of the Program. Estimate costs, suppliers, availability, and acquisition variables including lead-time and pay-date. Replace estimates by real quotes with help from Supply Chain et al.
    • Prioritize provisioning of Critical Path tasks.
    • Once the Program Plan for sequencing, above, is done, the major ongoing work on Program Structure is to keep the Logistics plan up-to-date, as material needs and supply unfold.

  • Finance

    • Program Logistics plus Program Schedule are the basis for Finance. Staffing is too but that’s usually more constrained, less volatile over the course of a Program.
    • Schedule drives Logistics, and Logistics drives Finance“. Tie Logistics elements to Program Plan events associated with allocation and use, and consequently to dates for that. I’ve built a lot of hardware in my programs, and 80% of it has been for software development tasks. Association and aggregation of Allocation and Use, Dates, and Quantity and Cost of materials is then mined to create financial reporting. The links below for tools show a nice way to use JOIN operations for association; or you could design your own method perhaps using lookups.
    • Program financials are needed at Program Commit, at Fiscal Year budgeting, at each Fiscal Quarter in the duration of the Program, and at Program Release. They are also used to drive Supply Chain processes. At Program Commit, complex programs typically must meet financial criteria in order to proceed. Changes to business conditions, mergers and acquisitions also need this level of information about the program.
    • For system products, Finance is a big factor driving need to identify equipment need-dates for spending, whether prototyped or acquired. Finance is usually a major factor in driving operational behavior quarter-to-quarter throughout the organization.

  • Program Deliverables for Product With Business Lifetime

    • Many Programs introduce a Product or Service that has a “Business Life” of its own.
    • Deliverables for those Programs include Product instantiation, but also include creation of the “Essence” of the Product – the ability to produce and use the product over time.
    • So primary Program deliverables include development of product instances as needed, PLUS simultaneous bringup, execution and ultimately documentation as appropriate, of capabilities to define, develop and document the product itself and also documented abilities to produce and use it.
      • These capabilities cover Business plan – product design – supply/production – distribution – deployment – support – use – maintenance – update/enhancement.
      • Via training – documentation – design artifacts (source, Verilog, specs, test et al.) – processes/procedures – contracts – internal/external contacts – staffing/allocation.
      • In practical terms, program elements where Agile methodology is applicable can use and re-use existing capabilities for these lifetime tasks. Program elements producing hardware on the other hand almost certainly must implement new capabilities specific to that hardware.
      • Instantiations of the product are built for use, and also represent of existence and then-existing state of the capabilities defined by documentation of its Essence.
    • These deliverables may vary in detail, depending on the technology of the product. For example, production and support are complex for electronic hardware or Construction, and even more so for chips. Code structure, coding, framework and library familiarity are complex for software. Customer-facing product testing and use are complex for cloud-based products.
    • All developed capabilities and deliverables continue to evolve over the full Business-Life of the product, from conception to retirement – thus requiring maintenance. Sustaining may transfer offshore; Re-organizations or corporate mergers may redirect any capabilities to different organizations; key people with expertise may make career moves. Usually enhancement and retirement are managed as subsequent and separate projects.
    • Program product requirements and customer dialog should cover all these aspects, without being limited to product features.

Actively use these Program structural tools to get the whole team working on tangible deliverables, synchronized, in a common direction, even through change.

The usefulness of the Program plan is tied to ability to keep it up-to-date efficiently and able to determine the “best known path from here”, with minimized effort. Following, are desirable characteristics of PM Tools to quantify and manage the Program Structure.


PM Tools

  • Represent the program in detail necessary and sufficient to represent and quantify the program plan Schedule and Logistics, and to mine the representation for tracking and reporting. More program elements makes this harder – the number of possible combinations of “stuff”, and ways to look at it, goes up factorially. The more complicated the Program, the more necessary the tools and representation.
  • Several other posts (Phased Methodology, Quantified Agile for Hardware) outline factors needing Program Management particularly in system programs involving hardware and software. Other program types may also have their complexities. Generally, Program complexity is driven by its Product technologies, organization operational processes handling them, and Program size. These factors and their combinatorial effects may seem overwhelming, even frightening! For that, there are at least these approaches:
    • Layering. Start by developing a basic task GANTT or PI plan for your Program, then layer on one factor after another. The combinatorial methods mentioned in Quantitative Management describe connecting the factors, and developing reports from the resulting combination of data. More detail and support are provided on my website at www.softtoyssoftware.com.
    • The tools available at PowerOpI Tools were developed specifically to combine the factors described, and to turn the combined data into information customize-able to operational specifics of participating organizations. The Tools represent Program data in Tables and provide functional use of that data. The Tools are based on common platforms: MS Project, Excel, Visio, and PowerQuery, MS Access, or MS SQL Server.
    • Tables in the tools can be made to describe factors describing your programs. These tools could be used directly for your Program by incorporating data specific to it into existing Tables, or by adding new Tables and JOINs. Alternatively, the tools provided could provide insight to development of your own similar tools. And of course, commercial tools are available depending on technologies.
    • It is these complexities that make PM tools important. Good PM tools, commercial or custom, support coordination, good decisions, good direction and support Agility in the face of Program complexity and size.
  • Tools facilitate fast and frequent planning and updating, minimizing workload imposed by updates, rework, tool mechanics, or breakage of tool, model or infrastructure. I don’t mean don’t re-plan – instead, I mean use tools that make it fast and “easy” to update the plan often to reflect changes, to reflect actual dates particularly on the Critical Path, so that the plan makes sense continually going forward.
  • Turn schedule and logistics data points into actionable tasks for organizations, keeping plan elements in sync technically and across organizations. Supply Chain should be purchasing, and Manufacturing should be building, what Engineering needs. Engineering should be providing systems that Software depends on, and Software should be building software that Engineering depends on… and many more inter-dependencies, keeping those on-time too.
  • Aggregate quantified history, to leverage into future planning both personally and as a PMO resource. “What did this take last time?” is the best estimating technique.
  • Corporate tool packages (like Oracle, SAP for Finance and hardware MRP) are not directly useful for Program Management although they will be used by Manufacturing for actual proto manufacturing steps. They’re controlled for revenue production; Program Management are planning a year or more out, often using components not yet set up for production, subject to change any time, and including planning for development and test structures that will not be productized. Tools for Agile methodologies are useful, but most of these tools don’t talk with sufficient breadth to other tools so leverage is usually constrained to proprietary captive included functionality.
  • PMs will have to develop their own tools. Larger Programs often use Microsoft Excel or Google Sheets, Microsoft Project or SmartSheet. Smaller Programs might use tools like Monday.com. The principles described on this site apply to many kinds of Programs, though. For complex programs, simple spreadsheets will become too limited and fragile with size, change, and time. Post “Quantitative Management” discusses some breadth of alternatives.
  • Considerations regarding use of Spreadsheets vs. Structured Tables vs. JOINed Tables are covered in Post Quantitative Management. Mechanics of JOINs with Structured Tables are not too difficult, will increase your power as a PM significantly, and are a skill worth learning. The Programming Projects section of the author’s website (www.softtoyssoftware.com) provides considerable support for this methodology.
  • Considerations for using a private local database vs. shared local database vs. shared LAN- or WAN-accessible database to execute JOINs are covered in Post Quantitative Management. Security, Privacy, Accessibility, and Maintainability of data and reporting are important factors as you interact with larger and more-distributed organizations.

Further Reading: Core Program Quantitative Structure for System Programs

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

Three Levels of Program Management
Guiding Principles for Program Management Action, Program Quantification, and Leverage Through Tooling.

Organizing Program Communication
Program Management depends on effective communication. Design Program communication paths for everyone throughout the Program.

Database Platforms for Program Management Logistics
Logistics Tool extended, using SQL Server and MS Access with MS Excel and PowerQuery.

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.


Credits
Base Images licensed from www.shutterstock.com
My website: www.softtoyssoftware.com
Copyright © 2022 Richard M. Bixler
All rights reserved

Share

6 thoughts on “Three Levels of Program Management”

  1. Ramya Praneeth

    Thank you for this insightful article, Richard Bixler. I must express my heartfelt appreciation for the captivating insights shared in ‘Three Levels of Program Management.’ This article highlights the significance of Program Execution, Program Structure, and PM Tools, emphasizing the need for adaptability in our ever-changing landscape. The practical guidance offered on developing a flexible Program plan is truly invaluable, enabling project managers to navigate dynamic circumstances with finesse. Kudos to you, for your exceptional contribution to the realm of Agile Project Management. I had the opportunity to post this article and the other article written by you titled ‘Advice for Program Managers – 5 PMO Role which sheds light on the strategic importance of Program Management Offices (PMOs) in enhancing program management effectiveness. It emphasizes the crucial role of PMOs in managing program practices, developing project managers, and fostering a productive work culture. I posted these two articles on my LinkedIn page to spread the word for everyone to read and learn, along with working on their own perspective. I truly appreciate your research, patience, and sharing your knowledge on this topic.

    1. User Avatar

      Thank you very much for your support!
      I have numerous articles on svprojectmanagement.com, with a consistent theme: Project technology may drive project methodology; Agile Mindset in any methodology is achieved by getting the whole organization to be willing to accept change, and also to be able to handle that change. PM leadership can make this happen. Change can come in many forms, and there are many ways to handle it. The methodologies I describe for implementing these principles have been used in multiple real projects with successful results!

  2. This is such a thought provoking post.
    I think it would be useful to work through an example for much of this.
    I am curious about the order in which you discussed each of these three pieces. What was the rationale for ordering things in this way?
    Thanks again!

    1. User Avatar

      I was thinking that I can describe some common and reasonably-comprehensive characteristics of PM management activity, then identify some structural entities I’ve found with material effect on achieving those characteristics, and then dive down one more level on how to implement those structures. That implementation can be tailored to contributing organizations so that it can coordinate tasks among them, and greatly facilitate managing and coordinating change. There are several articles on this website by me that describe programs managed with this layered construct.

  3. Thank you for the blog! this blog has helped me to an extent to understand the planning behind Project management systems.
    I have a few queries related to tools as it is becoming difficult to understand can I get in touch with anyone?
    Thank you in advance.

Leave a Reply to JSE advisors Cancel Reply

Your email address will not be published. Required fields are marked *

Scroll to Top