How to Health Check a Project
By: John Davidson
Tags: Program Management, Project Management, Leadership, Product Management

PROJECT MANAGEMENT

How to Health Check a Project

Photo by National Cancer Institute on Unsplash

Why run a health check on a project?

On a personal level, you first think about a healthcheck when things go wrong. You might then visit a doctor and then they run some diagnostics. If you’re lucky they send you away with some pills or a diet plan, but sometimes it’s more serious and you wish that you had gone much earlier.

The same happens with projects. Business leaders, sponsors, portfolio managers and PMs are often kicking themselves that they didn’t find problems sooner, but the reality is that, unlike medicine, you can perform your own project healthchecks. Here are some reasons why this is helpful:

You can pick up systemic issues that might negatively impact your project early enough that they can be dealt with;

You can identify areas you haven’t yet thought about, helping you to populate your backlog, your risk log and your planning;

When serious issues arise, you can quickly diagnose them and take corrective action; and

Even if there are no serious issues that arise, regularly asking these questions gives your stakeholders comfort that you’re in control.

If you are lucky enough to work in a global enterprise it’s likely that you will have people performing the role for you. If you’re one of those people, treat this as a cheat sheet of the kinds of questions you might get asked. If you’re not lucky enough to work in a large organisation then work with your team to ask yourselves the questions.

How should I run a health check on a project?

There are a few ways to do this. In order of simplicity:

Run a meeting, ask the questions and discuss the answers, making an action list as you go; Send a survey to project stakeholders via Microsoft Forms, Menti, Survey Monkey or another tool, then collate the feedback; or Hold several meetings with different stakeholders and then collate the answers and have a plenary meeting to discuss findings.

You can choose to score the answers in a number of ways. A Red, Amber, Green status works well, but you can also use a binary measure — OK, Not OK or just use free-form answers. What’s important is that you ask the questions, discuss the answers and take action.

What questions should a health check contain?

It turns out that projects and products often fail for one of three simple reasons:

Culture Routine Teamwork

However, just asking three questions doesn’t get to the point where you can take action, raise risks or identify blockers. So, here are 100 questions across ten dimensions to consider with supporting questions for each.

Clarity of Purpose

Essentially, this section asks whether you are aligned with your stakeholders on what you’re delivering, how you’re delivering it and why it’s important for them to put effort into your project.

Is your project’s purpose clearly articulated, in simple and easy to understand language so that stakeholders easily understand why you’re spending money? Is there a clearly articulated link between your organisational objectives and the objectives of your project? Is the impact (+ or — ) on customers, suppliers, partners, staff and other stakeholders clearly understood and explained? Is the $ value the project will bring clearly articulated and is there a clear pathway to achieving the benefit? Is the pathway to achieving the benefit of the project agreed with the people that need to make it happen? Is there a clearly articulated narrative that explains how, what and when the project will deliver? Is there a strong mandate for change in place, from a sufficiently senior level to create momentum?

Governance

In this section, we’re asking if the way you’re governing the project is appropriate relative to the risks, velocity and level of commitment needed by others.

Is there a clear sponsor for the project, with the right level of experience, decision-making authority and reach to make decisions when required? Can your sponsor describe the business case? Is there a Project Board* in place and does it meet regularly**? Does everyone on the Board understand their role, decision making powers and what success looks like? Are there any detractors on the Board and do you understand their concerns? Is the membership of the Board neccessary and sufficient to provide timely decision making and issue resolution? (i.e. is there anyone extra or missing?) Is the frequency of meetings regular enough to provide timely decision making and issue resolution? Is there a regular assurance process (like this one) to provide the Board with confidence that the project is being governed appropriately? Are decisions made recorded, logged and followed up on?

* Note that different organisations have different names for a Board, so use what works for you

** Note that some methodologies are not fans of meeting regularly, but in my experience, regular meetings sets a cadence that then drives decision making. Meeting ‘by exception’ is a valid approach, but not as effective.

Team

Are the right people working to make the project a success, with sufficient bandwidth to make a difference?

Is there a clear resourcing plan for the project? Are critical resources identified, with succession plans and backups in case of illness? Does the team (including the PM) have the necessary skills and capabilities to meet the needs of the project? This may include: domain expertise, business process knowledge, technology knowledge, cybersecurity knowledge, customer-facing knowledge, engineering knowledge, design knowledge and project control knowledge. Where there are gaps, is there a plan in place to develop the people, or to backfill them if necessary? Does everyone in the team have sufficient bandwidth to do what they’ve been asked to do, in addition to other projects or corporate commitments? If you use a PM tool, is your resource plan correctly added and have you in place the necessary processes to manage the team? Do all team members know your chosen ways of working, and are they using them? Depending on your organisation, this may include reporting, scrums, weekly meetings etc. Are all required resources from related teams in place, and committed? This may include legal, brand, product, marketing, finance, safety etc. Are all required resources from business teams in place, and committed? This may include teams that will receive your project to operate, such as a call centre, or manufacturing, or customer support etc. Is the project team set up for close co-ordination? Whilst co-location is the gold standard, it’s unlikely, particularly in organisations that work across time zones. If this is the case, are there sufficient overlap hours and regular meetings to ensure close teamworking? Have all team members been set to work, with clear objectives and sufficient empowerment to meet them? For staff members, are annual objectives and development plans aligned to what they have been asked to do?

Controls

Are the processes and procedures in place to manage the project on a day by day basis fit for purpose (not too robust, but not too loose)?

Is there a plan and is it up to date? Is the plan presented at an appropriate level of granularity? For stakeholders, it may be a ‘plan on a page’. For agile team members it may be a prioritised backlog, release plan and sprint plan. For engineers on a capital project it may be in the form of a probabilistic Gantt chart. Is the plan realistic from the perspectives of the teams performing the work, the teams inputting work or receiving outputs, operational teams that must take your output and run with it and other stakeholders? Is the plan realistic from the perspective of business capacity for change? Is there a robust process to manage risks, assumptions, issues and dependencies (RAID)*? Is there a strong budget management process, agreed with the sponsor and, if appropriate, the portfolio? Does the budget process identify under-spends and over-spends early enough to take corrective action? Is there a strong process in place to manage the team, including team members coming on board, leaving, moving roles, being promoted and emerging needs that changes the skills mix needed? Is there a strong process in place to manage continuous improvement & lessons learned? If your project has safety, controls, regulatory, legal or contractual implications, are these articulated and explicitly managed? Is the project approach agreed with all impacted stakeholders and is there a process to manage ‘continuous alignment’? Are internal gatekeepers involved in the project and is there a process to manage ‘continuous alignment’? Typical stakeholders include operations, architecture, brand, accessibility, communications, cybersecurity etc. Are obvious lessons from other projects embedded into your planning? Is there a clear and agreed level of reporting in place to keep stakeholders informed of progress that is appropriate and helpful, without being onerous either to produce or consume?

* RAID means different things to different teams. In my teams, Assumptions and Dependencies are articulated as Risks of them not happening, and Issues are expressed as backlog items, but in other teams different rules apply.

Stakeholders

How well are you aligning your stakeholder?

Are all key stakeholder identified and appropriately segmented? Do you understand what ‘success’ looks like for each segment? Is there a robust process for continuously engaging and monitoring each stakeholder segment? Is there a clear communications and engagement plan that is regularly reviewed according to evolving conditions? Is there evidence of disengagement and if so, is there a plan in place to remediate? Do you know your key stakeholders and do you have 1:1 plans for ensuring they are engaged and aligned? Are all key stakeholders committed to the project’s success and if not, is there a plan to gain commitment?

Business Impact

Is it clear what the wider impact on the business is of your project, and is that accounted for?

Is the impact of each deliverable on the business and, if appropriate, customers, partners or supplier clear (+ or — ) and agreed? Have you considered all channels of service delivery between the business and customers, suppliers or partners, and not just any that you are directly impacting? Are all interfaces & handoffs that will be impacted by your project clear and is the impact clearly articulated and agreed? Does the project understand key business crunch points (e.g. Christmas) that it must avoid when delivering outcomes? Are the impacts on key business resources understood and agreed upon? Are there upstream or downstream impacts on other customers, suppliers or partners that are less obvious, but which need to be accounted for? Is the impact of the project on the cost structure of the business understood and agreed? For example, does the business become accountable for a new ‘cloud usage variable cost’? Is there a plan in place to measure and extract the benefits you’re delivering? Is there an opportunity to ‘do more’ and ‘win more’ by extending the scope of the project? Is the impact on people, culture, processes and structures properly articulated and agreed by all impacted parties?

Customer Requirements

Does everyone know what we’re delivering and what ‘done’ means?

Are requirements clearly articulated and managed in a backlog? Is the backlog accessible and regularly reviewed by all key stakeholders? Is the process for managing emerging requirements robust? If there is a Product Owner, are they sufficiently empowered to be a single point of accountability? If they are not, then they are not a Product Owner. Is it clear who can say ‘yes’ to new requirements — and do they have budgetary authority to underwrite the requirement? Is it clear who can say ‘no’ to new requirements and designs — and have they been engaged early enough in the process? Are non-functional requirements clearly understood and taken into account? Are requirements subject to change and is there a clear process for managing these changes, both at a requirement level and a design level? Is there a clear and regular process for reprioritising requirements? Is it clear who needs to be involved in reprioritisation and are they engaged and aligned? Is it clear how requirements will be elaborated and finalised closer to when they need to be built and delivered? (this is especially important when in a rapidly changing or regulation-heavy domain) For each requirement, is there a clear definition of ‘done’, that all relevant stakeholders have agreed upon?

Technical Design

Is it clear that the project will work technically?

Is the overall technical solution agreed upon by all relevant stakeholders? This may be called a High Level Design, Architectural Approach, Cloud Architect Design or similar. This might be, for example, an agreement to use AWS vs Azure or Salesforce vs SAP, or to agree an architectural drawing if it’s a capital build*. Is there a clear and agreed process for agreeing technical designs at a detailed level as they emerge? Are important long term considerations, such as longevity, service level agreements (SLAs), maintainability, operations, security, information management, disaster recovery, complexity of handoffs between teams etc articulated and agreed? Are there sufficient skills and expertise in your organisation to deliver your chosen solution? Is there a clear process for continuous challenge and refinement to your design as the project progresses? Do all of your technical designs comply with corporate standards? When designing cross-country solutions, does your solution comply with in-country regulations?

Note

* I make no recommendation for any particular tool, and the cutaway drawings are just a bit of fun, but wonderful for showing the high level architecture of a tube station.

Contracts

Are you contracting with suppliers properly, in order to be able to deliver effectively?

Is there a clearly articulated procurement approach and is it agreed with the Board? Are all partners aligned with the approach and is it built into contracts? If you are running in an agile way, do contracts properly reflect the challenge of holding suppliers to account when requirements are allowed to change? If you are using a DevOps approach, do contracts properly reflect the risk and reward of ‘building and maintaining’? If you have different contractors for design and build, is there a clear handoff and dispute mechanism if the ‘design’ cannot be ‘built’? If you need to go to tender, have you taken into account how emerging requirements will be effectively dealt with both during the process and in the subsequent contract? Are procurement timelines sufficiently built into the plan, with sufficient contingency? Where you are using the services of internal suppliers (e.g. brand or legal) have you built sufficient lead times for the delivery of outputs from them? Where other projects are dependencies for you (inbound dependencies) are these clear and accounted for, with regular reviews in place? Where you are a dependency for other projects (outbound dependencies) are these clear and accounted for, with regular reviews in place? If you are dependent on any supplier, internal or external, are the risks, dispute resolution, decision making processes and exit criteria clear, documented and agreed? Is there an effective review process in place for all contracted parties, whether internal or external?

Change

How well have you planned for change?

Has a change impact assessment (CIA) been carried out on all impacted groups — internal and external? Is the CIA regularly reviewed? Is there a change and engage plan in place for each customer segment? Do you have measures in place for monitoring the quality of engagement with impacted groups, with robust mechanisms in place to address shortfalls? Are there sufficient engagements in place with impacted groups to allow you to ‘take their pulse’ regularly? Do all impacted groups know what will happen and when? Do all impacted groups understand what they have to do and are they committed to their actions? Are you measuring readiness for change, across multiple dimensions? These may include — solution design, support, processes, user training and commitment, regulatory approval etc. Is there a clear and up to date narrative for your project that stakeholders can access to understand the why, what, where, when, how, who of each delivery you’re making? Do you have strong, active change networks in place, to manage the changes you’re introducing through?

When should I run a healthcheck on a project?

The correct answer is ‘regularly’, but particularly at the following key points:

You’ve formed your team and you’re ready to start working in anger; You’ve been warned that you’re going to be audited; You’ve decided on your MVP, release 1 or other main release; You’ve onboarded suppliers; You’re mid-way through development; Your project leadership or board has a major change; When you’re about to ask for more money; You’re nearing a major deployment; You’re about to pivot; or Things aren’t going well.

Can I use this in my own projects?

Yes please do, but please link back to this story and if you improve on it, let me know too. I am very keen to hear about other indicators we should be looking at.

Can I use this for product management too?

Yes, absolutely. In many cases, the best way to create an MVP for a product is to run a project, to take advantage of the structure, process and controls that a project methodology offers, so the factors you need to consider will be very similar.