Software development projects are staffed by people like and you me, and where human beings are involved, things can sometimes get out of hand. There will be incessant conflicts on projects, and there will be expectations that are unrealistic, impossible, and downright unprofessional.
It is understandable that the business landscape of the day can put an organization and its projects in complex and highly challenging situations. Managing these situations is not for everyone, and it requires deep expertise and specialized skillsets that can be deployed to enable a project successfully emerge from these trying situations.
When faced with complex and unpredictable project situations, some end users, stakeholders, and project actors rise to the occasion and successfully close out hair-raising situations without rancor, personal conflicts, or unprofessionalism. These challenges bring out the best in them.
Conversely the unpredictable situations on projects can bring out the worst in some end users, stakeholders, and project actors. Because they are not adequately equipped with the experience or the tools necessary to manage the unexpected challenges that arise on projects, their responses are precisely those that exacerbate and inflame project challenges. Their responses range from management by bullying or intimidation, making unrealistic demands, shirking key decisions, managing through cliques, and all manner of unprofessional operational methods.
Any Business Analyst who has been a practitioner for a while has likely come across both sets of projects—those that rise to the occasion when the heat is on and those that wilt under pressure. As expected, no Business Analyst looks forward to being part of the dumpster fire that is the latter option, and the rest of the chapter will detail how to spot these troubled projects.
These dumpster fires of projects induce stress and confusion amidst a lack of clarity of purpose or focus. The way these projects are run also upsets the collaborative ethic on projects, damages relationships, creates unnecessary conflicts, and in some cases makes project actors physically ill. In an ideal world, none of us would want to shorten our lives by being staffed on these types of badly run projects. Sadly, there will be points in the career of a Business Analyst when they find themselves in the midst of such projects.
Additionally, given the aforementioned downsides of being staffed on such a project, the time comes when a Business Analyst has to evaluate whether continuing their tenure on such a project is worth it.
A project that is run with no sign of operational improvements or any strategic course correction from project leadership is usually a sign for the Business Analyst to reconsider their tenure on the project. It is time to either find another project or organization or both.
Should Business Analysts just skip town the moment they hit troubled waters? Not at all.
If a Business Analyst is confident and they have the tools, the expertise, and the support of project leadership to pull the project out of the fire then by all means they ought to proceed. Keep in mind that a rescued project makes for good reading on a well-crafted resume or LinkedIn profile; it’s great for career bragging rights. Not only does saving the project sharpen the intellect of a Business Analyst; it also deepens their expertise. They can always look back on how they rescued a seemingly lost cause and apply the same skillsets and expertise to other struggling projects.
However, there are projects that not even superheroes can salvage—they are that far down the rabbit hole. The project leadership lacks direction or know-how, and the project has flubbed and continues to flub key project management indices like budget, scope, and timing. Short of a change in the project or organizational leadership, there is not much that a superhero Business Analyst can do to salvage such projects. For a Business Analyst staffed on this horror show, it is time to move on.
Projects with bad leadership are a career accident waiting to happen which is usually manifested by projects being mothballed, downgraded, or outright terminated. A Business Analyst could very easily be rendered jobless when a project is shuttered. Its best for Business Analysts to exit on their terms and be fully in control of the narrative about their exit.
Badly run projects stunt professional growth not just for Business Analysts but for other team members too. If the project actors are obsessed with corporate politics and meritocracy is a dirty word, the fine work or potential of a Business Analyst is very unlikely to shine in such an environment. It’s pointless for a Business Analyst to invest their future in a project obsessed with office politics.
Here are a few signs that your project and specifically your tenure as a Business Analyst on that project needs serious re-evaluation.
Unrealistic Expectations or Assignments
While Business Analysts will wear many hats during the life of a project, some of the hats they are asked to wear are straight out of crazy town. I know; I have been asked to wear one such hat.
I had been on a project for a few months when I was asked when I was going to remove “X” from the project. Stunning but true: I was being asked to “fire” one of the project team members. There was so much wrong with this jaw-dropping request that I didn’t know where to start or end.
This has been touched on in the beginning chapters of this book: Business Analysts are rarely given the authority to hire or fire other project team members. They may interview or advise which candidate to hire or which disruptive team member needs to have a “chat” with human resources, but that’s the limit of their hiring or firing powers.
There may be projects out there where the project structure gives a Business Analyst these kinds of powers, but I will hazard a guess that they are a very tiny minority.
This particular instance was so galling for the simple reason that the Project Manager was simply avoiding their project staffing responsibilities. There had been no discussion about why such a sensitive task was being delegated to me, and it just smacked of high-handed unprofessionalism.
This episode illustrates the meaning of unrealistic expectations or assignments that Business Analysts encounter on projects.
Another take on unrealistic expectation’s centers on impossible workloads that regardless of how hard and long a Business Analyst works, the workload cannot be brought under control. A good day is a 12-hour shift for a Business Analyst on a project of this type. Unrelenting workloads are usually a sign that something is off-kilter in terms of project objectives, stakeholder expectations, project staffing, or the style of working of an individual Business Analyst.
Long shifts are unhealthy; they can induce burnout, not to mention that they are unhelpful toward maintaining a healthy work life balance. Experiencing these downsides of difficult workloads for extended periods of time should cause a Business Analyst to reevaluate if this is the ideal Business Analyst career they had in mind.
Another sign a project may not be right for Business Analyst is when project management works at cross-purposes and sees nothing wrong with that way of working.
If these expectations or assignments are being set with regularity with the expectation that the Business Analyst will meet, them then it may be time to consider if the Business Analyst is on the right project. More importantly they have to evaluate if this is how they would like to grow their career and professional abilities.
Lack of Transparency or Integrity
Project management that is lacking in transparency or integrity will sooner or later get a Business Analyst burned professionally. Project leadership that is brazenly deceptive and which prizes the same behaviors from other project team members should cause a Business Analyst to evaluate their tenure on such a project.
I once witnessed a project manager outrightly deceive organizational leadership about the status of the project I was staffed on. For starters he fibbed that the project was green—only that it wasn’t. It was trending red and had major issues with funding given the challenges it was having with closing out major project milestones.
On that call I was hearing a description of a project far removed from the one I was staffed on. All the warts were conveniently sanitized, and the impression the other callers got was that the project was going well; nothing could have been further from the truth.
This deception was unnecessary and it deflated my morale as it was obvious I was not on board with these brazen deceptions. This brazen act of dishonesty told me everything I needed to know about him, his values, and more importantly where our project was headed under his stewardship.
The person who lies to your face is not interested in your success or that of the project that he manages; it’s just their interests they are looking out for. This lack of integrity was a sign it was time to consider other options.
Purposefully Poor Communication
A close relative of a lack of integrity. If a Business Analyst is finding out about critical decisions concerning their work through the grapevine or informal unverified channels, then there is a problem. When project leadership is not getting ahead of major decisions and leaving them to be communicated by the grapevine, then what you have is not a communication problem but a zero-communication problem.
I once found out that end users and stakeholders had pulled the plug on the requirements we had been scoping and were instead moving in a totally different direction. Project management knew about this 360-degree turn, but we the Business Analysts were in the dark and continued working those same requirements. The point here is that information that impacts a Business Analyst at the tactical level has to be available to them, and they don’t need to beg to access it.
If this is a one-off event, that is understandable, but if this is how project management operates, the Business Analyst is courting trouble, for they will be working at cross-purposes most of the time. To my mind there are fewer surefire ways to make a Business Analyst look incompetent than denying them information that is critical to their deliverables.
Ingrained Lack of Focus and Purpose
It is the nature of organizational management that not all organizations and project setups are efficient and supremely organized to deliver all the objectives they set out to deliver. Organizations and project setups are also different; some of them are great at project execution and others not so much. Additionally, organizations always seek maximum returns from the projects they undertake; in other words, they will undertake those projects with the biggest bang for their buck.
In realizing this objective, some organizations have mastered the dynamics of successfully delivering multiple high-impact projects simultaneously. Other organizations cannot even come close as attempts to run multiple projects end in dismal failures or very few of the original project objectives are achieved as they undertake these multiple fronts and high-impact project implementation approach.
In terms of project performance, you can always tell the high achievers from the slackers after spending a few weeks with an organization.
There will be projects that sound and look dated—they just don’t close. Others close as soon as they are launched while others are in perpetual state of “launching.”
Watercooler chitchat can be amusing if not frightening as that is how I once found out the project I had been assigned to never gets anything done but for one thing: chewing up and throwing out team members. It had been in motion for so long colleagues started called it the “zombie” project.
While staying on zombie projects likely guarantees job security, it is not the type of project you want to be on forever. The reason it most likely never closes is due to lack of focus, purpose, and direction or all three.
Additionally, if a Business Analyst keeps getting assigned to projects that fold almost as soon as they are launched, those talents and abilities are being mismanaged, and it’s time to consider other professional pursuits. Launching a project is expensive business so why close projects willy nilly? What would be the thinking behind such project launches in the first place? It is the type of thinking and actions that display a lack of focus and clarity at the organizational and project level that don’t bode for a Business Analyst career.
Toxic Organizational Cultures
There is a ton of stuff that’s considered toxic on projects that cannot be exhaustively covered here, but suffice to say that if a project environment repeatedly makes a Business Analyst intimidated, physically unsafe, stressed out, or ostracized, then it’s time for a tenure re-evaluation.
Under the guise of competitive creativity, some projects encourage pitting team members against each other. I am all for healthy competition that gets the creative juices flowing, but an environment where the worst office politics is conflated with competitive creativity is best avoided altogether. Very rarely do project teams produce outstanding deliverables in such toxic environments. It’s also unlikely that a gifted and talented Business Analyst will stand out as meritocracy is not exactly valued in such project environments.
Closely following toxic cultures is cronyism or “buddyism.” It simply refers to project environments that closely mimic Animal Farm where the Napoleons reign supreme and where there are few if any consequences when they don’t meet their deliverables. On these, projects’ accountability and responsibility for project deliverables are applied selectively, and some project team members become notorious for being perennially late on their deliverables. Because they are buddies of project management, they do not face any sanctions, or if they do face sanctions, it’s more of a charade.
In fact, sanctions are so selectively and lackadaisically applied by project management that team members may be sanctioned based on how project managers feel on any given morning. Cronyism does not bode well for project teams whose lifeblood is collaboration, accountability, unity of purpose and cohesiveness, and this is usually manifested in the quality of the deliverables put out by the project team.
There are many more challenging project environments out there, and I am certain more experienced Business Analysts than me have more colorful tales that they could tell about projects and project management that have lost their marbles.
These tales are just a microcosm of how off-balance some projects can be. The moral of these tales is to get Business Analysts to do regular spot-checks and review whether the project environment is meeting the objectives that a Business Analyst envisioned when they were hired. This is especially the case if project management isn’t interested in rectifying these maladies in which event a Business Analyst urgently needs that career re-evaluation.