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:
- It's an intersection of two distinct processes: strategy management and project delivery
- It involves the collaboration of two groups with very different perspectives and focuses.
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.
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:
- 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.
- 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:
Zooming in a bit closer:
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:
- Ensure that senior management & project management are aligned on the nature of estimates and the potential for revision
- Formalise the hand-off between strategy and project deliver and ensure the charter is fit for purpose
- 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):
-
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.
-
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.
-
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
- Level of technical complexity
- Workload
- Availability of appropriately qualified and/or experienced resources
2- Project teams may fail to understand senior management expectations
- Nuances of the expected value/objective
- The projects prioritisation in amongst other initiatives (competing for resources)
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.
Typical senior management perspectives:
- Focussed on value
- Main attention is on the business/market & context driving project
- Has a view of planned/in-flight transformation across the organisation
- Accountable for resources. Tendency to deep dive there
- Has decision-making authority
- Technical knowledge may be 'out of date'
- May bring biased thinking from their past when they were part of different project teams, but conversely may have much more experience and bring high value insights.
- May not appreciate analysis, design, build etc. effort
- Likely to have very limited time for an individual project. Challenging when decisions need to be made on complex design areas
Typical project teams perspectives:
- Deep knowledge of the specific domain the project relates to (e.g., process, technology, data, etc.).
- The ability to monitor the project and identify issues, and risks
- Ultimately controls whether value is delivered by their design recommendations/choices
- May have a tendency to make suboptimal design decisions, not understanding longer-term business priorities and strategy
- May think more in an 'operational' silo.
- May not fully appreciate the strategic context or expected value
- May be unaware of scope or timing conflicts with other projects
- Lack of authority over resources. Including the ability to manage poor performers and part-time team members
- As a temporary organisation may struggle to influence functions and teams
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:
- A common understanding across both groups: scope, resources, timing, status etc.
- Appropriate information flow for real-time decision making on any course changes.
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:
- Individual preconceptions
- Fears
- Areas of discomfort
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.
- It helps test whether the objective is worthwhile
- It provides a basis to evaluate the cost to implement the project (and run whatever is delivered)
- It provides an expectation to measure success against
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:
- Either through a lack of knowledge or simple mistake, deliverables or activities may be identified that are not really necessary to deliver the expected value
- Individuals, teams, functions may use the project as a chance to add their own goals into the work. It's easy to rationalise in the logic of "If we are reviewing this in detail we might as well also do this"
- Teams may define scope in terms of solutions (target processes, systems, data, roles) during scope identification. Rather than identifying the scope of work for requirements analysis and design they may jump to defining scope by solution. This can lead to more complex or expensive routes to the expected value than absolutely necessary.
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:
- In scope
- Out of scope
- Any assumptions taken
I'd suggest the following good practices:
- Ensure scope is understandable by all relevant parties. This means using plain language with appropriate definitions. This can bridge the knowledge gap between levels and functions. Consider:
- From the most junior team members to the most senior management
- All impacted functions; IT, HR, finance, operations etc.
- Any external parties involved (especially internal terms which may not be well defined)
- Do not rely solely on third party scope proposals:
- Often software vendors, system integrators and/or consultancies will prepare scope
- Third parties may benefit commercially from low or unclear scope
- Third parties do not know the hidden complexities or nuances of their clients business
- In the case of a new type of initiative, look for ways to quality assure the scope, consider:
- Expert interviews
- Consulting firms
- Comparison with best practices (standards, community groups, research agencies)
- Multi-vendor project structures splitting up design/deliver/quality assurance etc.
- Formalise the scope development process and the sign off.
- Ensure each scope element has a formal owner
- Qualify carefully who can propose or define scope
- Ensure draft scope is circulated and feedback is tracked, recorded and actioned
- Require formal sign off where owners are accountable for any future scope changes
- Alongside each scope item capture some useful attributes; level of certainty, complexity, availability of internal expertise etc.
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.
- Review policy, process, architecture and data documents for impacted areas, pull out anything that may potentially impact for discussion
- Interview experts, team leaders, managers for impacted areas.
- 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:
- Start with the finance function org structure
- By looking at teams we can identify process areas
- Identify managers to survey/question/interview
- Identify potentially impacted roles
- Look at policy and process documents
- Further refine process areas
- Identify data elements and systems to consider
- Interview members of the finance team
- Refine understanding of all of the above
- Enrich the draft scope with information such as process maturity, complexity, level of knowledge, current issues, risks
- In some cases, the existing operation may not be well organised, and may not be using standardised or good practice team structure, processes or systems, in this case we can leverage external information to identify or better structure scope
- Refer to official bodies and standards. In the case of finance there are organisations such ACCA, CIMA . They have many publications on the structure and activities and good practices of the finance function.
- In the case of ERP programs refer to the software vendors reference processes, best practices or other templates. In the case of SAP ERP you have the best practices/signavio process navigator
- SAP also have their transformation methodology which can also give some guidance on scope development.
- Other external sources of knowledge; research firms, consultancies, community groups and expert interviews
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:
- TOGAF: Enterprise architecture focussed
- ITIL: IT service management focussed
- COBIT: IT governance focussed
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:
- Sizing of master data:
- Number of accounts, customers, vendors etc.
- Scope and size of configuration data
- Number of legal entities, plants, currencies etc.
- Scale of complex, custom or unusual processes:
- Complex requirements such as parallel valuation (i.e multiple ledgers)
- Unusual processes such as negative balance profit centers
- Technological complexity such as custom programs
- Interfaces from/to external systems
- User interface
- Number of users, number of unique roles
- Reporting
- Number of reports, type of reporting format / tools, content of reports
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:
- How complex the scope item is
- This can be as simple as 'high, medium, low' or something more advanced
- Level of internal knowledge / skills on the scope item
- Level of maturity of the existing process/system/data for the scope item
- Magnitude of the planned change
- Issues or risks present in the scope item today
- Other planned or ongoing changes affecting the scope item
- Risk to business as usual modifying the scope item
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:
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:
- Common language (i.e. one chart of accounts, one customer hierarchy)
- Working capital improvements
- Operational efficiencies
- Control improvements
- Improved decision support
We can see that our scope activities do align to different objectives.
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.
- High level timelines are often set by senior management based on the business cycle or financial goals. Project managers often have to 'fit' work into the defined window
- Project managers may not know how to properly estimate effort and create plans
- Even if project managers follow correct planning processes organisations may not have the right experts to make realistic estimates
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:
- Identify the gap between the desired timeline and the theoretical timeline
- Identify the 'critical path'. This is the chain of activities that represent the shortest path from the start to the end. To shorten the project we need to change one or more of these.
- Identify which activities take a lot of resources (effort, time etc.)
- Identify which activities fall in difficult periods (such as holidays)
- Identify parallel activities that rely on the same resources
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:
- The last time we did ERP it took 12 months, so let’s assume 10 months
- Our software vendor / system integration vendor suggests 10 months
- We need to go live by July 1st next year and it is now August, so we have around 10 months
- Each phase will take around 2 months and there are five phases so let’s say 10 months.
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
- S/4HANA
- Finance
- General ledger
- Master data - accounts
- Processes design - month end
- Configuration
- Roles
- Accounts payable
- Master data – business partners/vendors
- Process design – Invoice with three way match, invoice w/out three way match, reporting
- Configuration
- Roles
- General ledger
- Finance
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’
- Requirements analysis
- Review accounting policy
- Analyse historical account usage
- Extract existing chart of accounts
- Understand reporting requirements
- Understand downstream systems requirements (reporting interfaces)
- Design
- Classify accounts ‘no longer needed’, ‘needed’, ‘to be modified’ etc.
- Draft new chart of accounts
- Update accounting policy
- Map new CoA to reporting requirements
- Map new CoA to downstream system requirements
At this point, we start to have a basis for estimation.
Estimation for detailed plans
Common methods to estimate include
- Use expert judgement. For example an experienced accountant can estimate how long it would take to review a set of accounts
- Use an analogy, typically by comparing with another similar project
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
- Is it a new process/system etc. for the organisation
- How experienced is the expert
- How complex is the topic, how wide ranging are opinions
- How clear is the target scope/requirement/design
- The bias of the expert
- The personal style of the expert ranging from aggressive to conservative
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:
- Request accounting policy from group finance: 1 day
- Individual reading/review to identify policy changes & additions: 2 days
- Workshop to review policy changes & additions: 1 day
- Time to follow up on any open items: 2 days
- Write up final requirements for policy changes & additions: 1 day
- Sign off requirements: 1 day
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
- Best-case
- Worst-case
- Most-likely
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:
- Best-case: 3 days
- Worst-case: 8 days
- Most-likely: 5 days
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
- Activity with planned start date and end date
- Planned effort
- This may be a compromise between theoretical weighted average and what the project start and end dates allowed)
- Actual effort
- Theoretical best case, worst case and average effort.
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
Example 2: text with tabulated activity status
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
- They don't factor into account the uneven distribution of effort over the course of a task. For example a 'workshop task' may include significant preparation and follow up work as well as the workshop itself. We can't really assume it should be 50% complete half way through the allotted time.
- As per my example individuals may manipulate % and RAG measures
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:
- A request for additional resources
- A scope change request
- Actions for senior management or stakeholders
- Communication of project information
- Assistance in aligning stakeholders, groups, individuals
- Or in the case of something newly off-track it could simply be a request for time to investigate
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:
- Early sharing of project information can help to upskill the broader organisations knowledge and help them prepare
- For very large projects a newsletter may help identify and connect some missing integration points within the team
- This may improve the communication and alignment of key contacts per scope items.
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:
- Not only estimated effort, but 'best case' and 'worst case' effort
- Task type 'research, design, workshop, co-ordination' etc.
- Task complexity 'low, medium, high'
- Link to objective/expected value
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:
- Actions required that involve the project team and senior managers to work together
- Interventions required from senior management
- Review and approval for change to any specification of the project
- Scope change
- Timing change
- Resources change
- Soft requests
- Requests for senior management to make communications (formal or informal)
- Need to know which could include new information that is likely to lead to one of the above in the future.
From the perspective of senior management:
- Status of planned objectives / value. Has any new information come to light that will lead to a change or delay in the value delivered
- Resource utilisation profile. Are we utilising planned resources and performance vs. budget.
Information that we can probably drop from status reporting includes:
- Progress and achievements. I realise it's good to celebrate progress, but progress delivered on time vs. plan should not take any of the valuable discussion time with senior management. There are alternate approaches for this. It can be included as a pre-read or appendix. Why not send a separate monthly 'achievements summary' separately to the whole team copying senior management, this may in fact be a better approach for motivation.
- Risks not realised After risks are identified and mitigation plans are put in place, there's no need to continue reviewing them unless one evolves into an issue.
- Issues. If an issue does not impact objective/value or timeline then it probably does not need to be discussed with senior management.
When drafting a status report I would do a sense check on the information included:
- Is this information related to a request for help?
- Is this information related to an important change to what was agreed?
- Is this new information that is 'need to know' in that it might lead to either of the above.
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.
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.
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
- The frequency can vary based on the project stage. In some stages there is less to discuss. For example we may have meetings every 2 weeks at the start of a phase, which move to every week as deadlines draw nearer
- On cross functional projects we may have multiple meetings between team members and senior management, for example
- Finance function leadership with project management and finance workstream: finance requirements and design status
- CIO, head architect and technology workstream: technology requirements and design status
- Cross functional steering committee, project management and workstream leads: overall program status
- Change management, HR and selected workstream leads: org and people impact status
- Project sponsor, project manager, admin assistant: budget review
Often large transformation projects suffer from meeting overload. A few things that can help:
- Replace some meetings with written reports. This works well for meetings that are mostly one-way communication. It may also be an option to simply record the presentation and send it out for people to watch when they have free time. Discussion points can be handled via e-mail, forums etc.
- Where meetings are required send pre-reads and shorten the meeting length
- Use '15 min' morning stand ups to review daily work & re-assess if planned meetings are required
- Use a web portal as a way to identify and reply to questions for the project team
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:
- A lack of business understanding of proposed elements of an IT solution and commonly why it is so complex, takes so long etc.
- A lack of IT appreciation of the importance of certain elements of a solution for the business
- An underestimation of data importance and data migration efforts from all functions
- Missing focus on specialised functions such as internal controls
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:
- Information senior management need projects to present regularly to enable them to make decisions or intervene where required. I have seen senior managers frustrated by off track projects being unable to communicate what they want the leadership to do to help them
- Likewise project teams should ask for clarification when they are unsure about the purpose for or prioritisation of work they are doing. This is especially true when competing projects get into conflicts over resources
- All functions have a responsibility to explain the rational behind their requirements, solution design and project status in a way that others understand
- This is particularly true for technical areas. Finance should be able to explain why a certain reporting approach is important. IT should be able to explain why a certain architecture or build architecture is important.
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
- What is the status of the expected value delivery?
- Show me the project activities as they relate to the objective and value
- An explanation of technical requirements, design or solution in plain english
Questions project teams should ask
- Keep me up to date on changes to the business strategy and how it may impact projects priority
- Explain other planned or in-flight projects and how they may impact the project
- The status of any senior management actions
- Budget requested
- Resources requested
- Phase end sign offs
- Other interventions requested e.g. alignment of stakeholders, functions etc.
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 on LinkedIn, X, or Facebook.