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.