The Better Business Analysis Institute.
Presence the Better Business Analysis podcast.
With Benjamin Walsh. Hello.
Everybody and welcome back to the Better Business Analysis
podcast with Benjamin. Walsh, your host and today.
We are continuing on our BA. Byte series.
And we're diving straight into hen ways to spot and solve.
Project red flags. That's right, we're all, we've
all been on projects either. Successful or unsuccessful?
Projects that have had red flags.
Along the way, and so I'm going to give you 10 red flags that
you can watch out for and I'm going to talk.
About specifically what you. Can do as.
ABA. So if you're not ABA listening,
you can probably. Still do.
Some of these actions. Everyone on the project should
always recognize red flags. And I'm going to give you 10 of
them. Today.
So #1 is missed deadlines and milestones.
The BA focus. Here is to.
Analyze the root cause of delays.
Are they due? To unrealistic planning.
Lack of resources. Or kind of unanticipated
challenges along the way. So you will know if you missed a
deadline because you should have your.
Milestones already defined and if you don't then your root
cause might be you need to define your milestones now in
this case. The BA should.
Present the data on the missed deadlines and highlight the
impact. On the project's critical path,
so they. Are the most important
milestones along the way if nothing else mattered.
They can propose a reevaluation of.
Time frames or. Suggest revisiting resource.
Allocation and it should. Be escalated as a risk.
Up. To the stakeholders of the
project. So this.
Conversation would be with the PM initially.
Why should? You raise this.
Delays just compound. OK.
It leads to more significant. Problems and project risks down
the. Down the line and early
intervention allows the team to re.
Collaborate or reset? We say sometimes before it's too
late, so if you missed the first deadline.
Raise it straight away, OK? It's not like.
You need to raise it. Straight away, as ABA, we must
look. We said we were going to do it.
Here, we're not doing it. Here this is.
What I suggest. Project Manager, let's raise it
into the risk. Register is a critical risk.
Number. 2 is budget overruns OK, so.
When the BA themselves can assess.
Whether or not due to scope. Changes or inefficient?
Use of resources or maybe? Just inaccurate budgeting in the
initial planning phase of whether or.
Not it's likely that you're going.
To go. Over budget.
And so you might not have access to the finances, but for
example. If you knew.
That you were buying like a. New server.
Or you're estimating some cost to.
Go out to. A vendor and that came.
Back and. Everyone was.
Surprised about that? Then you would know that you've
gone over budget and so there's usually about a 20 to 30%.
Contingency on projects. But that's locked in at the
start, so if there's suddenly a big expense you didn't plan for.
That's. Going to come from somewhere.
Time, costs and quality. One of those is going to move.
In this case, the BA can conduct.
Like a various. Kind of a variance analysis just
working out. What the actual cost versus?
The estimate and you could ask the project.
Manager, if you can see those costs.
And you? Can look at.
Areas of. Overspending and recommend
adjustment adjustments. So you can.
I mean #1 is just. Cut out low priority tasks or
find. Cheaper alternatives, but if
you. Go over.
Budget, then you threaten the financial.
House Health. Of the project which is 1.
Of the pillars. Cost.
And. If you don't take corrective.
Action, then that money is going to come from somewhere.
So usually labor, it will come off the labor, which means
you've got to just do less. Stuff.
So it's really important. To monitor that and of course.
The other side of that around quality or we.
Use the word. Scope and projects is scope
creep OK? Track all scope changes.
And validate whether or not they align with the business needs
and are formally approved. Look, it doesn't matter who
you're working with, make sure you've got some formality in
terms of if something is signed off, make sure that.
You do. Have a line, even an agile.
That you've kind of. Locked in the.
Scope OK. Agile is about refining features
and how you're going to do things and and kind of running
at speed. But ultimately, the vision
should still remain the same, and if scope changes from that
vision, it's going to impact you.
Regardless of your waterfall, agile or whatever other full.
That you are using. The BA should.
Document each. Scope change, right?
And you could do that in terms of requirement changes and then
get a response to that and that could.
Be an increase. Or impact anyway on time,
budget. Resources.
And that needs to be very clear and again, escalated.
Uncontrolled scope Scope creep. Excuse me?
Can derail a project OK? This isn't about.
Refining a requirement. This is about having a new
requirement. The BA raising.
That is to protect the integrity of the original project.
Goals. And also that you're meeting the
user journey that the BA envisioned upfront.
OK, you do not want to set unrealistic expectations.
And the reality? Is people do think of things
along the way, so you need to make sure that that is managed
effectively. The other one which is.
Really important, which is more around EQ.
Which we talked about last week is low team.
Morale. The BA is a cross functional.
Role and they can. Observe and see.
Signs of burnout, usually. Colds.
Is a big sign people get sick if it's more than a couple of
people and it's not just a cold and people getting sick and
again, disengagement, frustrated.
Registration. People acting out of.
Character they're usually. Doing that because they're.
Overworked. OK, they.
Have lack of. Clarity or poor leadership?
The BA. Can informally.
Gather that feedback. From the team understand their
concerns. Advocate for them right around
workload. Distribution and you should.
Talk to your. Program project manager.
About that low? Team morale.
A fixed productivity. And the quality of deliverables
and ultimately mental health. And it's just not good enough.
No one should quote UN quote. You know, get so upset about
these. Deliverables when you're on a
project. The BA.
Raises raising it. Ensures that the team.
Dynamics are addressed. And without the team dynamics
working the engine. Working.
Appropriately and not sputtering or or having engine.
Failure you're. Just not going to be able to
deliver anyway #5 is poor communication.
We talk about communication again and.
I'm happy every time I do it because it's a reminder monitor.
Communication channels and identify whether key information
is getting lost or delayed leading to misalignment.
I had that this week. The BA can.
Recommend structured communication.
Methods like a one page. Decision doc, right?
Or a racy, but you're actually a practical racy where you're
actually allocating. Communicating to.
Everyone that wants to know. Status updates clear.
Reporting lines, effective documentation.
They're also important. Poor communication can lead to
misunderstandings and costly mistakes.
The BA. Raising, raising it is a.
Really good person. To raise it.
They promote clarity. They ensure that.
Information flows properly between all.
Parties and actually you can, even if it's not your.
Area of the project. You can actually help here by
putting up a. Structured process in place.
For communication. This is terrible.
Communication. Means a whole lot of things.
It's not just it's like an onion, right?
You UN peel it and one of them could be just slow getting
decisions. One could be project manager not
knowing how to deal with the. Difficult stakeholders, so they
wait a week. And all of that have impacts in
terms of time and effort and cost and quality #6 is.
Around increased defects. So the amount.
Of bugs. Really.
Or test. Cases that fail or quality
issues. So BAS.
Can identify patterns and quality issues and that could.
Be from the fact that you. As ABA haven't.
Done a really good job. Of or enough of a job in terms
of requirements solicitation. It could be around the.
Development the development slack and that could be again
gap between BA and developer. Or it could be a gap.
Between developer and. Tester.
Or it could be a testing gap the BA can review.
The kind. Of defect backlog or the test?
Backup log and you know with the bugs in it and participate in
triaging those and getting making sure that the QA team,
the the testing team and the development team are focusing on
the root. Cause there.
It could be something that's technical.
Debt related. You're building on a problem
that already existed, but obviously building on top.
Of that, it would be really important to kind of.
Raise that that. These frequent defects.
Indicate a deeper issue in the development process.
Or there's something around your requirements you're not getting.
Feedback before devs start so they're.
Like building something that doesn't align with your
requirements so you you can definitely.
Help. When it comes to quality issues,
even though. That's usually you.
Would think. Owned by the.
Tester you as ABA. Play very, very closely with the
tester. #7 is. Around stakeholder
dissatisfaction, you can gauge stakeholder feedback and check
whether their expectations are being.
Aligned. As you have regular progress.
Meetings with them and deliverables.
So the BA. Can.
Facilitate regular stakeholder reviews.
Gather. Informal and informal feedback,
and they can test along the way, and that's what you should be
doing. So one test is not just about
the. Product testing.
And go oh. Does this look good?
But one might just be testing your requirements, like going to
them with a list of your requirements saying ensure these
are. Right.
And checking in again. Anything changed?
If if. Stakeholders are dissatisfied
and it's usually a gap between what they thought they were
getting and what they get. The project.
May lose. Support or.
Fail to meet objectives there will.
Be a trust. Gap between the project and the
stakeholders and ultimately. BA is really.
Good at managing that relationship and ensuring that
there's continued alignment with business goals.
That's. Actually your job so if you go
through. And things are just not
aligning. So you'll you've done the
requirements, you've started dev and things you're starting to
output and you should have done. Like regular demos?
When I say demos, the product might not be there, it could
just be a mock up. Back to the.
Stakeholder. And they're like.
Well, it's not really what I wanted.
That's the time to intervene, OK #8.
Is around unclear. Roles and responsibilities.
We talked about racy before. But I think the BA is.
Really clear or usually they hear about it.
When the team members are unclear.
About their responsibilities. Leading.
To confusion or duplicated efforts.
The BA. Can develop or update the the
racy matrix. To clearly identify who's
responsible, accountable, consulted and informed.
For each. Task.
Now that's can be a bit administrative and just.
Add bureaucracy here. I think it's just really just
like, who's responsible for testing, who's responsible?
For UAT. That's an interesting question.
So you just. You can just do it once.
Who is it? Who's your real Smee?
Who needs to be? Who needs to sign this off?
It's not a is it a committee? Committees.
Never. Work by the way.
So you need need an accountable product owner.
So if. You don't.
Have clear responsibilities and. Roles.
That leads to inefficiencies and frustrations.
The BA raising. This ensures there's smoother
collaboration and accountability both within the team and
outside. So you need.
This this racy. In the team and you need it out
the team. I see this all the time.
This is. I would say is up there as.
One of the number one underlying.
Reasons. That project fail.
OK #9 which is kind of, if you like, an amalgamation of all
those things. We just.
Talked about. Is poor risk.
Management, OK, All of those things we talked about if
they're happening. A risk should.
Be logged OK. Along with our.
Suggested mitigation. So if.
You are not reviewing the risk. Log at least once a.
Week. OK.
With the team. And they're not properly
tracked. Or.
Mitigated, then you have a problem.
The BA. Should proactively engage.
In risk identification. And management ensuring.
They are logged. Assessed.
Mitigated. OK.
That could lead to a risk. Workshop, right?
And a risk review. That should all those.
Risks, especially if they're high.
And I would. Say all of them in the appendix,
so the high ones maybe in your PowerPoint and then all of them
in the appendix should be. Provided to project.
Governments if risks are ignored, they materialize.
Into. Actual issues and and.
Probably significant problems to be honest.
Issued. You know, issues sound small.
But we're actually about problems here.
You raising them allows. The project to adapt and prepare
for those project. Challenges that you have along
the way and at the end of the. Day.
Of risks are mitigated as the project.
Is in jeopardy and #10. Is what we talked.
About a. Little bit it's.
Closely related. To scope.
But it's slightly different and that is frequent change
requests. So.
A lot of project managers go right.
I'm fine, I'm going to protect the initial scope, but what I'm
going to do is. When a change comes through, I'm
just going to raise the change request.
So I get. The money and resources I need,
so I'm going to go through that formal channel.
But. Actually, at the end of the day,
it's a distraction from you doing.
The main core focus of the. Work.
Right, I can't. The product can't be everything
to everyone. So.
If there are change requests which being driven by changing
business needs or unclear requirements or external
factors. The BA probably knows.
OK, so it. Depends on the pattern of the
change request and you need to. Really.
Probably intervene. And talk to stakeholders and say
well. What's the problem here?
Have we got the requirements completely wrong?
Do we need to stop and do a reset?
But you. Can't just add.
On more work to. What we're doing, because at the
end of the day, there is. Only a certain pipeline that can
that's been set up and certain budget.
Now, even if you add more people and you add more budget.
It doesn't work, trust me. It doesn't work.
The BA raising thus that there are frequent change requests
make. Sure, it's making sure that the.
Project. Is focused on the.
Goal the actual vision of the project and ensures that changes
are. Only made if something.
That is critical. Basically and it's.
Not met. You don't.
Meet the. Objectives is truly necessary.
And if that isn't true, if that. Change request doesn't fall into
the category of. Absol critical.
Don't do it. Do it as a second phase after.
This project is. Properly closed.
So there's 10. Red flags that you as.
ABA can ID can identify. And help with.
And if you can spot and solve. These project red flags your
project. Is in a much better state.
Of delivering on. Time, you know.
Within cost, within budget. With great quality.
And can actually mean that you've got.
A happier project team. I'll see you next week.