When I started out in project management I remember clearly being told that the lifecycle of a PMO was 7 years. It’s often seen as overhead, and certainly I’ve known organizations where the PMO team was caught in reshuffles and redundancies in a way that other teams were not.

At least, getting people to believe that the Project Management Office adds value is tricky until something goes wrong, and by then it's too late to build credibility and magic up a PMO when the company has underinvested in it from the start.

And if your PMO is only reporting management activity (like number of reports produced, meetings held) instead of outcomes (risk avoided, decisions accelerated, money saved), then we need to get you to a place where the value is obvious.

So, if that rings any bells for you, or you’re worried that communicating the value of your PMO isn’t landing with leadership as well as it should, this article is for you.

Don’t assume good work speaks for itself

A PMO has to sell its value continuously, the same way a marketing function does, rather than assuming good work speaks for itself. Project managers know this as well – if a project goes well, people ask, “Why did we need you? It was all fine.” And when it goes badly you get the blame!

Project work is hard to justify because so much of it seems nebulous. Regardless, that’s what we have to do in a PMO because we can’t trust that people will inherently know that the function is valuable.

Adopt an ‘internal marketing mindset’ like this:

• Know your audience (stakeholder engagement is key)
• Have a consistent message
• Repeat it in multiple formats
• Make it about them, not about the PMO (the ‘what’s in it for’ of the message, constantly).

That’s a lot like you would do for any project communication plan, so your team definitely already has the skills for this.

How do you measure PMO value?

But what does value look like? As a PMO leader, you might have success criteria for the function, but when you read KPI lists like ‘number of projects delivered successfully’ they don’t really say how YOUR team is supporting the work and what difference YOUR people are making. KPIs are not value, and that could be why your PMO is struggling to make a case for its existence.

Personally, I would like ‘value’ back to organizational goals, strategic objectives, company values and things like that. Value is what someone would miss if it disappeared.

If the PMO vanished tomorrow, what would people actually notice was gone?

For example:

• Executives would probably notice they'd lost visibility and early warning, and nicely formatted PowerPoint slides!
• Project managers might notice they'd lost support, or they might notice nothing at all (which tells you something too)
• Finance would notice forecasts got less reliable
• Team leaders wouldn’t have the information they need for resource management.
• Project portfolio managers wouldn’t have consolidated reporting or risks.

What else do people rely on you for?

If you’re struggling to work out what value looks like for you, it might help to break it down into different categories, like these ones below.

Delivery value

Did the work land, on time, on budget, to quality? Is everyone doing risk management consistently?

KPIs are how you would measure this, but from a PMO perspective, you aren’t actually in there delivering the work, that’s what project teams are doing. So your contribution is indirect and hard to quantify, because you support project management practices and standardization.

Get some feedback from delivery teams about how you supported, facilitating workshops, coaching etc etc, so you have narrative examples to provide.

Decision value

Did the organization make better or faster decisions because the PMO existed? Do you track time-to-decision? Ideally, you should be able to evidence that fewer decisions were made on incomplete information, and there is less time between "we need to decide" and "we decided." In my experience, senior management care quite a lot about this.

Risk avoided

Another difficult one to quantify because if a project didn’t fail because you identified a risk, there are no heroics to cheer about or delays to report on. If change management was handled well for the cross-functional teams, there are fewer problems with implementation. You can't KPI your way to counting things that didn't happen!

But your team’s dependency map or portfolio plan underpins all the ways that you’ve avoided these things.

Capability value

Is the organization better at delivering projects this year than last year? This, of course, relies on you having data from last year, which you might not have as a new PMO. Are standards actually being used, are people more confident, is there less reinventing the wheel project to project? Maybe do a survey and ask people how confident they are with the processes to evidence this?

Removing friction value

I don’t know how you quantify the human side of governance. What I’m talking about is the risk that your PMO hits all the KPIs and looks great on paper but the people you work with still experience the PMO as a pain in the proverbial.

Trust and friction are components of this. If you can build trust and remove friction, you’re winning! Overall, the value you add has to be more than the friction you add, otherwise your overall ‘value scale’ will tip to the wrong side.

Value over time

There's a time horizon problem that most PMOs face as well. How do you communicate something next month when the difference you are making is only going to show up in improved project management competence over the next year?  

Some value is immediate and visible (a report that saved someone two hours this week), some only shows up over quarters or years (an organization that's better at running projects than it was, project managers who have completed training or been through a mentoring program). PMOs that only claim the fast, visible stuff tend to get treated as an admin function, because that's all they're presenting evidence for.

I know I’ve given you a lot of problems in the topics above, but if you can spend a morning with the team, with some good coffee and away from the ping notifications of emails and chats, you can work out how you want to position yourselves. Then build a communication plan that works to highlight those things.

Building the story

We could call this a ‘value narrative’ if you want to be fancy about it, but really it’s simply making sure you know what your message is and how to present it to the people that matter.

Translate PMO activities into business outcomes: 'We standardized status reporting' becomes 'Leadership now gets an accurate view of portfolio risk two weeks earlier than before.' Another example: ’10 people completed project management software training’ becomes ‘team upskilled’.

Be clear about what services you offer and how those tie back to business value. Even in the early days of your PMO, when you’re all about setting things up, choosing project management frameworks and creating a template library, you can talk about standardization and efficiencies of scale.

Try to keep your message simple. Use a small number of proof points rather than an exhaustive list; you don’t need to keep telling everyone every little thing, but identify a couple of strong examples that help address pain points in the organization instead of multiple weaker examples.

And be careful about using jargon. What really is ‘value-based portfolio management’? Make sure people know what you are talking about!

Be evidence based. If you have a governance KPI library and a maturity/capability assessment, you can pull evidence from both of those. And benefits realization is another good one – when the project teams move on, you can track benefits for the duration, and report on those.

Create your PMO communication plan to get the message out, including feedback loops so you can make changes as necessary.

Overcoming resistance: 'we've always done it this way'

One of the big challenges with any new way of working – and the PMO has to overcome this – is the ‘we’ve always done it this way’ argument.

I think this objection is really about fear of change, added work or loss of control, not a real belief the old way was better. And I know from my own experience that when new enterprise project management tools are launched, there is a learning curve that makes it hard for people to embrace change with their whole being.

I would recommend that you start with a small, low-risk win rather than a full rollout for new PMO processes. Find and use an internal champion who already has credibility with the sceptics, and get them onboard for new ways of working. Let them talk about the value to their peers.

One of the processes I recommend regularly to mentees to start with is the project onboarding process – the activity to get a new project from ‘idea’ to ‘approved’. That can be messy and challenging, and streamlining it adds real value to the organization through:

• Better prioritization of human resources
• Better prioritization of financial resources
• Managing risk across a portfolio and not taking on too many high risk projects at once
• Managing expectations about what the team can actually achieve in this year/quarter.

Next, make the new way visibly easier, not just visibly 'better practice'. So streamline the guidance, give people templates, make the right fields mandatory, share the prioritized list, and so on. This makes value visible, as well as making life easy for the people engaging with the PMO processes.

Finally, remember that some resistance is legitimate feedback about a clunky process! It’s not all problems to be overcome, so be willing to adjust rather than dig in and mandate what clearly isn’t working.

The PMO cheat sheet

One of the best managers I ever worked for had a one-page diagram of what our department did and how we added value, that he carried around to most meetings with him. We worked in a global headquarters, and honestly, it was pretty difficult to articulate how the team added value to the countries we supported, especially as they all had their own local project teams and internal communications teams.

But his diagram made the nebulous simple: you could see what we did, how we contributed to the organization’s values and how what we did supported the work elsewhere. We underpinned a lot of things, and the behind-the-scenes work was valuable. And the diagram showed how.

You could do the same. Make a single page you can hand to a new sponsor, a sceptical director, or use to prep for a five-minute leadership update.

Include:

• What the PMO does in one sentence (your service catalogue and/or mission statement)
• Three headline outcomes this quarter (in business language, not process language, this is how you add value)
• Portfolio health at a glance using key metrics, pulled from your single-version-of-the-truth
• One risk or ask that needs executive attention (if that’s relevant to the meeting you are going into).

Choosing the right message for the right stakeholder

When you are talking to stakeholders about the value, or creating materials where you need to implicitly big up the work of your team, tailor your message to the people you are talking to. Senior leaders will want headlines, whereas a delivery team will want to know how you can practically help them through coaching, templates and so on.  

Also, consider that value is also relative to the audience, not absolute. People interpret value differently based on what they need from the PMO.

For example, an exec’s definition of PMO value (strategic alignment, confidence, no nasty surprises) is different from a project manager's (less admin, someone removing blockers) which is different from Finance's (forecasts they can trust).

Go back to your stakeholder list and make sure you have enough narrative to connect each of them to what they are getting from you – value isn’t just one thing, and only talking about the strategic alignment part means that you are missing out on showing your other stakeholders why they need you.

This article first appeared on Rebel's Guide to Project Management and can be read here: How to communicate the value of your PMO

Project governance is an important part of project management processes – even if it’s not the most exciting part of getting work done.

As a project manager, part of your role is shepherding the work through the project lifecycle. That means moving it on from idea to done and keeping it all on track as you go. Governance is a key part of that, and gate reviews are part of navigating through the project.

Gate reviews, or stage reviews are part of the PRINCE2® process, and also part of the UK Government's National Infrastructure and Service Transformation Authority (NISTA) Project assurance review toolkit. Decision gates are part of empowering decision-making and ensuring the right people make the call as to whether a project progresses (or is closed).

They don’t really make an appearance in the PMBOK® Guide, although obviously it’s good practice to use a structured method of moving between phases.

What is a gate review?

A gate review is a control point that acts as a go/no go decision point for the work. It’s a formal governance step which provides assurance on the project that the required processes and tasks have been completed, and that it is worth continuing with the project.

Unlike a normal project status meeting, the purpose of a gate review is to make a decision. The reviewers should be working from agreed criteria and evidence, rather than simply hearing a progress update. If nothing (or no one) could realistically cause the project to stop, pause or change course, it isn’t much of a gate.

It’s the point where all stakeholders reaffirm their commitment to the work and approve the project to be moved forward into the next stage of work.

The ‘gate’ is the boundary between one project stage and another. Stage gates are most strongly associated with predictive lifecycles, where stages have clear boundaries. Agile approaches have ceremonies, norms and processes for moving work on and securing approvals to continue, but you can also use decision gates in agile and hybrid environments.

The difference is that you are normally authorizing investment, release, readiness or continued delivery rather than approving completion of a traditional waterfall phase. The NISTA assurance framework, for example, includes specific guidance for applying assurance reviews to agile digital delivery including that you need agile people on the review team (phew!).

You might hear them called stage gates, decision gates, toll gates, phase gates, gateway reviews, or just gates. For simplicity, and because the UK government uses the terminology of gate review, that’s what I’m going with in this article.

5 Benefits of gate reviews

The benefit of a stage gate is to make sure that the right projects are being worked on. It confirms that in-flight projects are:

• Still aligned to organizational strategy
• On track to deliver the forecasted benefits
• Still required by the business
• Still due to complete with the allocated funding
• Following good governance processes with adequate oversight.

The gate process also has other benefits for everyone involved:

1. Shorter planning horizon

It’s hard to predict the future. When you plan in project phases, you gain the benefit of only needing to do detailed plans for the next stage.

2. Risk management

Project risk can be re-evaluated, and that can provide useful information for the program or portfolio team. Risk levels input into the decision about whether the project should continue, and given that some teams are not as on top of project risk management as they should be, it serves as a handy reminder to focus on risks.

3. Stakeholder engagement

Getting people together to talk about the project is a way of reaffirming commitment, making sure they are still involved in the ways they want to be and keeping lines of communication open.

4. Expectation management

It serves as another point to reiterate what the project will do. For the project team, that’s a good way of identifying potential sources of conflict and making sure that everyone is on the same page. For example, highlighting if there is additional work required.

5. Increased confidence in delivery

I feel that the main benefit of gate reviews – having been involved in some in my time as a project manager – is that it increases everyone’s confidence that the project is going to be delivered successfully. As part of the project control processes, gate reviews should lead to a higher likelihood of project success.

The fact that there is some oversight and governance, plus project teams being held accountable for the delivery, seems to help structure projects and put some rigour around delivery. It makes phase transitions easier.

The stage gate process explained

Let’s say you work in a predictive environment and you have a defined project lifecycle with key decision points. There are gate reviews to jump through in order to keep your project moving, and your project sponsor very much wants that to happen. No one wants bureaucracy to slow their project down.

If your project is facing a gate review, then it’s highly likely you will also have a set of documents or expectations to complete in order to kick off the process and move the work on to the next stage.

The key here is the stages. You need to know what stages make up your project lifecycle. The gates open the door to each new stage.

The project lifecycle and stages

PRINCE2® requires at least two management stages: one to initiate the project and then however many you need after that to do the rest of the work. Your lifecycle might look a bit different.

The phases of a typical predictive lifecycle are:

1. Idea or concept phase
2. Initiate
3. Plan
4. Execute
5. Close

You might call them different things (some of our projects have a development phase, for example).

Gates allow you to transition between stages in a controlled way. In the diagram below, you can see that there’s a stage gate required to move to each new phase of the project.

You might not need project gates to move between each stage. For example, on large projects, you would expect a certain amount of governance and rigor, especially considering the amount of money tied up in the work.

NISTA has the following gateway review stages, aligned to the requirements for larger, government-backed projects:

• Gate 0: Strategic Assessment
• Gate 1: Business Justification
• Gate 2: Delivery Strategy
• Gate 3: Investment Decision
• Gate 4: Readiness for Service
• Gate 5: Operations Review and Benefits Realisation.

But for smaller projects, you wouldn’t necessarily benefit from introducing gates for every point – it would feel like you’re in review meetings all the time.

As an example of a gate review process in action, for one of the projects I am running at the time I’m writing this, we have a governance point after the Business Case phase. That basically approves the business case and allows the team to move into kick off and planning. Then we don’t have another review point until we’re about to close.

Essentially, our gate process only requires approval to get the funding, commitment, resources etc, and after that the team can run with it. Obviously there are regular project board meetings and other governance checks, but the practical implication is that we have freedom of action for low value initiatives that are low risk and things we’ve done before.

So you can see that you can have different processes for different types of projects, as you see fit. The PMO will specify the route your project has to follow.

What are gate review criteria?

A useful gate should have criteria agreed before the meeting. Otherwise, the decision risks becoming subjective.

Entry criteria tell you whether the project is ready to come to the gate. For example, the business case has been completed, the latest forecast is available and significant risks have owners.

Exit criteria define what needs to be true before the project can progress. For example, funding is approved (or will be approved), resources are committed and the sponsor accepts the residual risks.

If the entry criteria are not met, consider postponing the review rather than holding a meeting simply to agree that the project isn’t ready.

Let’s look at what it looks like to prepare for a stage boundary (to use a PRINCE2® term) and take your project through the process.

Who attends a gate review?

The project manager normally prepares the evidence, so while you might attend, decision-making, as is normal at this level of approval in project management, sits above you. Depending on your governance structure, the decision-maker might be the sponsor, project board, portfolio board, investment committee or a PMO governance group.

• The project manager provides evidence/recommendation
• The sponsor owns the business justification
• The governance body makes or ratifies the decision.

Subject matter experts can attend to answer questions, but keep the decision-making group small enough to actually make a decision. In my experience, the PMO team will book the meeting and invite who they want, so you might be asked to advise on attendees but the invite will come from someone else's calendar.

Example stage gate process

Each organization may implement a slightly different take on the stage gate approval process depending on your internal best practices. If you are new to the idea or thinking about implementing one for your PMO, here is an example so you can see how it works.

This is a sample gate process that could be followed at every gate point.

Step 1: Create decision-led documentation

The stage gate process is effectively a governance process, so that includes paperwork! The project manager will draft the necessary papers. These include the evidence the decision-makers to approve/deny the project passing through the gate, such as:

• A summary of progress to date
• A summary of expected progress/actions for the next stage
• The financial calculations required to back up any requests for funding for the next phase.

The evidence should answer the 'exam question' that the gate is testing, and some examples are in the table below.

In other words, the project manager is asking for approval to continue with the project and asking for approval for the budget and resources to be made available.

The PMO will normally have a gate review template or checklist for this, whether that is a document or slide deck or some other format. Ideally, each project being taken through the stage gate process will use the same template for standardization. NISTA's Gate 1, for example, includes a lot of evidence and questions around business case and strategic fit, as you'd expect from a project asking for approval to move into delivery.

You should also make sure that the rest of your project management documentation is up-to-date including:

• Project plan
• Business case
• Change requests that relate to the stage you have just finished
• Risk log
• Issue log
• Quality register.

Check what specific criteria are required to get the gate decision you want, which is normally, to ‘pass through the gate’.

Step 2: First document approval

The project manager shares the documentation with the rest of the project team, the project sponsor and any other key stakeholders who might have a say.

This is what you would normally do with project documents that are being sent up the chain for approval. No project sponsor wants to see a deck presented for the first time during a big meeting, and they want to know what is being said about their project (and, of course, it’s their project so they have a right to know!).

Step 3: Second document approval

Next, your internal authorization process kicks in. For example, this step could be that your project board or steering group formally confirms that the work has been completed as documented in the gate review papers.

This check ensures that the project doesn’t reach the gate review process too early – before the project has finished all the tasks from the last stage.

Step 4: Final decision

With confirmation of project progress and approved gate review documentation in hand, the project can go to whatever final, formal governance body will make the decision to move the project into the next stage. Or not, depending on the situation.

• This group could be:
• The PMO or Portfolio office
• A business strategy team
• An internal senior leadership forum supported by additional approvers
• Or any other group set up for the purpose.

This group will probably meet regularly to discuss several projects at once. They are not a project-specific group, but a forum that oversees project governance across the organization.

Step 5: Decision enacted

Finally, the project team acts on the decision that has been taken.

The outcomes from a gate review are:

• Go: The project proceeds to the next stage or phase
• Go with conditions: The project proceeds but is bound to complete certain actions or meet conditions e.g. approved but contingency funding line is stripped from the budget and the team must submit new forecast figures without the contingency (real example!)
• Hold/Return for review: The project is delayed or put on hold until some specified criteria are met e.g. a new schedule being produced, input gathered from another stakeholder etc, when it returns to the forum to try again. This could also include the project is changed in some way to better fit business needs or available funds e.g. scope items are removed or added.
• Stop: The project is moved to a premature close and effectively cancelled.

That may mean carrying on, raising purchase orders for the next set of spending, reviewing or redoing work if necessary before coming back to try to get through the gate again, or trying to salvage what you can before you close the project.

Ultimately, the point of the gate review in project management is to provide assurance that the project can and should continue to the next stage. If it is not clear that it should, this is the point to have conversations about what can be done to rescue the project or to close it.

What to cover in a gate review meeting

A stage gate review meeting can be quick and informal or a more formal process, depending on what is being approved and the level of governance required.

For a small, relatively easy project, the meeting might involve a short presentation from the project manager that confirms the latest project status, budget position, risks and timeline. The governance board can then approve that the work continues.

A more formal meeting might require more papers produced in advance. It might have to discuss changes to scope, time or budget and what impact that has on the viability of the project. More people may need to contribute to the conversation or provide approval, depending on which areas of the organization are affected by the change.

Either way, the gate review meeting should provide confirmation that:

• Continuing the project is the right thing to do
• The project is being run in the ‘right’ way (whatever that looks like for you)
• Resources are still available and committed (at least for the next stage)
• The organization is ready for the project to move to the next stage
• If things have changed, the review committee is happy that those impacts have been adequately considered.

How to implement the gate review process

So, you want to implement this approach within your PMO? Get the PMO leaders together and agree on your expectations and what project teams need to do.

Then, communicate it.

Honestly, it’s not difficult to put together a simple process and a checklist of things you want to see in order to release the project into the next phase. The hard part is in changing the culture of the organization to want to work this way, but as someone skilled in change management, you’ll find a way.

When gate reviews don't work (advice for PMOs!)

A gate adds little value if the decision has effectively been made before the meeting. If every project passes every gate, regardless of the evidence, you've created an administration checkpoint rather than a governance control.

Equally, don't turn a gate into a document-completeness exercise. The question isn't, “Have we filled in every template?” It is “Do we have enough evidence to make a sensible decision about continued investment?”

Your next steps

In this article, you’ve learned about what a gate review is, why we’d use it, how it fits into the project lifecycle, and how to get your project through the gate.

Things to do now:

• Read about why your project board isn’t working.
• Talk to your team about your internal gate process so you understand the specifics of how it works in your organization.
• Read the NISTA guidance on governance or check out what PRINCE2® has to say about managing stage boundaries.

This article first appeared on Rebel's Guide to Project Management and can be read here: Gate reviews: What to do and why you need them

Name: DHTMLX Gantt

Vendor: DHTMLX

Hosting options: Needs to be self-hosted; designed to be embedded in an existing application

Cost and plans: Free 30 day trial so you can test it in your app. Perpetual licences start at $799 (individual, includes 1 year of updates/support) and scale up, and there are cost-efficient bundles that loop in other JS products.

Languages: 50+ languages and you can add your own translations too. Interestingly, they have several versions of many languages (e.g. Portuguese – Portugal/Portuguese – Brazil) but not English UK and English US, just “English”.

A tool for your tools

The important thing to know is that DHTMLX Gantt is not a standalone project management app, but a developer component. You use it to add Gantt functionality into custom software, whether you are building a product to sell or creating your own tool for internal PM use. It’s the component that powers GanttPro and plenty of other tools.

Alongside DHTMLX Gantt, the company offers a range of other Javascript components including a scheduler, Kanban board, and an interactive To Do list widget.

What DHTMLX Gantt offers you

DHTMLX Gantt combines a configurable task grid with an interactive timeline, giving you a detailed view of project structure, schedules, and dependencies in one interface. You can organize tasks and milestones, create and edit dependencies directly on the chart, and visualize how changes to one task affect the rest of the schedule.

For more complex project planning, DHTMLX Gantt also supports critical path calculation, resource management, working calendars, constraints, and custom scheduling rules. These capabilities make it suitable not only for displaying a project timeline, but also for building full-featured planning and scheduling workflows.

Strengths of DHTMLX Gantt

In my experience, many companies end up building their own project management software in-house because off-the-shelf products don’t really give them what they want.

If that feels like where your PMO is right now, then DHTMLX Gantt is a configurable JavaScript Gantt chart, you can drop into your builds.

Proper Gantt chart features

This isn’t just a timeline. You get all the Gantt chart features that project managers actually need to schedule effectively. The core scheduling logic that powers the advanced PRO features such as auto-scheduling, critical path calculation, and constraints, means your schedules are realistic and help you keep everything on track.

Usability

The product feels very usable. I love the Zoom-to-fit feature and the option to collapse rows. So often we have to share Gantt charts with executive teams and they don’t want to see 500 lines. This gives you the option to screenshot a consolidated version that will fit on a slide for your exec reporting.

There is also specific guidance on making the Gantt chart responsive, essential for looking at your plans on small screens.

It offers smart rendering and dynamic loading for large datasets, so it works brilliantly for construction, manufacturing and other environments where you have a lot of tasks to manage.

The task tooltip is fully customizable, so developers can adjust its content, appearance, and positioning to fit the application’s interface and avoid overlapping with other elements during task editing.

Configurable

The Gantt chart is highly configurable which is great if you want your team’s plans to come out in brand colors, or make other tweaks to make it fit within the context of the app you are using it in.

Add the columns you want where you want them. You can even switch to Right to Left mode to support languages that are read that way!

The customization options give you a lot of control over how the Gantt chart appears and behaves, the task grid, timeline, templates, pop up tooltips, and other UI elements to tailor it to your users.

Accessibility

DHTMLX Gantt includes built-in accessibility features for applications where keyboard and assistive technology support is important. It supports WAI-ARIA attributes for screen readers and provides keyboard navigation for tasks, grid rows, and cells.

Keyboard navigation can be enabled through the dedicated plugin, with a set of ready-to-use shortcuts for common actions such as navigating between tasks, creating and deleting tasks, opening the task editor, and expanding or collapsing the task tree. Developers can also define custom keyboard shortcuts to better match the accessibility requirements of their application.

Frontend framework integrations

DHTMLX Gantt works with popular frontend frameworks, including React, Angular, Vue, and Svelte, so you can integrate it into your existing technology stack without changing your application architecture.

AI-assisted development

DHTMLX also supports AI-assisted development. The DHTMLX MCP Server gives AI coding assistants access to up-to-date documentation and API references, while Agent Skills provide framework-specific integration patterns and help tools like Claude Code, Cursor, and Codex generate more accurate Gantt code.

Exporting

DHTMLX Gantt supports export to multiple formats, including PDF, PNG, Excel, iCal, MS Project, and Primavera P6. You can also import project data from MS Project and Primavera P6, making it easier to migrate from existing project management tools or exchange data between systems – which you often need to do when working with suppliers who use different tools.

Free community edition of DHTMLX Gantt

Another thing I love about this product is that they have a free Community edition, with an MIT licence. It comes with 7 predefined skins, or you can use custom CSS to bespoke it.

The Community edition is missing some of the PRO features like resource management, but it’s still plenty to get your app up and running. You can test it out without having to commit to a paid licence.

The verdict

DHTMLX Gantt is a powerful and flexible option if you need to add Gantt chart and scheduling capabilities to a web application. Its extensive customization options, range of features and support for integrations with tools such as Microsoft Project and Primavera P6 make it a good choice for organizations that want to build something tailored to their own processes.

It’s worth being clear (again) that this is a developer-focused product rather than an off-the-shelf project management tool, so you’ll need development expertise to get the most from it. Get your requirements straight before diving into the licensing structure, so you can get the best bundle for your needs, or check out the free Community edition before committing.

Overall, if you’re looking to build a bespoke project planning or scheduling application rather than buy a ready-made PM tool, DHTMLX Gantt is well worth investigating. It offers a strong combination of functionality and flexibility, with enough scope to create something that fits your organisation rather than forcing your processes into someone else’s software.

This article first appeared on Rebel's Guide to Project Management and can be read here: Software review: DHTMLX Gantt

Project managers make decisions all day. We decide how to structure the work, who needs to be in a meeting, what needs escalating and whether a risk response is worth the effort. But the bigger the decision, the less likely it is to be ours to make.

At some point, the choice belongs to the sponsor, project board or another senior leader. That’s where a different project management skill becomes important: helping the person with the authority make a good decision, at the right time, with enough information to understand the consequences.

That is not the same as learning another decision-making technique. If you want the mechanics of working through a choice, start with my guide to project decision-making. Here, I want to focus on the project manager’s role in executive decision support: turning delivery detail into something senior leaders can actually act on.

Know which decisions are actually yours

One sign of an experienced project manager is that they don’t escalate everything. Senior leaders do not need to approve every change in meeting dates, every small spend decision or every adjustment to the plan. If you have delegated authority to deal with something, deal with it.

Equally, do not quietly make a decision that sits outside your authority simply because getting time with the sponsor is difficult. I have seen both extremes: project managers who ask permission for everything, and project managers who carry on making increasingly significant calls because “someone had to decide”. Neither is particularly helpful, and both can get you into trouble.

Get clear on decision rights early. Your governance arrangements should tell you what can be decided within the project team, what belongs with the sponsor (or steering) and what needs wider executive approval, through investment committees, the PMO, change boards and so on. Tolerances, delegated financial authority, terms of reference, and escalation thresholds all help.

The practical test I use is: does this decision materially change the business case, benefits, risk exposure, strategic intent, budget, timeline or operating model? If yes, it probably needs to go upwards. If not, you may be able to make the call and keep the project moving.

Translate project information into business consequences

Project teams live in detail. We know which test script failed, which supplier is late, how many tasks have moved and why the integration environment is unavailable. Senior leaders rarely need all of that information.

They need to know what the detail means.

For example:

• Project information: “Testing is two weeks late.”
• Decision-support information: “If testing moves beyond 30 September, we lose the only implementation window before peak trading. We can add testing capacity now, reduce scope, or move the launch to January.”

The second version gives the decision-maker a consequence and a choice. It connects delivery performance to something the business cares about.

This is why business acumen matters for project managers (it’s specifically called out as a PMI Power Skill). It's still a development area for many project professionals. PMI’s 2025 Pulse of the Profession found that only 18% of project professionals demonstrated high business acumen, and those with stronger business acumen were more likely to meet business goals, schedules and budgets.

You need enough understanding of the business case, benefits, operating model and strategic priorities to explain why a project issue matters outside the project team. A red milestone is not inherently interesting, although I know many execs will want to go straight to that, so they can fix it. It’s the effect of that red milestone on revenue, compliance, customer experience, capacity or another strategic objective that they should be caring about.

Bring a recommendation, not just a problem

There are times when the right thing to say is, “I don’t know yet.” But there are many more occasions where the project manager can do (at least some of) the analysis before asking the sponsor to choose.

Instead of taking a problem to the project board and asking, “What do you want to do?”, prepare the decision so the group can spend its time making the choice rather than discovering the issue from scratch.

A useful decision brief includes:

• the decision that is required
• your recommendation
• the realistic alternatives
• the main trade-offs
• the evidence behind the recommendation
• what happens if no decision is made
• the date by which you need the decision.

That does not mean pretending there is only one sensible answer. Your recommendation may be based on delivery considerations while the sponsor has access to commercial, political or strategic information that changes the picture. Your job is to make your reasoning visible so they can challenge it.

Being able to make a recommendation is not only a project management skill. The World Economic Forum’s Future of Jobs Report 2025 found that analytical thinking remains the most sought-after core skill, identified by 69% of employers, while leadership and social influence was cited by 61%.

It is also worth separating solving the underlying issue from choosing what to do next. I have written separately about the difference between problem solving and decision making. They are related, but they’re not the same activity.

Build enough business acumen to understand the trade-offs

You don’t have to become a finance director to support executive decisions. However, it helps enormously if you understand the language behind the trade-offs you are presenting.

Depending on your environment, that could mean understanding:

• Opportunity cost: what else cannot happen if resources stay on this project
• Cost of delay: what waiting another month actually costs the organization
• Benefits and value: what outcome the project is meant to create, not simply what it is delivering
• Total cost: including ongoing support, licences, maintenance, training and operational effort
• Strategic fit: whether the initiative still supports the priorities the organization has today, not only the priorities it had when the business case was approved.

Most project managers build this knowledge through experience: sitting in governance meetings, working with Finance, talking to sponsors and seeing what happens after a project goes live. Mentoring and cross-functional work help too.

Formal study is another route if you want a broader grounding in finance, strategy and leadership. For example, a Master of Business Administration online can provide a structured way to learn how the different parts of an organization fit together.

You don’t need an MBA to become a strategic project manager, but you do need to understand enough about the business to recognize what makes a trade-off important.

Be explicit about uncertainty

Executive decisions are often difficult because the information is incomplete. If the answer were obvious and the data perfect, the decision probably would not need much senior attention.

One of the most useful things you can do is separate what you know from what you think is likely to happen. Label the information clearly.

• Facts: things already evidenced or agreed.
• Estimates: numbers based on known inputs and an estimating approach.
• Assumptions: things you are treating as true for planning purposes.
• Forecasts: your current view of what is likely to happen.
• Unknowns: information you do not yet have and may not be able to get before the decision is required.

Avoid false precision

I would much rather tell a sponsor that the cost is likely to be between £180,000 and £230,000 than present £204,738 as if we have somehow achieved perfect certainty. False precision does not make a recommendation more credible!
Although I also remember being told as a young project manager that not submitting a round number made it look like we’d worked out the budget forecast somehow, instead of just guessing, which is what we were basically doing.

How you present the information matters too. The same facts can feel very different depending on whether you emphasize the potential gain, the potential loss, the short-term impact or the long-term consequence. My article on the impact of framing in decision making goes into that in more detail.

And if you are wondering why capable people still make poor choices when they have plenty of information, there are some common traps. I cover three of them in 3 things that stop you making the right decision.

Match the decision process to the decision

Not every decision needs a workshop, thankfully. Not every decision should be made by one senior person either.

Think about what kind of input will give you the right data for the decision. A technical architecture decision may need specialist advice. A change to a frontline process probably needs input from the people who will use it. A time-critical incident may need one person to decide quickly so everyone else can get back to work.

If a collaborative approach is appropriate, I have a practical guide to helping teams make group decisions. There are also situations where autocratic decision-making is the no brainer choice: someone has the authority, the decision is time-sensitive and wider consultation will not materially improve the outcome.

You can also reduce the stakes by avoiding one giant, irreversible decision. On uncertain projects it may be possible to approve a pilot, fund the next tranche or test an assumption before committing further. That is close to the incremental model of decision-making: moving forward in smaller steps as more information becomes available.

Manage the decision pipeline, not just individual decisions

A project can have perfectly good governance and still grind to a halt because decisions are sitting with busy people – this is decision latency, the slowness of decision-making.

One outstanding decision may not be a problem. Five decisions, each dependent on the one before it, quickly become a delivery issue. I think of this as decision debt: unresolved choices accumulate until the team is spending more time working around them than moving the project forward.

Manage significant decisions as actively as you manage risks and actions. For example:

• Keep a visible list of decisions waiting for action
• Give each decision an owner and required-by date
• Show the impact of missing that date
• Pre-circulate and socialize major decisions with key stakeholders before the formal meeting
• Make the decision ask obvious in papers and presentations
• Escalate an impending decision delay before it becomes a schedule delay.

And please do not hide the decision on slide 17 of a 30-slide project board pack. If you need the group to choose something, say so at the beginning, because who is going to read to slide 30?

A clear heading such as “Decision required: approve Option B by Friday” is far more useful than hoping everyone spots the ask in the discussion. Pop it in the exec summary right at the front.

Close the loop after the decision

The meeting finishes, everyone closes their laptops and the conversation moves on. That is exactly the point where a decision can disappear.

Confirm what was agreed, especially if the discussion moved away from the options originally presented. I worked with a sponsor who was incredibly good at this. He would summarize the actions and decisions in the last 5 minutes of the meeting, even though I had been taking the minutes. He must have had his own notes because the meetings could get a bit rambly.

Then turn the decision into delivery: update the schedule, budget, risks, scope or communications as required.

For decisions that matter, record the rationale as well as the answer. Six months later, “We chose supplier B” is much less useful than “We chose supplier B because they were the only bidder able to meet the regulatory deadline, despite the higher cost.” A project decision log gives you a simple structure for keeping that history.

Five habits that make your advice easier to act on

If you want senior stakeholders to see you as someone who helps them make decisions rather than someone who simply reports project status, these are the habits I would focus on.

1. Lead with the decision required. Do not make people listen to ten minutes of background before they understand why you are in the room.
2. State your recommendation. You are allowed to have a professional view, even when someone else owns the final choice.
3. Quantify what matters, but do not invent precision. Use ranges, assumptions and confidence levels where that is a more honest presentation of where you are now.
4. Say the uncomfortable trade-off. If saving three weeks means accepting more operational risk, say so plainly.
5. Say when you need the answer. A decision without a required-by date has a habit of becoming tomorrow’s problem!

For more ideas on strengthening your own everyday judgement, see my 5 tips for making better decisions every day.

Make yourself useful at the decision point

Becoming more strategic as a project manager is not about pretending to be a senior executive. It is about understanding the business well enough to recognize what matters, applying project judgement to the evidence and making the consequences of each choice clear.

That means doing the analysis before the governance meeting, knowing where your authority ends, presenting uncertainty honestly and making it easy for the right person to choose.

Do that consistently and you stop being the person who turns up with a status report and a list of problems. You become the person whose advice helps senior leaders decide what happens next.

This article first appeared on Rebel's Guide to Project Management and can be read here: 8 Ways for project managers to support better exec decisions

There are multiple stakeholders, different views on how things should be done, different channels to use, and no one has the time to do anything any longer.

I believe that project managers have had to move into the space that used to be filled by internal communications or change managers.

Those roles still exist and support large projects, but many smaller or internal projects don’t get that support, so as project managers, we step in to fill the gap.

That’s what I’m researching at the moment, and I’d love to hear how it is for you, communicating your project. The short survey below will let you tell me what challenges you face. Skip any questions you don’t want to answer, and add as much detail as you like where you have more to say!

I appreciate any and all answers, and at the end, there is a project communications health check spreadsheet you can download, plus a worked example so you can see how to use it to assess the comms maturity on your project. You don’t even need to leave your email address, but if you do, I’ll send you the survey results when they are available.

Thanks in advance! (And please share with your teams!)

This article first appeared on Rebel's Guide to Project Management and can be read here: Project Communications: Take the Survey