Business Analysis Center of Excellence – How To Stop Committing Project Malpractice
Most organizations are very good at delivering projects.
They are much less good at deciding which projects should exist in the first place.
You can hit the holy trinity of project management
on time, on budget, in scope
and still ship something that does not move the needle for your customers or your mission.
In medicine, prescribing before diagnosing is called malpractice.
In business, it is called “business as usual.”
A Business Analysis Center of Excellence (BA CoE) is one way you put discipline and ownership around changing that.
This guide walks through:
- Why “successful” projects still fail
- What business analysis really is (and is not)
- Why BA is not a junior skill, even if the title often is
- A simple diagnostic split: problem vs new capability
- A seven step lifecycle for value focused business analysis
- How conflict patterns reveal what is really going on
- What a BA CoE does and how to start one at any scale
- One question everyone in your organization should learn to ask
Use this as a field guide for yourself, your team, and anyone who touches projects.
This video comes from my time building the Business Analysis Center of Excellence at the U.S. Forest Service under USDA. It walks through foundations of business analysis, why we bothered to stand up a BA Center of Excellence, and how we handled governance, templates, and coaching inside a very traditional hierarchy.
The recording is several years old and it feels like a rough-cut training, not a polished demo. Some agency specifics and systems have changed, but the underlying patterns have not.
If you are trying to move a complex organization from ad hoc projects toward disciplined business analysis, watch it as an example to steal from and adapt, not as a script to copy.
I am sharing this here because I want you to see what this looked like in a real federal agency, warts and all. You do not need me in the room to apply these patterns, and there are many ways to structure a BA function. This is simply one concrete instance you can compare against your own world.
1. Why So Many “Successful” Projects Still Fail
If you look at failed initiatives, a familiar pattern shows up.
- The project had a charter.
- It had a sponsor.
- It had a schedule and a budget.
- It had scope that was reasonably well defined.
- The team worked hard and did what they said they would do.
And yet, when the dust settled, the business outcome was not there.
- Customers did not adopt the new portal.
- Staff quietly went back to their spreadsheets.
- Costs did not go down.
- Risk did not go down.
- The strategic priority the project was supposed to support did not move.
The usual post mortem questions are about execution:
- Did we have enough resources
- Did we estimate correctly
- Did we manage scope creep
Those are valid questions. They are not the first questions.
The first question is:
Were we even working on the right problem
If the answer is “no,” then perfect execution only gets you to the wrong place faster.
That is what business analysis is trying to stop.
2. What Business Analysis Really Is
There are many formal definitions of business analysis. Here is a useful one:
Business analysis is the practice of enabling change in an organizational context by defining needs and recommending solutions that deliver value to stakeholders.
A plainer version that you can hand to non practitioners:
Business analysis delivers better business outcomes that are aligned with organizational goals and stakeholder needs, outcomes that would not happen otherwise.
That second half matters.
If the outcome would have happened anyway, you do not need a business analyst.
You need a scheduler.
Business analysis vs business analytics
People often mix these up.
- Business analytics crunches numbers.
It looks at your data to detect patterns.
For example, a credit card company calculating credit risk, or a logistics team optimizing routing. - Business analysis asks different questions.
- What problem are we trying to solve
- For whom
- Why now
- What will be different if we get this right
Analytics can support analysis, but it is not a substitute.
“Is business analysis boring”
If you ask most people whether they want to be great at business analysis, almost no one says yes.
It sounds abstract, bureaucratic, and sometimes pedantic.
It involves documents, diagrams, meetings, and uncomfortable questions.
Is it glamorous No.
Is it something anyone aspired to in kindergarten Probably not.
Are some BA conversations painfully detailed Yes.
Does the core idea benefit any serious enterprise Absolutely.
At its heart, business analysis is very simple:
Slow down long enough to understand what is going on, what you are really trying to achieve, and what will actually get you there.
Everything else is tooling and technique.
3. Business Analysis Is Not A “Junior Skill”
One of the most damaging beliefs you can have is:
“Business analysis is for junior staff. Senior people are beyond that.”
If you hold that belief, three bad things happen.
- You delegate the thinking and keep the politics.
Senior leaders spend their time in funding boards and steering committees, but never train themselves to ask good diagnostic questions. - You create a skills vacuum at the top.
Elicitation, stakeholder management, and conflict framing are treated as box checking exercises, not as core leadership skills. - You hollow out horizontal capability.
The people who do have BA skill get trapped at one layer of the org chart and one domain, instead of being allowed to move sideways across programs and disciplines.
In reality, good business analysis is inherently cross cutting.
- It applies at every level, from a help desk lead up to the CIO.
- It cuts horizontally across IT, operations, finance, customer support, policy, and more.
- It connects strategy, operations, and technology.
If you are a senior leader and you opt out of learning BA thinking because the title sounds junior, you are making a category error.
You might never have “Business Analyst” on your badge.
You still need to be able to:
- Elicit what people really want and need.
- Understand what motivates each stakeholder.
- Separate symptoms from causes.
- Frame options in a way that makes tradeoffs visible.
- See how one solution will ripple through the rest of the system.
Those are not junior skills.
Those are leadership skills, with a formal discipline behind them.
A Business Analysis Center of Excellence is one way to protect and normalize that skillset, so it does not get dismissed as “documentation work.”
4. The Business Advisor: Getting Around The Org Chart
Here is one reason business analysis can struggle in traditional organizations:
Org charts are about status and control.
Business analysis is about advice and insight.
If you are lower on the org chart, offering advice upward can feel risky.
If you are higher on the org chart, accepting advice from a junior can feel uncomfortable.
To get around this, it helps to reframe the role.
Instead of “business analyst,” think “business advisor.”
Consider two examples.
The dentist
When you sit in a dentist chair, your social status does not matter.
You could be a senior executive, a junior employee, or a head of state.
In that moment, you willingly defer authority to the dentist and their team.
- You expect them to examine, test, and diagnose.
- You expect them to offer options.
- You expect them to tell you what they would do if they were in your place.
You still make the decision
pull the tooth, fill the cavity, or wait
but you rely on their professional judgment to frame the choice.
The corpsman
In many militaries there is a similar pattern.
A young hospital corpsman might be years junior to the soldiers they treat and to their commanding officers.
Yet when that corpsman says a service member is not fit for duty, that restriction is respected.
Authority is temporarily deferred to earned medical competence.
You can build the same kind of deference around business advisory skills.
A BA CoE is essentially a cadre of “business corpsmen” and “business dentists” who:
- Listen.
- Diagnose.
- Offer options.
- Make tradeoffs visible.
- Then hand the decision back to the people who own it.
The org chart stays intact.
The quality of thinking improves.
5. The First Diagnostic Split: Problem Or New Capability
One of the first questions a good business advisor asks is very simple:
“Is this a problem, or are we trying to create a new capability”
The distinction sounds academic.
It is not. It completely changes the approach.
What is a problem
A problem has four parts:
- There is a defined standard.
- There is a deviation from that standard.
- The deviation happens at a specific point in time.
- The cause is not yet known, and it matters.
Example:
- Your contact center has historically answered 90 percent of calls within 30 seconds.
- Over the last two months, that drops to 60 percent.
- Nothing obvious changed in the technology stack.
- Customer complaints are rising.
You had a standard.
You saw a deviation at a specific time.
You do not know why.
It matters.
That is a problem.
What is a new capability
A new capability is different.
- You have never been able to do this thing.
- There is no historical baseline.
- You cannot talk about “deviation from standard” because no standard exists yet.
Example:
- You have never offered an online portal.
- Now you want to.
- You have a target in mind, but no past performance data.
That is not a problem.
It is a capability build.
Why the split matters
Problems and new capabilities use different tools.
- Problems are about restoring a lost ability.
- New capabilities are about creating something from scratch.
The diagnostic question is:
“Have we ever been able to do this before If yes, why not now”
If the answer is “yes, we used to,” then you are in problem solving mode.
If the answer is “no, never,” you are in capability design mode.
Treating a capability build like a simple problem is how you get naive timelines and magical thinking.
Treating a simple problem like a capability build is how you waste effort over engineering something that only needed one careful fix.
A BA CoE exists to make sure that split is made early and consciously.
6. The Seven Steps Of Value Focused Business Analysis
Once you have that initial split, you can follow a repeatable lifecycle.
Here is a seven-step model that works across industries.
Step 1: Identify problems and opportunities
This is the “chief complaint” step.
- What hurts
- What is not working as expected
- What is working, but hints at a bigger upside
You are not designing yet.
You are noticing and naming.
Step 2: Clarify problem vs new capability
Ask:
- Have we ever done this successfully before
- If yes, when did it stop working
- If no, what would “working” even mean
This anchors you in the right mental model.
Step 3: Elicit and document requirements
This is where the stereotype of “boring BA work” lives, but it is also where a lot of value is created.
You are trying to answer:
- Who cares about this and why
- What outcome are they actually chasing
- What constraints are non negotiable
- What fears or incentives might derail good decisions
This is not just about user stories and process maps.
It is about human motivations.
- The executive who wants numbers for a board meeting.
- The frontline staff who are afraid a new system will expose their coping mechanisms.
- The finance team that needs a predictable cost profile.
Good elicitation means you understand the people behind the requirements, not only the text in the document.
Traceability matters too.
Every requirement should have a source and a rationale.
Nothing gets added simply because “it would be cool if.”
There are no cool requirements.
There are only justified requirements.
Step 4: Define and compare solution alternatives
Once you understand needs and constraints, you can look at options.
- Buy vs build.
- Centralized vs distributed.
- Manual process change vs tooling change.
Think of the dental example.
- Pull the tooth.
- Fill the cavity.
- Perform a root canal and crown.
All three might remove pain.
They have different costs, risks, and long term implications.
In a project setting, your job is to:
- Make alternatives explicit.
- Show tradeoffs.
- Connect each alternative back to the requirements and to the broader business context.
This is where the advisory role is powerful.
You are not deciding for the sponsor.
You are helping them make a decision they will not regret.
Step 5: Support implementation and protect scope
Once the project is underway, classic project management takes the lead.
The BA CoE does not disappear. It shifts focus.
- Keeping requirements visible.
- Watching for unvetted additions.
- Surfacing impacts as new ideas appear.
If someone says “it would be really nice if it also did…” the BA instinct is to ask:
- Who needs that
- What requirement does it support
- What are we trading away if we take this on now
That one habit alone can save months of effort.
Step 6: Verify outcomes, not just outputs
When the thing ships, the work is not over.
Shipping is an intermediate milestone.
The real milestone is the outcome.
Go back to the original problem or capability statement:
- Did customer wait times actually go down
- Did kiosk usage actually increase
- Did error rates actually fall
- Did revenue or mission impact move in the intended direction
This is the business version of the physician question:
“Do you feel better”
If the answer is no, it is time to look again at diagnosis, not just at execution.
Step 7: Monitor real use and prevent workarounds
Over time, two things always happen:
- The environment changes.
- People invent their own shortcuts.
Workarounds are not inherently bad.
They are signals.
- Sometimes they reveal that the official process does not match real work.
- Sometimes they reveal unanticipated constraints or edge cases.
A BA CoE pays attention to those signals and:
- Decides which workarounds should be formalized.
- Decides which ones should be eliminated.
- Revisits requirements in light of new realities.
This closes the loop, so that the next project is smarter than the last.
7. Conflict As A Diagnostic Tool
Projects are full of conflict.
Most of that conflict is misclassified.
There are three broad types that matter here.
1. Personality conflict
This is what people usually blame.
- “They just do not get along.”
- “Their styles clash.”
True personality conflict exists, and sometimes it does require HR or professional intervention.
It is not the most common pattern in project work.
2. Outcome conflict
This is a disagreement about what “success” even means.
Example:
- One leader cares most about time to market.
- Another cares most about minimizing risk.
- A third cares most about staff workload.
They are arguing about the same effort, but they are optimizing for different outcomes.
3. Alternative conflict
Here, people agree on the outcome but disagree on the path.
Example:
- Everyone agrees they want a training program for staff.
- One group wants a self paced video series.
- Another insists on in person workshops.
The BA CoE’s job is to triage what kind of conflict they are seeing.
- If it is alternative conflict, remind everyone of the shared objective and explore options.
- If it is outcome conflict, clarify who owns the decision about what “success” is.
- Only escalate to “personality conflict” when it really is about interpersonal dynamics.
That simple triage prevents a lot of unnecessary drama and keeps energy focused on solvable problems.
8. What A Business Analysis Center Of Excellence Actually Does
Think of a BA CoE as the equivalent of a top medical center for your project portfolio.
Instead of scattered, ad hoc practices, you get a coordinated framework under one roof.
Typical services include:
- Intake and triage of new ideas
- Separate problems from capability builds.
- Spot duplicate efforts.
- Identify quick wins and hidden dependencies.
- Facilitation of diagnostic conversations
- Help sponsors articulate the real problem or opportunity.
- Make sure the right people are in the room.
- Expose hidden assumptions.
- Requirements practice and governance
- Maintain standards for elicitation and documentation.
- Provide templates and coaching.
- Ensure traceability across the lifecycle.
- Option analysis and decision framing
- Prepare structured alternatives with pros, cons, and impacts.
- Support leadership boards and steering committees with real choices, not just yes or no.
- Outcome verification and post implementation review
- Run “did we actually get what we wanted” sessions.
- Capture lessons that are actionable, not just blame stories.
- Portfolio level monitoring
- Look for systemic patterns in problems and workarounds.
- Advise on where to invest in new capabilities versus fixing recurring issues.
At its best, a BA CoE is less about documents and more about posture.
It gives your organization a habit of diagnosis before prescription.
9. How To Start A BA CoE At Different Scales
You do not need a huge budget to start.
In a large agency or enterprise
- Start by mapping where BA work is already happening under different labels.
- Bring a small group of your strongest practitioners together.
- Standardize a minimal set of practices:
- Problem vs capability diagnostic.
- Requirements traceability.
- Option analysis format.
- Outcome verification checklist.
Give them a visible mandate to advise on major initiatives.
Report their impact in clear, business terms.
In a small company or startup
You probably will not create a formal “CoE” at first.
Instead:
- Identify one person who can play the business advisor role, even part time.
- Create lightweight artifacts:
- One page problem or opportunity brief.
- One page options table.
- One page decision log.
Make it normal to use those for any decision that moves real time or money.
As you grow, you can formalize the function.
10. The One Question Everyone Should Learn
You do not have to train everyone as a full business analyst.
You can still change the culture by teaching one simple question that anyone in the organization is allowed to ask.
When someone in authority asks for a project, a feature, or a deliverable, the response can be:
“Before we get started, can I ask how you know this will actually solve the problem you are seeing”
That is it.
- For executives, the discipline is to expect and welcome this question.
- For staff, the discipline is to ask it respectfully and consistently.
Everything in this guide grows from that spark.
Bringing It All Together
Business analysis is not glamorous.
It is not what most people brag about on social media.
It can feel slow, detailed, and even pedantic.
It is also the foundation under every serious enterprise.
- If you care about not wasting money, you need it.
- If you care about not wasting staff goodwill, you need it.
- If you care about not disappointing customers, you need it.
- If you care about doing the right work, not just doing work right, you need it.
Or you can treat them as part of your craft, at your level and in your domain, and use a Business Analysis Center of Excellence to support you.
Whether you are a junior staff member, a middle manager, or a senior executive, the skills of business analysis cross your path.
You can either pretend they are “junior tasks” and leave a critical gap in your own capability.
Or you can treat them as part of your craft, at your level and in your domain, and use a Business Analysis Center of Excellence to support you.
It all begins with analysis.
Diagnosis before prescription.
Last Updated on December 9, 2025
