¿Cómo se definen y se realiza un seguimiento de los requisitos del programa?

As a Program manager, I have learned that asking open-ended sequential questions of the right stakeholders can help unlock value and accurately define the program requirements. Questioning often requires a few conversation rounds with different stakeholders entering, exiting, or staying for all the discovery discussions. The dialogue can also build trust with the stakeholders, helping to collect the necessary information and actively listening to opinions, and interpreting the data that supports defining concise requirements with clarity.

Agree with what was said here. One thing to add based on my experience. Clearly list out the outcome of the solution from customer/user perspective after the execution of a given category/prioritized bucket of requirements. This helps driving clarity with stakeholders and aligning with expectations across the board. Example: A user will be able to leverage the solution for doing <list of actions> upon fulfilling the P0 set of requirements. Explicitly calling out the user scenarios will help in internalizing the priorities, defining the MVP, and will also help with later stages of capacity planning.

One thing I have found is helpful is to use software white boarding approach. At first when you are gathering requirements, put them all there on a board. Then take the funnel approach. From the whiteboard , make connections, define relationships and as you go you will drill down to requirements. Once you have the requirements, go back to the whiteboard to see if everything and every stakeholder is covered. Sometimes this is iterative but most times it works.

While developing requirement it is important to ensure, the requirement do not tie out to a specific implementation, rather provide description of what objectives needs to be met. Requirements should be testable. Each deliverable and acceptance criteria for these deliverables needs should be identified as part of the program requirements. Program requirements along with functional requirements shall clearly identify production, sustenance and customer support requirements.

All the items listed are all fine and useful, but keep in mind peoples time and what the key purpose of doing this activity. ❓Having a team of people to define this MAY not make sense. 💢 The program sponsor/leader should take the first shot at defining the program requirements, this has much to do with any potential cross-over into other teams and or internal depts. What can your team and the PM own and manage. ↩️ THEN areas which either have dependencies and or other should work that out with leaders of those teams leveraging the details above.🔝

The gold standard to measure and track project and program progress is Earned Value Management (EVM). The Defense Acquisition University (DAU) has has a neat cheat sheet you can download here: https://www.dau.edu/tools/t/EVM-General-Reference-(Gold-Card)

Risks aren't program metrics. Risks are possible events that may, or may not, occur during a program. Risks can be positive events or negative events. The most important aspects of risks are their likelihood of occurrence and potential impact to scope, quality, or budget. Strategic planning for handling risks is key. Risk management is a continuous, iterative, process that starts during requirements definition and ends at close. Risks and whether they transitioned should be logged in a risk registry or in a risk, action, issue, and decision (RAID) log. Risk management can also help with requirement prioritization. Risky tasks can be done early when there's time to course correct, for example.

Metrics are defined at the start of a program or start of a fiscal year usually. Though in my personal experience, every quarter there is a need to review the goals and the objectives set. Do they make sense ? Aligning to the greater objective or strategic goal is fine but at the level of the program itself, does what we are measuring still make sense? Is the question we need to ask every quarter/ reporting cycle. The goal is to report the right things rather than report against what was set out. So if the right and defined are different, go ahead and make the change. Communicate the change and the rationale.