In this article we will talk about the organizational structure to put in place in the context of strategic or business transformation programs.

These programs are by nature more or less unique within organizations and require a specific setup to address their challenges.

Speaking a common language across departments

One often mentioned challenge is the necessary alignment between Business & IT since many of these programs involve both and these departments often do not have the same methodologies, because they cover different types of projects.

For one of our clients we had divided the project types in 5 major categories having each a different focus and methodology: R&D (product development), Engineering (plant construction or extension/improvement), IT, Business Process Reengineering, Continuous Improvement (Lean Six Sigma). In addition to these 5 major categories, there are smaller repetitive projects closer to the operations of departments but managed as projects, such as marketing campaigns, some maintenance programs in plants, etc.

When we talk about Business & IT alignment we should then look at which business department we are referring to and which type of projects, but there is a general need to align methodologies between different departments having a different work culture related to the nature of their activities.

For example, for another customer, we had to find a common way to manage 3 concurrent initiatives:

• the start-up of a new subsidiary led by the Finance, HR and Supply Chain departments,
• the construction of a new warehouse and manufacturing plant managed by Engineering and
• the development of a new IT solution developed by the IT department.

Another example was a large Business Process Reengineering for Finance and HR, including the creation of a new subsidiary providing Shared Services to European countries and the outsourcing of the HR platform to a partner. There as well we had to find a common ground on how to manage a number of projects with the same guidelines.

Two major aspects must be standardized:

Program & Project Planning

Project Management standards should be common to all projects belonging to the same program. This will ensure consistency of information and eventually quality of decisions.

Level of detail in planning and tools to be used should be agreed upon at the beginning and enforced throughout.

Project Execution & Monitoring

Project health indicators should be standardized; typically

• Scope: is there any major scope change that requires approval?
• Time: are we reaching major milestones within tolerance?
• Cost: are we within tolerance compared to the budget?
• Resources: do we have the quantity and quality needed to ensure success?
• Risks: do we face unmanaged/unmanageable risks?
• Change: are people too worried that they cannot move forward efficiently? Is there significant resistance that cannot be overcome? 

Status reports should be provided regularly by project managers to the program manager and shared within project teams (removing some sensitive information if needed).

Program Dashboard should present a one-page summary of the health of all projects to allow top management to quickly spot issues and risks.

Making decisions by the right people

Probably the most important aspect in large programs is the capability to make decisions in an efficient way.

Decision Making is very much driven by the corporate culture and the level at which the program is managed.  For example if you have Japanese top management to report to, you will have to demonstrate that your approach is not too risky and rely heavily on numbers to enable a collective decision. If you have American top management, decisions will be made by fewer people and with less aversion to risk. If your program is managed at Belgian level, there is good chance that decisions will be more consensual and softer. Of course it also depends on the personal styles of the main decision makers.

Key decisions to make:

Regardless of the decision making style which will influence the way you should present proposals for decisions to make, there are a number of key typical decisions to make in such programs. Here are examples: 

• Scope of program & projects: where does the program stop in terms of geographical scope, or process boundaries between projects, for example.
• Allocation of budget and resources: how much money and internal resources are available, for example how many resource backfills you need during the program to allow internal experts to dedicate sufficient time to the program
• Partner selection: decisions on whether to outsource or not some part of the scope, e.g. using a Big-4 consulting company to support process design, or use an IT company to deliver a full turn-key solution instead of hiring individual contractors to fill in team members positions.
• Process design: decide on business rules related to a specific process, e.g. require procurement approval from upper management beyond a certain amount or decide whether the company enforces electronic invoicing from its suppliers
• Infrastructure design: decide on the location of a shared service center or plant, or decide on the capacity of a plant
• Technological decisions: decide to implement a full standard ERP package or best-of-breed modules
• Go-No Go to the next project phase: decide if the deliverables of the current phase are of sufficient quality to move to the next phase
• Stop/Abandon project: determine if a project in jeopardy should be stopped or redirected to a new scope or objective 

Decision bodies:

These decisions should be made by a number of decision bodies. Here are typical examples:

• Program Steering Committee: this body should make decisions at investment level (where to allocate funds and resources) related to the business case; in particular, the monitoring of the business case and assumptions taken initially to start the program about costs and benefits and the resulting payback, net present value, or return on investment, should be regularly made and presented to senior management.
• Project Steering Committee: this body should cover process & solution design; as a program is made of a number of projects, detailed decisions should be delegated as much as possible to the managers who will eventually be in charge of running the business
• Business Sounding/ Change Management Board: this body should cover business impacts and may not have a decision power but must certainly advise the Program Steerco; in most strategic programs, change management is a key success factor, therefore the input from a wider range of people impacted on the workfloor is important. Change should be managed as a specific aspect of the project by dedicated resources for large programs. This covers among others organizational readiness assessment, individual stakeholder assessment, communication, training, incentives, resistance management.
• Architecture Board: this body should ensure that process and solution design across projects remains consistent and aligned with the long-term company objectives; it also provides advice to the Program Steerco

Each of these bodies should not be constituted of too many people. We recommend between 4 and 8 people max.

Sometimes in Steering Committees we see more than 10 people around the table. This is likely a sign of lack of delegation or lack of preparation of the decision before it hits the Steerco, or an issue with the level of Steerco that should take the decision (project versus program). 

Having Clear Roles & Responsibilities – Focus on the Project Management role

Since these programs occur every now and then, one cannot take for granted that individual responsibilities are clear to all participants.  It is definitely worth taking the time to agree upfront on these responsibilities with key managers (typically working on a detailed RACI matrix with all deliverables and all roles), communicate them to team members and ideally ensure these responsibilities are translated into performance evaluation criteria to make expectations clear from the start of the program, just like they are in regular business operations.

We will not provide here a full list of possible roles with their duties. If you want to get more details about all typical roles in such programs, please contact us. There are typically 4 major families: project management, business, IT and business process management making the bridge between the latter two. In some organizations, the business process management team is part of IT, in others it is part of business.

The project management role may be distributed in different roles depending on the program setup:

Project Manager and Product Owner

The Project Manager focuses on moving the project forward whereas the product owner focuses on making sure the product/solution is viable.

If these two work closely together, they can be much stronger as you can combine an experienced external project manager able to challenge the teams in terms of solutions and pace, while building or leveraging deep internal functional knowledge that is difficult to find externally.

Internal Project Manager and Partner Project Manager

In case part of the scope is outsourced to a third-party consulting company, there is typically a Partner Project Manager assigned and both the internal and the external project manager must align. It is important to have both roles filled in to ensure the interests of the customer and the partner are taken into account to ensure a long-term successful relationship.

Business Project Manager and IT Project Manager

The split of responsibilities is made based on deliverables to be managed by business or IT. As IT is often seen as an internal supplier/partner, similar remarks as for the Partner Project Manager usually apply. 

Both roles can sometimes be held by the same person, depending on complexity and skills. However, most people have either experience in Business or IT, so it is not easy to find people who can play both roles.

Business Project Manager and Change Manager

The Project Manager manages the entire scope of the project while the Change Manager can provide a useful transversal view of impacts on the business and how to cope with it, especially in the case of projects covering multiple departments. 

The change manager has typically also been a project manager but focuses on the soft/human issues, which are time-consuming.

In smaller programs or projects, these roles may be fulfilled by a single person.

 

We believe the topics above, methodology, decision making and roles & responsibilities are key success factors in managing strategic programs. Your comments and questions are welcome. 

 

Articles on the same topic: 

Efficiently deploy your projects with pragmatic Project Management

Assessing Project Health

Strategy to develop project management in a low-maturity company

Customer reference: Alter pharma