One of the challenges of IT management is how to manage and deliver transformation projects on time, on budget, in compliance with the quality standards, while achieving the business’s requirements. BAI01 Manage Programs and Projects1 is good guidance to ensure that IT management has overall project management knowledge.
In accordance with ISACA’s definition, “program” is defined as a structured grouping of interdependent projects that are both necessary and sufficient to achieve a desired business outcome and create value. These projects could include, but are not limited to, changes in the nature of the business, business processes and the work performed by people, the competencies required to carry out the work, the required technology, and the organizational structure.2 “Project” is defined as a structured set of activities concerned with delivering a defined capability (that is necessary, but not sufficient to achieve a required business outcome) to the enterprise based on an agreed-on schedule and budget.3 In other words, the program is a master plan that includes a number of projects. BAI01 defines the following management practices:
For the program:
01—Maintain a standard approach for program and project management
02—Initiate a program
03—Manage stakeholder engagement
04—Develop and maintain the program plan
05—Launch and execute the program
06—Monitor, control and report on the program outcomes
14—Close a program
For the project:
07—Start up and initiate projects within a program
08—Plan project
09—Manage program and project quality
10—Manage program and project risk
11—Monitor and control projects
12—Manage project resources and work packages
13—Close a project or iteration
In the context of this article, the focus is on the approach for program and project management.
The program normally takes place through assessment, design, construction and implementation, which, in some other contexts, are called initiation, analysis and design, construction or package selection, testing and quality assurance, program implementation, and data conversion. The program approach establishes the foundation and agreements, and oversees the program’s activities. It covers the master program plan, scope, stakeholder engagement, reporting mechanism, budget and cost, quality of product, benefit realization, resources and team capacity, supplier management, media and communication, risk management, and issues and changes management. In each area of the program, the program management office (PMO) should assess the performance of the program’s activities in comparison with the planned program. As mentioned previously, the projects are subsets of programs. Aspects of project management are similar to program management.
Figure 1 is an example of a program approach.
Figure 1—Program and Project Management Approach
Source: My Hanh Nguyen. Reprinted with permission.
Scope Management
Based on the business cases that initiate the program, the PMO defines the draft scope. The business cases may derive from a feasibility study, the requirements from a merger and acquisition deal, the result of an audit report, innovation ideas, etc. Once the scope is defined, the PMO:
- Communicates with the business owners to clarify the draft scope, sanitizes the scope in the logical business sense, and consults with other business advisors, if necessary.
- Identifies the list of senior stakeholders who are likely to be involved in the program. Confirms the list of approvers and program sponsors with their authority level.
- Engages the senior stakeholders to understand their expectations and, together with the program sponsors, prioritizes the scope, defines the outcomes of the program, estimates the budget and plans the completion date. In addition, the PMO, senior stakeholders and program sponsors will evaluate the interdependencies of the program with other programs, the impact of the program on the business strategy and the limitations the PMO needs to take into account throughout the program. This step is critical, as it provides direction for the whole program. Confirming documented and written approval is mandatory. The PMO needs to identify out-of-scope areas and document them.
- Monitors the program activities, alerts if scope creep arises, requests scope changes and follows the change management process.
Program Plan
Common steps of the master program’s plan include:
- The PMO defines the draft master program plan at a high level and simultaneously drafts the scope of the stage and gets approval along with the scope approval process.
- The master program plan is divided into program stages from assessment to implementation, including the interdependencies of the master program plan with other programs.
- The PMO manages the progress of the plan throughout the program.
Stakeholder Engagement and Reporting
It is particularly important to program management for the PMO to have early discussions and meetings with the relevant stakeholders involved in the project. This interaction can have a significant impact on how the relationship develops over the program’s life cycle. The PMO needs to put themselves in the stakeholders’ shoes to understand their concerns, determine business matters to drive discussions and steer meetings in an effective manner.
The PMO should take into account the organizational structure, communication protocol, reporting mechanism, culture, behavior and policies/procedures to establish the appropriate approach. In some enterprises, verbal discussion or email communications are accepted while others request more formal documentation. Furthermore, program management should also take into account who should be notified of the program’s progress, issues, etc. If the enterprise has a complex organizational structure and many approval levels, notification, consultation and approval processes can be difficult for the PMO. Challenges also arise when interdependent projects require output from others and vice versa.
Managing Outcomes of a Program
To manage the program effectively and in balance with the enterprise’s procedures, the PMO needs to identify the critical milestones of a full program cycle, information that will be reported, how the information will be reported, the template of the report, and the identity of the authorized stakeholders. Information to be exchanged covers scope, activities performed, planned schedule, resources, planned costs compared with actual cost, root cause analysis of deviation, new issues and how to manage risk, quality of work, expected enterprise outcome, benefit milestones, and stakeholder involvement. This will reduce the risk of misunderstandings, false starts and rework.
Benefit realization is a continuous management process.4 Benefit realization is measured in the program and, in order to quantify the actual benefit from the program, a postimplementation review is usually recommended. In practice, the objective of a postimplementation review is also to make a new business case for a new program. Cost savings, cost avoidance, control/operational effectiveness improvement, security enhancement, and increases in competitive advantages are common types of benefit measurements.
The objective of quality management is to control the work product of the program and ensure that activities are conducted in line with enterprise procedures, the project charters and the work agreed upon in the program meetings. Throughout the program, a great deal of documentation is created, necessitating document control and storage requirements—also covered by quality management. The PMO must establish the process and relevant controls to manage the documentation; then, quality management will refine the program based on lessons learned from its use and directions from authorized stakeholders.
Program Resources and Communication
A good PMO must not only deliver the program to meet its objective, but also manage its program office effectively. Therefore, the PMO has to establish a strong project assistance team to provide support throughout the program. A mobilization project team includes a number of project assistant staff members, so their requirements, specific skills, roles and responsibilities, reporting structures, sourcing plan, and training needs must be defined.
Vendor, scope, plan and outcomes must be closely aligned. Strong relationship-building skills, good communication and a high level of openness are important parts of the process and contribute to the program’s overall success. Normally, a vendor begins fulfilling the program’s requirements in the proposal. If a vendor’s proposal is qualified and selected to proceed in the enterprise’s procurement process, the contract is signed during the completion stage. Those vendor commitments are also used to evaluate the quality of the program. A vendor contract normally consists of these areas:
- Technical scope of work, related deliverables of each stage, work stream and acceptance criteria
- Security commitment and audit requirements (if any)
- Resources
- Program plan
- Project management such as frequency of project meeting, issue escalation process, project form, report template
- Payment terms
- Legal terms such as termination, penalty, liability, intellectual rights
The PMO needs to establish a suitable communication strategy plan throughout the program. The communication strategy plan needs senior stakeholders’ approval prior to execution. The types of communication required include:
- Communication progress of program
- Reporting mechanism to the stakeholders
- Raising awareness of end users regarding the program
- Internal communication within the project team
- External communication to the officers, consumers, customers, vendors
- Information types in case of crises
Communication channels can be formal or informal meetings, discussions, emails, media or events. Depending on the level of importance of messages, the purpose of communication and the stage of the program, the PMO can propose the appropriate channel to deliver the messages.
Issues, Changes and Risk Management
Any program has risk. Each stage of the program has different types of risk while some risk can occur at any time during the execution of the program. An issue is an unexpected event that arises during the delivery of the program. Changes to the program normally derive from such issues. The PMO is responsible for establishing an appropriate risk management program and harmonizing it with the risk culture. A too-complex risk management program may create unnecessary barriers that can adversely affect the progress of the delivery program.
Relationship With Other Enablers and Metrics for Achievement
COBIT 5 describes 7 categories of enabler. They are:
- Principles, Policies and Frameworks
- Processes
- Organizational Structures
- Culture, Ethics and Behavior
- Information
- Services, Infrastructure and Applications
- People, Skills and Competencies
These enablers interact with each other. For example, the project charter is considered as the framework to manage the project. To manage the project successfully, as mentioned in the Stakeholder Engagement and Reporting section, the project charter should be established in consideration of the culture, ethics and behavior of the enterprise. The roles and responsibilities of the project team are a part of the project charter and relate to the Organizational Structures enabler.
The contents of the project charter normally consist of the following sections:
- Purpose of project
- Scope and deliverables
- Timeline, meeting/workshop schedule
- Team structure and roles and responsibilities
- Risk indicators and mitigation plan
- Information and communication
- Documentation control
- General documentation standards (font, line spacing, icon to be used for bullet points, etc.)
- Templates being used in the project
- Document-handling procedure and storage location
- Access rights to project documentation
- Project issue resolution
- Logistics management
In addition to the project charter, other common documents such as risk management, communication and benefit realization documents are also regulated. In the case of small projects, the project risk and mitigation section of the project charter can provide sufficient risk information. With complex projects, a separate risk management procedure is necessary to define the risk types, risk indicators, risk profiles, risk assessment guidance and the results of risk assessment such as risk heat maps and risk logs. The PMO can also refer to APO12 Manage Risk when developing the risk management procedure. Similarly, big projects require a clear communication strategy, communication plan, communication channels, types of information to be communicated, crisis guidance management, etc. The PMO should consider whether to put them all in the project charter or in a separate document.
The purpose of the project itself may not reflect the whole benefit of the program. Each project has its own targets. The benefit of the program will be achieved when the interconnected projects under the program meet their project goals. The business case and benefit realization of the program are used to measure the success of a completed program. COBIT 5 defines metrics for the achievement of goals (called lag indicators) and metrics for the application of practices (called lead indicators). Lag indicators are used to measure whether stakeholder needs are being addressed, while lead indicators are used to measure whether the life cycle of the program is being managed and whether good practices are being applied. On time, on budget criteria or other related metrics that are defined in BAI01 Manage Programs and Projects, such as the percentage of stakeholders effectively engaged, the percentage of deviations from the plan addressed, the percentage of projects undertaken without approved business cases, etc., are examples of lead indicators. The lag indicators in this example are the value brought by the program, such as competitive advantages, brand recognition, cost saving, sales increase, automated and integrated systems, etc. APO11 Manage Quality is good guidance, which provides the management practices for the PMO to define the process of measuring these indicators.
Conclusion
COBIT 5’s BAI01 process, supporting materials, ISACA documentation, and other standards, such as the Project Manager Body of Knowledge (PMBOK) and Projects in Controlled Environments (PRINCE2), provide good guidance for PMOs to follow. COBIT 5 defines management processes from planning to the build, run and monitor stages. There are 32 management processes in which each COBIT process focuses on a specific area, while they also interact and supplement others, for example BAI02 is to manage requirements, BAI03 is to manage solutions, and BAI06 is to manage changes. The metrics related to each process are a good source of guidance for the PMO to concentrate on the lead indicators. The PMO needs to tailor the approach and identify the structure of the program. This requires the PMO to possess skills in organization, communication, team-building, negotiation and detail orientation, and a profound understanding of the program’s objectives, resources, challenges and degree of enterprise support. Shortcomings in any of the areas discussed may impact the success of the program.
My Hanh Nguyen, CISA, CISM, CRISC, CGEIT, ACCA
Is an IT risk assurance director at PricewaterhouseCoopers Vietnam Ltd. She has more than 17 years of experience in enterprise resource planning implementation projects (SAP, Microsoft Dynamics), having been involved in 15 such projects in Vietnam, and IT audit engagement leadership for banks, insurance, fast-moving consumer goods manufacturing, and telecommunication. Endnotes
Endnotes
1 ISACA, COBIT: 5 Enabling Processes, USA, 2012
2 ISACA Glossary, “Program”
3 ISACA Glossary, “Project”
4 Project Management Institute, Project Management Body of Knowledge (PMBOK Guide), USA, 2013