Three Levels of Program Management

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.

Quantification translates Corporate Concepts (business, market, product, branding, architecture, technology) into Reality: shippable product with continuous life: build-able, order-able, shippable, operable, fixable, enhance-able. Quantification represents "the best-known path from here" in terms that are visible, measurable, and comprehensive. This usually incorporates numbers, currency, visualizations, time… Math!

But Quantification is MIA as a program management focus, it’s not even a topic (either corporate or PMI); there is no available training, only piece-wise tools. Most Quantification efforts are piece-wise, isolated, un-coordinated, un-integrated, under-valued, done with available skill set. Yet the work quantified represents 50% of organizational spending.

This website is an attempt to describe full Program quantification. Examples involve a medium-complexity electronic product, but the underlying concepts undoubtedly apply to Programs of all sizes using most technologies.

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.

"Prototypes are easy, production is hard." – Elon Musk

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.
  • "If you don’t know where you’re going, you’ll end up someplace else." – Yogi Berra
  • 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.

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