From my view, Program Management Office (PMO) helps when we engage with clients to address their requirements which can be full-filled through managing group of projects. PMO should use Work-Breakdown-Structure (WBS) as key tool for identifying required deliverables. By logically grouping these WBS items into projects, we can manage the whole work as an overarching program.The aim of this post is to relate the WBS items to Feature card (MMF) for managing requirements. A WBS item is a hierarchy of deliverables and therefore should be related to the expected software features or services. More precisely a WBS item is related to MMF(s), where the MMF is client valued deliverable. For example WBS item can consist of implementation services of out-of-box product with some limited customization. This limited customization can be translated into MMFs for the Engineering organization.
Does the delivery program include managing the software development project?
Well, I think there should not be any project for software development. The WBS has related MMFs, where each MMF can be composite or simple. Composite MMF is related to more than one engineering team while simple MMF is related to only one. The MMF card should be added onto the overall backlog of the engineering organization with submitted date, target date, intended client and description derived from the WBS. Submitted date is important to calculate Lead Time when the MMF card is fully done apart from being composite or simple. Also, I suggest to deemphasize on priority as this is established by the target date. The Engineering organization should reply back (this should be within 24 hours from my view) to PMO on committed date unless further clarification is required.
Afterwards this MMF card is translated into second level children cards in the backlog of respective engineering teams. Every product owner manages the traceability of requirement till accepted. She participates in the integration to the parent MMF with the rest of product teams. If PMO involves product managers up-front, then probably we can have only simple MMFs because the they can do the split-up . One thing about commitment is that it can’t be completed unless the MMF card is added to the product back of the engineering team.
This process of requirements management starts with the Client to PMO to Engineering. The hand-offs between these three groups are critical to facilitate flow of value to client. A traditional PMO would require estimation from up-front based on fully defined requirement, for me this is non-value add activity and is a drift from Agile principle of being able to work on partial requirements and evolve them till they meet what is really valued by the client.