A program management system (PMS) for international business initiatives
Rollout initiatives for international corporations have been a challenge for years. This is especially true for ERP (Enterprise Resource Planning, i.e. SAP) rollouts where major changes in the processes of the corporation and its units are always necessary. These rollout projects also include business process redesign and standardization/ harmonization initiatives. For some years, lessons learned and best practices have been documented, and are even demanded, by the tool vendors. Still many ERP rollout projects are not being finished on time, on budget, or to the satisfaction to the stakeholders.
This paper describes an approach to manage such an initiative as a Program, not just a Project. It shows the reasons why standard project management alone is not sufficient to handle such an endeavour and defines a structure and functions to overcome the shortfalls, call Program Management System (PMS).
While the PMS was developed and partly implemented in a real life international SAP Rollout, the approach discussed is also applicable to other business initiatives which include different geographical and/or business areas and therefore need special focus on integration efforts.
Problems with traditional Project Management for Business Initiatives
Starting a rollout endeavour may be just a mere project and normally goes pretty smoothly. It is necessary to agree on a project set-up, define standards, and get the right skills and key stakeholders onboard and so on. When the blueprint for a core template is defined and documented and it is being implemented and put into production for the first country or organization unit (also called ‘rollout’), everybody involved may be pretty happy with the achieved results.
Then, normally, the trouble starts.
After the first (pilot) implementation the number of tasks/projects are normally multiplying and the established (Project) management system is not capable of handling the amount of interfaces, change requests information, issues, etc.. Furthermore, integrating functions, as an overall architectural board and a testing group, are not present, not authorized or understaffed. The endeavour is normally proceeding with further rollouts in parallel, as planned originally, but the production and maintenance of the first rollout also has to be managed and there might be missing functions from the first rollout that must quickly be implemented.
As the business environment is also changing, new demands from other requesters, like e-business, SCM, warehouses or CRM initiatives, are starting and require interfaces to the ERP system that may not have been planned for in the beginning.
If the organizational change (e.g. the change to the organization's governance structure, it's processes and roles and therefore the ways how people work and report) was not well accompanied by stakeholder information, involvement and care, the first user community using the system might not be satisfied with the results, which creates a negative image for the whole initiative with an impact on upcoming rollouts.
Also it may be coming clear, that the authorization for the project team may be inappropriate for the international endeavour. Blueprint development and Pilot rollouts are often done for only one geographical and/or business area and are also often focussing on technical information technology (IT) issues. So IT functions may take the lead, the sponsor may be the CIO instead of the CEO and the linkage to business might be too weak to ensure international decision making on the business side.
So what is often experienced, with 10-15 tasks/projects now in parallel, the amount of management effort for the interfaces between these tasks, the stakeholder groups and the upcoming issues can not be handled by the established project management system. Not only is the proper staffing and tooling missing, the procedures and communications and the authorization for integration all the projects and the production are also not sufficient. What is needed now is a structure, that is one authorization level up, a Program Management System (PMS).
In summary, the problems seen in many international business initiatives are likely to be in the areas of integration, business environment changes, authorization/sponsorship, organizational change and interfaces. To tackle these areas of risk for the business initiative, a broader approach than mere Project Management is necessary, available and a proven way to mitigate these risks. This approach is provided by the Program Management System.
The Program Management System (PMS)
What is a Program?
Project Management Insittute's (PMI®) Guide to the Project Management Body of Knowledge (PMBOK® Guide®) 2000 defines a program as ′.. a group of projects managed in a coordinated way to obtain benefits not available from managing them individually. Many programs also include elements of ongoing operation.' (PMI, 2000, p10). In PMI's OPM3™ Knowledge Foundation this definition is extended to ′.. a group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of work outside of the scope of the discrete projects in the program' (PMI, 2003, p173).
One main difference between project and program management is that projects are concentrating on their deliverables and milestones while programs are concentrating on the interfaces between the projects within and also towards the ongoing tasks. Recent surveys and papers show that there is a reasonable difference between project and program management, e.g. as the strategic importance, business relevance and needed skills of management are concerned (Shenhar, A, 2003; Pellegrinelli, S, 2003).
Another major difference between project and program management is that project management is focussing on the triple constraint: deliver predefined scope within a given timeframe and budget. The scope is expressed as product scope in terms of deliverables as a part of the project. A program in contrary is focussing on value generation for the business and it is using projects as a means to this goal.
It can be said that a project is managing efficiency while a program is managing effectiveness.
What is a Program Management System (PMS)?
Operational and Strategic Layers (see Exhibit 1)
The Program Management System (PMS) for a international business initiative presented in this paper consists of two layers: The existing base of projects, the specialty teams and ongoing operations form the operational layer, where ‘the work is done’. There are rollouts to countries and organizations, new functions to be implemented, interfacing systems and also ongoing tasks such as maintenance of productive system parts, operations of the productive systems and User Help Desk. Specially skilled teams needed by several projects or operational functions, e.g. instructors or functional specialists, also are part of the operational layer.
To support, to integrate these operational layer functions and to reduce and to combine and control interfaces to sponsors, business functions and other stakeholders, a strategic layer of functions has to be implemented.
This strategic layer includes general functions normally necessary for any kind of program, as a (technical) program office, responsible for tooling, program repository, planning and tracking on program level, change control and so on. Risk management and quality management also have to be coordinated centrally and standardized within a program. Additionally, in environments where external suppliers are involved in the Program, also the contracts, budgets and billing for these have to be taken care of.
Besides these general functions, specific functions for supporting business needs are necessary: Since ERP programs are always changing the way the enterprise is undertaking it's business, it is mandatory that there is a linkage between the program, it's projects and ongoing tasks and the business management. This linkage is to ensure that business requirements and changes are understood and represented within the program and that they even drive the program by business defined goals and objectives. The business management should even take over responsibility for the whole program.
The PMS presented was defined in a real world example and consists of eight Strategic Layer Functions (SLFs) which are outlined in the following:
Exhibit 1 – Program Management System (PMS)
What Strategic Layer Functions (SLF) were implemented?
SLF 1: Business Strategy - ensures the linkage between business and IT
Within SLF 1 the linkage of the whole business initiative, the program to the business functions and their requirements and requests, is being managed.
In international ERP rollouts there are normally several dimensions of business functions to be considered:
- Country Organizations, which differ in terms of country specific regulations/laws, language, culture of doing business, marketplace etc.;
- Organization Units, which may each have a profit & loss responsibility and also differing goals and strategies setup;
- Process Owners, which have a local, regional or even global responsibility for a specific business process area as Finance, Procurement, Manufacturing, Logistic, Sales etc.
The internal structure of SLF 1 has to make sure that the interests and needs of the business functions within these dimensions are being balanced and harmonized, to the benefit of the whole organization and in regard to the Charter of the Program, which should include the business goals of the initiative. All requests, changes, complaints coming from these business functions have to be funnelled thru SLF 1 and brought to a decision being executed by the program.
SLF 1 should be chartered as a function and must be authorized by the highest level of management in the total organization, e.g. the CEO, in order to be effective in decision making. SLF1 also needs staffing which understands business language and also has skills to understand the program's scope and content.
If the number of requests and changes to the program is high and complex, SLF1 should utilize a Project Portfolio Process to evaluate, prioritize and select the right changes and requests to implement. Prioritization is to be done on the basis of existing goals, strategies and measurable objectives of the Program. Each new change request from business will be analysed and evaluated against a preset range of criteria. A business case has to be developed indicating the business value to be achieved by the change. After having selected projects to populate the Portfolio, the Portfolio itself has to be re-analysed on a regular basis, sometimes projects have to be stopped and all finished projects are to be analysed to determine if they delivered not only the scope within time and budget but also the business value as stated in the business case. A frequent distinction between Project and Project Portfolio Management is that project management ensures that projects are done right while Project Portfolio Management ensures that the right projects are done (PMI Knowledge & Wisdom Center). Within PMS SLF 1 these areas are combined.
SLF 2: Architectural Board - integration of all functional and non-functional areas
SLF 2 takes the lead and responsibility of the overall integration of the delivered system. It includes responsibility for the technical systems with its components hardware, software, network, infrastructure etc. and how they are combined to fulfil the non-functional requirements like performance, reliability, maintainability (System Architecture). SLF2 also includes responsibility for the application and business architecture, thus ensuring end to end integration of business processes across application boundaries and as well as appropriate usage of application features to implement functional requirements (Application Architecture).
SLF 2 also is regularly requested by SLF 1 to evaluate solutions for business requests against the architectural baseline, business case and feasibility. The evaluations are necessary before business decisions can be made on a well educated fact base and with risks identified and analysed.
The staffing of SLF 2 varies as the implementation of the Program or Business Initiative proceeds. For example, just with the rollouts going live, a deep monitoring and tuning on systems performance is often necessary and a focus would lie on technical architecture. On the other hand, when deciding which applications should support the business requirements, and also best fit into the existing application landscape, an application architect's skill is required.
SLF 3: Organizational Change - ensures appropriate stakeholder information and care
SLF 3 ensures that any changes to the Program stakeholder's environment are proactively communicated and any questions, remarks and complaints of the stakeholders are being taken care of.
Stakeholders include members of the Program teams (Project teams, Operational teams, SLF teams), those individuals and groups affected by the program within the organization (e.g. end-users, middle management, staff functions like HR or workers councils) and those individuals and groups outside the organization like clients, suppliers, auditors, environmental groups or the general public.
SLF3 functions include such as those defined elsewhere as ‘Organizational Change Management’, program marketing, and stakeholder care. SLF 3 therefore needs skills like organizational design, governance models, marketing skills, and intercultural balance.
Deliverables of SLF3 may include organizational charts, representation of the program's vision and goal statements, newsletters, program flyers, educational sessions to end users and management, inter/intranet websites, call centre, satisfaction surveys etc. SLF3's focus may change as the program proceeds and it's deliverables are put Live and so affect more and more stakeholders.
SLF3 is the key function that transports and sells the outcomes of business decisions made by SLF1 and implemented as architectural decisions by SLF2 to the affected people. SLF3 is the ‘skin’ of the program visible to the stakeholders. (see Exhibit 2)
Exhibit 2 – Interaction of PMS Strategic Layer Function 1 to 3
SLF 4: Relationship Management - linkage between program and its sponsors
As SLF1 links the program to business functions and their requests, SLF4 links the program deliverables and results to the respective sponsors. While SLF1 creates and approves the business case for changes, SLF4 tracks the business case achievement.
The sponsors might or might not be part of SLF1 and there may be several different sponsors for the different projects, countries, organization units and ongoing operations of the program. SLF4 may present the achievement of Service Level Agreements (SLAs) according to operations of systems (performance, availability, responsiveness, problem solution rate...), Project's progress, and budget status. SLF4 also is responsible for management of a Program issue log and tracks solution of problems, and issues relevant to the sponsors.
The sponsors as a group are also often represented in the Program Steering Committee.
SLF 5: Quality and Risk Management - provides pro-active insights to program status
As every project and every ongoing operation in the Program should incorporate it's own quality management, assurance, control processes and risk management procedures, SLF 5 integrates these for an overall program view. SLF 5, as such, defines standards and procedures valid for the program, checks compliance to these, supports projects and ongoing activities and summarizes the results on program level. In addition, Program level specific risks are identified, analysed, mitigation is planned for and risks are monitored. Risks, especially risks concerning the interfaces between projects and ongoing activities, require special attention and ownership as they are often neglected by the operational functions, thought to be ‘out of scope’ or ‘external risk’.
SLF5 skills are the same as those needed for Project Risk and Quality Management but they have to focus on interfaces instead of deliverables.
SLF 6: Technical Program Office - setting up and administering all the program processes
SLF6 includes these functions normally seen in a Program Office, known from literature and examples: Setting program standards and procedures, integrate planning and performance measurement, execute Project Change Management, enable team infrastructure (tools, locations), communication, ownership of program database etc..
Major focus lies on integrating communications, project files, plans, reports and the operational teams from projects and operations.
SLF 7: Test and Transition - ensures linkage between projects and production
SLF7 manages the interface between projects and ongoing operation and integrates these two scope areas of the program (see Exhibit 3). SLF 7 sets the standards and procedures necessary to make sure that projects prepare and execute the technical and business integration test of the systems being delivered.
Both tests are dependent on the architectural frameworks provided by SLF 2 for a) the technical system landscape (hardware, software, interfaces) to ensure non-functional requirements as performance and reliability as well as b) the business and application framework to ensure end to end processes spanning all applications and utilizing interfaces between applications. As these types of test may not lie within the scope of the singular rollout project, they are necessary from the overall business and program view to ensure the business goals.
Exhibit 3 – PMS SLF 7 integrates Projects and Operations on base of architectural decisions made by SLF 2
After ensuring proper testing and acceptance by business and production operational functions, the Go Live (setting into productive state, often a weekend activity with migrations) may be prepared and executed. Preparation includes education, workshops, detailed planning for migration. Some weeks of after Go Live support is to be planned as support by the project team until the final handover of the system to production may conclude. Handover includes transferring documentation, procedures, communication etc. to production. With Handover checklists normally are being used, that are provided by SLF 7 and open issue lists are tracked. Depending on the maturity of the system, a stabilization phase with support by the project team may follow, under the lead and responsibility of the operational production function.
SLF 8. Resource Management - ensures staffing, availability of proper skills and HR billing as contract management
Often, also, part of SLF 6, Technical Program Management, these functions require special consideration to confidentiality. Resource and Contract Management in a Program deal with Human Resource data as daily rates, Curricula Vitae, appraisals as well as Program Finance data, as budgets, costs, profits, invoices., For that reason it may be wise to form an separate team and function to ensure that access to this data is fenced and not disclosed.
SLF 8 interfaces on the Planning side with SLF4 in respect of Project Change Management and Budget/contract Changes. On the tracking side, these plans and budgets are compared with actuals provided by SLF 6 and invoices are initiated and checked.
Any staffing and procurement requests for external skill suppliers are being handled by SLF 8.
What are the Benefits of the PMS
With these Strategic Layer Functions set-up and authorized properly a Program is able to cover the main interfaces between business and IT functions, between functional and non-functional areas, between projects and production, between the Program and it's stakeholders, especially business functions, sponsors and users of the system to be delivered.
Depending on a Program Risk Assessment, priorities for implementation of the SLFs may be derived. For instance, if there already is an effective Risk and Quality Management Function established within the organization, it should not be necessary to establish SLF 5 separately.
Especially the absence of skilled and empowered individuals taking care of the requirements cycle SLF 1 to SLF 3 is a major cause for failures of business change implementations. If not all business functions are participating in overall requirements gathering (sometime called fit-gap analysis) or the affected end users are not informed properly about changes in their organizations and ways to work, disruptions, will result in rework, conflicts, dissatisfaction and possibly in the Programs delay or halt. The business case of the Initiative is jeopardized.
The benefits of having these functions established and working are outnumbering the costs by far. But it is only necessary to set-up the PMS when the number of tasks/projects to be managed grows from one or two to ten and more. It is therefore important to recognize the right moment to kick-off the PMS and to have planned for this structure in advance.
Lessons learned from real life international ERP rollouts show that they are often suffering from budget overrun and stakeholder dissatisfaction.
This paper presents an approach that was developed in a real life example. It is shown how to properly set-up a Program Management System (PMS). This PMS addresses gaps and interfaces between projects and ongoing tasks and ensures controlled interfaces between the Program's functions and it's stakeholders as business functions, sponsors and end-users.
The differences between Project and Program management described are demonstrated in the context of the PMS approach and it's Strategic Layer Functions (SLFs).
Pellegrinelli, S (2003, May) Understanding and assessing Programme Management Competence, Proceedings of PMI Global Congress Europe, The Hague, May, 2003.
PMI (2000) Guide to the Project Management Body of Knowledge (PMBOK® Guide) Newtown Square: PMI
PMI (2003) OPM™ Knowledge Foundation, Newtown Square: PMI
PMI's Knowledge and Wisdom Center, Portfolio Management Retrieved from https://secure.pmi.org/memberapp/code/premium_content/kwc/KWCtopic_ppm.asp
Shenhar, A. J. (2003, May) Strategic Project Leadership™, Leading Projects for Business Success.
Proceedings of PMI Global Congress Europe, The Hague, May, 2003.
© 2004, Thomas Walenta
Originally published as a part of 2004 PMI Global Congress Proceedings – Prague