On Time, On Budget, and Still a Failure

Let me start with the practical part. On a small or medium project, one person can run the delivery and own the requirements without dropping either. On a large or complex one, that stops being realistic.

At SYNERGEN Health our solutions team grew past 70 people, and some client implementations had budgets of over a million US dollars. At that scale you need people whose full-time job is to sit with end users, map processes and write requirements. You also need people whose full-time job is schedule, budget, risk and resourcing. Sometimes you need several of each.

So I’m not saying every project should have one person wearing both hats. Splitting the duties is often the right call. What I am saying is that the two disciplines can’t be separated in purpose. You can give them to different people, but if those people aren’t working towards the same thing, the project will struggle no matter how good each of them is.

Even PMI, the body behind the PMBOK Guide, treats the two as partners rather than one role swallowing the other. Its practice guide on business analysis sets out collaboration points between the project manager and the business analyst across the whole life cycle, from planning to identifying stakeholders to implementation[1]. What it doesn’t really deal with is the person who does both jobs at once[2]. That happens to be the situation I’ve been in for most of my career.

Most projects get called successful when they go live, or when they finish within schedule and budget. I don’t think that’s enough. Every project is started for a reason. Someone expected it to deliver some value, and that value is the real measure of success.

PMI now says the same thing. In 2024 it published a new definition of project success: a successful project delivers value that is worth the effort and expense[3]. Measured that way, its research found that only 48% of projects were seen as successful, 40% sat in a grey area and 12% failed outright[3]. The PMBOK Guide Eighth Edition, released in late 2025, carries the idea into its principles. “Focus on value” is one of the six core principles it sets out for how projects should be led[4].

Take a simple example. Say an organisation implements a new system expecting it to save the work of 10 people every month. If each of those people costs $5,000 a month, the business case is a saving of $50,000 a month.

Now imagine the system goes live on the planned date and comes in under budget. Everyone celebrates. Six months later the team is still the same size, people are running the old spreadsheets alongside the new system, and the saving is nowhere to be seen.

Was that project successful? I’d say no. If it isn’t at least heading towards that $50,000 a month, or something better, then the project has failed, whatever the status report said on go-live day.

This isn’t a rare problem. McKinsey and the University of Oxford studied more than 5,400 IT projects and found that large ones ran 45% over budget and 7% over time on average, while delivering 56% less value than predicted[5]. Look at those numbers again. The value gap is bigger than the budget gap, yet budget is what most status reports track.

This is where business analysis comes in. Understanding why the project exists, what problem it solves and what return it’s meant to bring is core BA work. Without it, the team is building towards a date instead of an outcome.

The BABOK Guide puts value right at the centre of the discipline. IIBA describes business analysis as enabling change in an organisation by defining needs and recommending solutions that deliver value to stakeholders. Value is also one of its six core concepts, alongside change, need, solution, stakeholder and context[6].

PMI’s own research shows what happens when this part is weak. Its Pulse of the Profession study on requirements found that when projects miss their original goals, poor requirements management is the main cause 47% of the time[7].

None of this makes schedule and budget unimportant. A project that delivers the right value two years late and at three times the cost has its own problems. Getting delivery right is what good project management practice is for.

Where I differ from a lot of what I read online is in what “good practice” means. I don’t believe you can pick Agile or Waterfall at the start and expect it to carry you through. I’ve tried doing exactly that, and I’ve watched others do it too.

What works is situational. A regulated healthcare integration with fixed contractual milestones needs a different rhythm from an early-stage product that is still finding its market. Quite often one project needs a bit of both, with firm governance on the outside and iterative delivery on the inside.

The standards have caught up with this too. The PMBOK Guide used to be read as a rulebook of processes. The Eighth Edition keeps the principles and performance domains from the Seventh, and presents inputs, outputs, tools and techniques as non-prescriptive items that apply across different approaches[4][8]. In plain terms, PMI is telling project managers to pick what fits the work instead of following one method end to end.

A project manager who has seen these methods applied in practice, and seen where they break, can work out how things should be run for that team, that client and that piece of work. That judgement is worth more than any framework label.

When the project manager also understands the business analysis side, a few things change.

PMI looked at this directly in its 2025 Pulse of the Profession report. It found that project professionals with high business acumen consistently get better results, but only 18% of project professionals actually show that level of business acumen[9]. Most PMs are good at running the work. Far fewer are confident linking it to how the business makes or saves money. That’s the gap a BA mindset fills.

The team always knows why they’re doing the work. Developers, testers and stakeholders make dozens of small decisions every week. When they understand the purpose, those decisions tend to point the same way. When they don’t, you get features that technically meet the requirement but miss the point.

Trade-offs get easier, and better. When scope has to be cut to protect a date, a PM who understands the business value can tell which features carry the return and which ones are nice to have. Without that, cuts get made on effort alone, and sometimes the thing that gets dropped is the very thing that was going to deliver the saving.

Go-live stops being the finish line. This is the one most often missed. Most of the projects I’ve worked on changed how teams operate day to day. In those projects the system is only half the job. The other half is organisational change management: redefining processes around what has been introduced, training people, setting up support, and staying with the users long enough for the new way of working to stick.

BABOK covers this in its Solution Evaluation knowledge area. It is about measuring the value a solution delivers once people are using it, and recommending how to remove whatever is stopping the full value from being realised[10]. BABOK splits those blockers into limitations of the solution itself and limitations of the enterprise around it[10]. In my experience the second group is usually the bigger one: processes nobody updated, skills nobody built and habits nobody challenged.

Go back to my $50,000 example. That saving only shows up if people actually stop doing the work the old way. A PM who only manages delivery will hand over and move on. A PM who understands why the project was done will keep going until the outcome is real.

The research on this is hard to ignore. Prosci’s long-running studies found that projects with excellent change management were about seven times more likely to meet their objectives than those with poor change management. They were also nearly five times more likely to be on or ahead of schedule, and around 1.5 times more likely to stay on or under budget[11]. That last part surprises a lot of project managers who see change management as something that slows delivery down.

Split the roles when the size and complexity of the work calls for it, and give each person enough room to do their job properly. But don’t split the purpose. The PM needs to understand the why as clearly as the BA does, and the BA needs to care about delivery as much as the PM does.

Project management gets you there on time and on budget. Business analysis makes sure you’re heading to the right place. You need both before you can honestly call a project a success.

I’d like to hear how others have handled this. Have you seen a project go live on schedule and still fail to deliver what it promised? Feel free to reach out and share your experience.