The leadership-project team gap

by Alex Roan on Mar 14, 2025

Introduction

A key enabler of successful large scale transformation is an effective relationship between senior management and project teams.

Two key challenges stand out:

This post examines objectives, scoping, timelines, and status management to improve this relationship.

As I think about this topic, I realise that many of the challenges arise from the responsibility hand-off and ongoing interaction between the different processes and teams. Hand-offs are a common challenge in business and technology management.

A good place to start is to lay out a simplified strategy and project process and look at how they connect.

Combined view of strategy and project processes

In this case strategy moves from design to resource mobilisation and execution. Design may be done as part of an annual planning process, continuous business review or in reaction to specific business event. Within the design phase, leadership would normally assess business challenges and opportunities. This may lead to the identification of a potential transformation initiative. At some point an initiative may lead to a project as a part of resource mobilisation.

Project management standards and methods suggest creating a project charter document to formally hand-off from an approved initiative to a project. Charters document the objective and high level estimates for key items such as resources, timings and risks. The charter theoretically acts as a contract between senior management and project management and represents a shift of responsibility to deliver. However, in many areas while charters are commonly used they often aren't taken very seriously.

There are two challenges that stand out when moving from an approved initiative to a project:

  1. The objective/value and scope is usually only defined at a high level of detail. This will evolve as the project encounters new information. In particular the scope of work to achieve the objective may only be partially identified.
  2. At the outset everything is an estimate. In the early stages of an initiative estimates are made with limited knowledge and information. As initiatives progress into projects and projects progress through stages these estimates have to be continually adjusted as new information comes to light.

Let's look more closely at the information that is known and how it is refined through the design and project initiation activities.

Let's break down strategy and project initiation into key sub activities:

Detail of stragey project proceses

Zooming in a bit closer:

Zoom into details

In this illustration I've assumed that the strategic investigation into challenges and opportunities leads to ideas for transformation initiatives, however those ideas are not yet mature enough to approve a project. In this case it's not uncommon to approve a pre-study. A pre-study may be assigned to a function leader and done informally or it may have a charter and assigned to a small project team. The pre-study will refine the scope and high level timeline as well as assessing feasibility by looking at key factors such as issues and risks. The pre-study then may lead to a project.

Initial recommendations

With these top level challenges in mind a few initial recommendations:

  1. Ensure that senior management & project management are aligned on the nature of estimates and the potential for revision
  2. Formalise the hand-off between strategy and project deliver and ensure the charter is fit for purpose
  3. Expect the unexpected. Projects will encounter new information. They are a journey from the unknown to the known. It isn't necessarily a failure to have scope changes, resource changes or timeline changes during project execution.

Main challenges

I'd call out three fundamental factors that may not be well managed during this handoff from strategy (senior management) to project (project team):

  1. Accurate identification and understanding of objective/value and scope is critical. This forms the basis for every part of the project. Strategy presentations, charters and project initiation documents often don't define this in enough detail. Furthermore, the relationship between expected value and scope is often not well managed throughout project delivery. This should be a constant focus. During a project, the project team and senior management need to make decisions with the impact on expected value at the forefront.

  2. Project plans and timelines are poorly prepared and the rationale and assumptions behind them are not well understood or communicated. In my experience overtime and delays often relate to poor quality planning. This is in part due to poor planning processes and in part due to a poor planning basis i.e. poorly defined scope as per point 1.

  3. The quality of information sharing and the effectiveness of time spent together between senior management and project teams. As projects progress into new levels of details they will face challenges with scope, resources, issues, risks, technical complexities etc. Projects need to transparently communicate their status and the root cause of any problems so that both team experts and senior management can make the right decisions and execute the right interventions to move ahead in the best way possible. To be more concrete items like status reports and activities such as steering committee meetings are often not fit for purpose.

Thinking through this we can already see that optimising the connection between senior management and project teams is not a simple matter. We need to dig deep into some of the fundamentals of defining initiatives and managing projects.

To continue the discussion, let's start by exploring the different perspectives of senior management and project teams. Then, take a deep dive into two key topics: (a) objective/expected value and scope, and (b) project effort/timelines. After that, let's examine status reporting before concluding.

Topic 1: Perspectives of senior management and project teams

There may be some important differences in assumptions between senior management and project teams.

1- Senior management may fail to understand the details of the challenge a project team faces

2- Project teams may fail to understand senior management expectations

Keep in mind the perspective gap can be quite wide. In the case of large scale transformations such as a) an ERP upgrade with SAP S/4HANA or b) a major acquisition, senior management participation may include c-suite executives and project lead participation may include workstream leads at the analyst level.

It's useful to consider the different perspectives of senior management and project teams. We can illustrate that there is fairly little common ground. This can represent challenges in terms of achieving an aligned understanding or in communicating complex information.

Management-project team venn diagram

Typical senior management perspectives:

Typical project teams perspectives:

Some of these points may be a little extreme, but they illustrate the differences that may exist. I believe that good steering committees tend to have members who can look at the business through the project and operational perspective and likewise good project managers can look at the business with a strategy management perspective.

With these differences in mind it’s critical that we manage initiatives and projects in a way that ensures:

Topic 1 Recommendations

At the outset I'd suggest that senior management and project managers discuss this topic. A change management framework such as ADKAR would be a good tool to use to construct a survey and run a workshop to allow all members to think about and share their individual perspectives, this could include:

The results of this could help to identify which areas of objective, scope, plan etc. need to be further detailed and which information needs to flow to which parties during the project execution.

Topic 2: Objectives, expected value and scope

Project initiatives are usually identified as part of strategy management. Common scenarios are as part of an annual planning process or as part of a regular business review in response to a business event. A transformation initiative should relate to a challenge or opportunity, with a clear objective. As part of the objective, a quantifiable expected value should be set.

Setting an objective with a value does a few useful things.

In addition to this, a clear and detailed objective and value will help focus scope. The more clearly we can tie scope to a quantifiable expected value, the easier it will be to evaluate issues with the project scope and make decisions on scope changes.

I would categorise the main issues with scope as follows:

1- Missing or incorrect scope: it can be quite hard to identify everything that needs to be done to achieve an identified objective, this is especially true in the early project phases where perhaps not everything is known and the project may not yet be staffed with experts who can help with this

2- Objective/value - scope misalignment: When transitioning from strategy to project a range of people may be involved in converting the objective into scope. During this process the connection may be partially lost:

And this is within the context that scope is usually defined and agreed between senior management and the project team.

Clearly link the objective and value expectation to the individual scope items. The project team and senior management should be ready to consider a trade-off between scope, timing and budget at any point. It’s much easier to make these decisions when it’s clear what in reality each scope items means.

Topic 2 Recommendations

Scope management basics

As a baseline I'd recommend to define scope in as much detail as possible. This usually means stating what is:

I'd suggest the following good practices:

With respect to the point about third parties in my experience it's quite common for them to underestimate scope particularly on requirements. It's also quite common for them to have various assumption for 'out of scope' items that the client may assume are in scope. This often leads to unexpected change requests.

How to identify or evaluate proposed scope

Senior managers, project managers and experts need to take an objective and develop a scope. This can be quite challenging. This is particularly the case for large scale transformations where one individual or even a small group of individuals is unlikely to have the technical knowledge to assess each impacted area and identify scope items.

There are some useful approaches to identify impacted scope. With all of these it may be safe to start with a list of potentially impacted items and then narrow that done to a more confident scope.

  1. Review policy, process, architecture and data documents for impacted areas, pull out anything that may potentially impact for discussion
  2. Interview experts, team leaders, managers for impacted areas.
  3. Utilise external standards and frameworks.

Finance example

If there is an initiative to improve finance function operational efficiency by 10% during an upcoming ERP upgrade, the following might be useful:

For business orientated projects this is a good way to start with the business focussed scope. However the scope may also include technical work on roles, data, systems, so the objective - value - scope of these areas should also be clarified.

Information technology in particular can be difficult to document in a way that allows a cross functional audience to understand it. If the current state IT processes are not well organised or easily understandable these can be mapped to IT standards and those IT standards used as a checklist to make sure everything is considered. IT stanards of interest for typical business transformation programs include:

These frameworks can help us think about deliverables and actions that we need to consider when documenting the scope of work for systems development, infrastructure deployment, post-go live support. Searching for and reading an overview of each can be very useful for Non-IT managers and team members to get an insight into the scope of IT work that is sometimes required to deliver business scope via systems.

Scope list example

For an ERP implementation such as SAP S/4HANA it's not uncommon to see fairly simple scope lists. These may just be listings of functional processes and SAP components or modules. This can lead to misalignment between senior management, project teams, or internal and external parties. For example if a scope statement says 'Finance General Ledger' management of a company may consider this to include all possible general ledger activities in SAP. However a technical expert or an external vendor may consider this to only include a main ledger and to exclude topics such as parallel valuation. Parallel valuation itself could be one of several technical solutions.

Considerations when defining scope:

It's quite easy to find a checklist of these items for any given functional area undertaking ERP or reporting programs

In addition to defining the list of scope items it's a good idea to enrich it with some additional information that may help in the management of the project. This may include:

Going back to a finance ERP example I would assess an item like cost center hierarchy re-design as low complexity, low risk, but potentially medium effort. Alternatively a topic like margin analysis / profitability analysis would be very high complexity, very high effort.

How to align scope to the objective and expected value

Having a comprehensive scope list is part of the picture. The other part is ensuring it is well connected to the objective and expected value.

Finance ERP example

Looking again at finance we may have a scope list that is organised by function or system component. Something like this:

finance scope list

However, in many cases an ERP project has an objective beyond just implementing a new system. With the above scope list if our project encounters issues it's not particularly transparent at a glance to see what the impact of changes to different scope items might be. If we assume this ERP project has several objectives we may be able to categorise our work by obejctive. When we encounter difficulties it's then easier to assess value impacts.

Assuming some fairly common finance objectives:

We can see that our scope activities do align to different objectives.

finance scope list 2

In the above case if the project is under resourced and delayed and we know the top priority is common language we may start to propose to remove some steps from scope. For example we may de-prioritise the manual journal review which constitutes part of the controls objective and re-assign those resources to assist with the accounts review.

Topic 3: Effort and timelines

The second big misalignment between senior management and project teams comes with estimates. This is part of the project planning process.

Planning is a huge part of project management and methods such as the project management institute’s PMBOK go into a lot of detail on this. However, many projects do not follow good practices when it comes to planning.

And this is all in the backdrop that whenever we create a plan we are working with limited information. Any plans and estimates we create are prone to change as we move into more detail throughout a project.

There are two things we can do to improve this situation. The first is to ensure that senior management and the project team are aligned on the nature of estimates and the potential for change. This may sound fairly obvious but I've often worked with people (at all levels) who consider a project plan to be a fixed contract that should never change. They may consider any change as the fault of the project team and demand that there be no more changes. The second thing we can do is to try our best to make realistic estimates and keep the context of those estimates in our mind. To cover this we will need to deep dive into estimating and planning.

Why focus on planning and estimating

In the situation where senior management set a fixed timeline for a project it can still be useful to create a theoretical plan based on deliverables, activities and effort. This help us to:

All of this can be useful to try pin point areas where we can adjust our theoretical plan to come closer to the desired plan.

Building a plan and estimations

ERP projects are often staffed with a wide range of business, IT, and data experts who aren’t necessarily project management professionals. Large projects like these are usually split into ‘streams’ or sub teams that need to do their own planning. I’ve often had discussions with team members on how to plan and how to estimate effort.

This is not an easy topic, but it’s one where we need a transparant approach in order to align between senior management and the project team. Let’s break it down.

Top-down plans and estimates

A project may have start and end dates pre-defined as part of the strategic planning process or project pre-planning activities. In the case of ERP programs the logic behind these is often:

Top down-planning may be a bit more detailed, but at the end of the day it doesn’t factor in a consideration of the individual activities required to deliver the scope.

Building detailed plans

To make detailed estimates, we need detailed plans. The classic way to do this is through the ‘work breakdown structure’. In theory, it’s straightforward, but to build a good one takes time and expertise. What we do is take the main objective and break that down into it’s constituent parts. The focus is on outputs, not activities at this stage.

So if we are implementing S/4HANA we may start to break it down like this

Once we have identified outputs down to a level where we can start to define a process to create them we can start to create our detailed plans. Let’s take for example ‘GL – accounts’

At this point, we start to have a basis for estimation.

Estimation for detailed plans

Common methods to estimate include

When working on multi-stage rollouts we may also apply efficiency factors for waves as we move forward.

When it comes to expert judgement the accuracy of this will be impacted by

These factors mean that expert judgement and estimates don't necessarily come together as realistic plans.

For example, my own opinion on an accounting policy review for one country of a large business may be:

Assuming none of this is in parallel, it adds up to eight days effort.

We can improve on the above with the ‘program evaluation and review technique (PERT)’. In this approach I'll make 3 estimates

A formula can then be used to get a weighted average. My estimate above is fairly conservative so in reality I would probably make it as worst case. Thinking through the exercise in more detail I may come out with totals of:

Applying the PERT would give a weighted average of 5.16 days (read online for the formula).

PERT uses this approach to estimating together with critical path identification to help create more realistic project plans. One of the big benefits of this approach is when planning as part of a team or in a workshop. Often there will be different opinions on the effort behind an activity. PERT allows you to capture the more conservative and more optimistic views and calculate an average.

In addition to using this weighted average to create the theoretical project plan I would also suggest that it might be beneficial to use some of this information for our project tracking.

When we discuss progress between the project team and senior stakeholders we may find it useful to track

As we progress through the project we can look at how close our actual effort aligns to our planned effort. If we observe one month into a six month project that our actual effort is often in line with our worst case effort we know that between senior management we need to have an immediate discussion and intervention as for some reason our project is performing at a much lower level than we expected.

Alignment of how effort estimates work and this kind of tracking between senior management and project teams may help shift from the dialog blame and frustration to a more analytical focus on planned vs. actual effort and organisation transformation capability.

If this is combined with some of the previous points where we discussed defining complexity, knowledge etc. for scope items we start to get very good reporting that help us understand the reasons why a project progresses how it does. This helps to define better interventions.

Further reading

This is just a small part of the process of converting an objective into a plan. I believe a lack of estimation or poor quality estimation is at the root case of many project issues, however there is a lot more to read on how to use work breakdown structure and the ‘critical path method’ to create project plans.

Topic 4: Status reporting

Reporting content

From small to large scale transformation programs I sometimes see single page status reports. For example:

Example 1: mainly text points Status report example 1

Example 2: text with tabulated activity status Status report example 2

These are fairly simple illustrations. In reality status reports will be more detailed, however these do illustrate some of the issues that exist.

Lack of focus on the objective of status meetings

Status review primarily exist to make decisions and initiate actions in the interest of the business strategy. I purposefully don't say 'project success' as sometimes the best decision for the business is to stop a project.

With this in mind the materials for a status meeting should be carefully constructed to share information relating to the status of work towards the objective with an orientation towards facilitating discussions and decisions that may be needed.

Lack of reference to the objective/value

As projects work with focus on activities and deliverables it's tempting report the status of those. However, we really want to keep an eye on the status of the objective and it's expected value. It's possible that as requirements and design options are analysed a 'scope element' may progress in terms of activities and deliverables and hence may be reported positively, however the associated value of that solution for that scope item may change. Any change in this should be reviewed and corrective actions or scope changes may need to be discussed.

Status impacts not made clear to all involved parties

The wording of certain activities and deliverables may not carry meaning for all involved managers and stakeholders. This may be especially true for activities at more technical levels of detail. For example on a large scale complex transformation a status report flag issues with master data management interface progress, this may be a dependency for finance achieving a 'common language' across systems. This may not be clear to finance stakeholders.

When presenting status particularly for off track items it's important to clearly define impacts in plain language.

Activity naming

We already covered linking activities to objectives. This carries through to activity naming in status reports. For example we may see a delayed activity 'Finance workshop 1' in a status report. With this information it's very difficult for senior management and stakeholders to provide help. If we work activities by objective it may help. For example rename the activity to "Finance workshop 1: identify estimated efficiency savings".

This kind of simple change will help stakeholders and managers sense check if they have promoted the right participation in activities and also understand the downstream impact of those activities not being done.

Inaccurate or misleading views of progress

Quite a long time ago I had a conversation with someone about how misleading '% complete' is in project plans and status reports. This struck a note with me as I've encountered team members in project before that I know have given me false reports such as 80% complete in order to get me to stop asking them for updates, or to stop me from putting them as 'off track'.

This problem extends to red-amber-green status assessments too. The problems with these approaches include

My current viewpoint is it's better to simply track not started, in progress or complete for a task. However there are certain tasks that can be tracked in more quantifiable ways. For example activities such as 'extract accounts', 'review accounts' may be tracked in terms of for example 100/1000 accounts reviewed.

Lack of clarity on open items and follow up items

When a project works through requirements analysis or design it will often complete activities such as document reviews, interviews and workshops. Each of these will likely lead to issues, questions, uncertainties. Informally these are often called open items or follow up items. It's important to track these alongside the activities.

It's useful to apply some categorisation to these. This can include complexity, impact on expected value.

An open items and follow up item lists may act as an early warning signal for a complexity that may become a significant issue for the project. That's because this is the first point someone may write down something that doesn't line up with the understanding of the objective, scope etc. It's crucial to monitor items in these lists which are not progressing. They are likely not progressing for an important reason such as lack of knowledge resource or significant complexity.

Lack of update to project risks

There's no need to review the complete project risk log at each status update. However it's important to add any new risks to the log as they arise. New information may also mean adjustment to existing risks or their mitigation plans.

No actions for off-track items or issues

Anything presented as a 'off-track' during a status meeting should have an impact and recommended action. This may include:

With the relationship between project teams and senior management what we want to avoid in status reports is open ended discussions and brainstorming. Those are valuable activities but should be in smaller more focussed groups.

I'd recommend in the case of significant off-track items or issues there is a separate paper dealing with the detail. Ideally as a pre-read. I'd also recommend always preparing options if possible with quantification of the benefits, disadvantages of each.

Over emphasis of progress and achievements

As managers and project team members we are only human and there is a tendency to try and focus on the positive and also to justify the use of resources this can lead to review lists of work done or achievements. If that work was part of the plan there is really no real value to spend time focussing on it between the team and senior management. Time is better spent on points requiring some action.

However, maintaining a positive environment around a project is important, and this can be achieved beyond just senior management and project manager meetings. I would suggest a separate way of updating and sharing progress and achievements. This can be done as part of an information sharing / project awareness newsletter. There are a few extra benefits of this:

Reporting format

In line with the above discussion I believe content is more important than format. For example any layout or tool may work well if the content is well designed. This includes dashboards, spreadsheets, presentations etc.

Reporting tools

Online project management/task management tools can be a useful addition.

Large projects may have teams of over 100 people working on 1000s of tasks at any given time. Collecting the project status in this situation is significant pain point. It's a big effort for project management and it's a disturbance for team members. Project/task management tools such as Asana can help here. If we set up the project plan in these tools with detail down to the task level and ask the team to use it as a 'daily management system' we should be able to see detailed status in real-time with no extra effort. This does require an effort to set up, and an ongoing effort to govern and adjust, but once a team is used to it, it can work well.

In line with various points discussed when we set up our detailed plans, we should ideally enrich them with:

With this information in a single location for a project we can easily filter on overdue activities by complexity and objective.

Reporting recommendation

The single biggest improvement with status reporting is to shift from providing a general summary of the project to focus the discussion on factors that will improve the likelihood of project success (or project cancellation!).

From the perspective of project managers/teams:

From the perspective of senior management:

Information that we can probably drop from status reporting includes:

When drafting a status report I would do a sense check on the information included:

If the answer to these is no, question why you are presenting it.

As a sample of an alternative status report I would be tempted to go with an individual page which covers the key factors and highlights if they are an attention point or note. For any that are attention points I would then have a separate page deep diving into those topics.

Status report 3

In this example I've highlighted three key areas 'objective/value and scope', resources and timing with a brief statement on impact and whether an action / intervention or help is required. Where something is required we refer to another page for the detail. In this case illustrating the impact of a 2 day delay along with options to proceed.

Status report 3

A note on project plans and GANTT charts in status updates

Note that this kind of summarised activity list / timeline doesn't represent the actual project plan. Detailed project plans are in my opinion management tools not information sharing tools. It can be useful to prepare summarised views for communication with people who are not involved in the details of planning. However, in the case of summary views, it may be necessary to add explanatory notes.

Participation and timing for meetings

Setting up the management meetings for large cross functional projects can be complex. This really needs to be designed for the individual project, but there are some considerations to keep in mind

Often large transformation projects suffer from meeting overload. A few things that can help:

The biggest recommendation to optimise the meeting approach is to be flexible and react to what works and doesn't work. If meetings between the project team and senior management do not go well question why and figure out an alternate approach to improve the situation.

Conclusions

As stand-alone processes strategy management, and project management are both very good at managing everything they need to. The challenge occurs when these two teams have to collaborate on a complex initiative in a finite timeframe.

If both groups, senior management and project teams, think through this collaboration and pro-actively share information in an efficient manner, it will improve the likelihood of success.

Hopefully the discussion points above can provide a 'checklist' of things to think about for this collaboration.

The discussion primarily addresses the connection between the project teams and stakeholders. There is one additional complexity that often occurs on projects. Large-scale transformation programs can represent the first time different functions have to collaborate on a complex activity. Often the functions may have competing priorities. Classically IT may want to support the business, but it will also want to build according to its own architecture strategy and within that it may have it's own priorities. Unfortunately, in this circumstance the project manager and the project team may become a mediator between competing function strategies. This kind of cross-functional challenge may manifest in various ways:

As part of our overall discussion on senior management and project team collaboration it's useful for senior managers and project team members to be clear on their information needs. This collaboration can involve:

For senior managers and project teams, here are the kind of questions you should consider asking as part of the project collaboration

Questions senior management should ask

Questions project teams should ask

Did you find this discussion useful? Are there any topics you think would be worth exploring more deeply to produce a framework, checklist etc.?

Share, comment/discuss

Share on LinkedIn, X, or Facebook.