Author: Paul Gouws

We all had that one project—the one that made us question our career choices, doubt our sanity, and consider a swift exit from the world of project management. It took me a moment to recall mine. The late nights, the endless meetings, and the creeping feeling that I was steering a ship into a storm without a compass. Yes, that project—the one that left me pondering whether I had accidentally signed up for a one-way ticket to project manager purgatory.

But here is the twist: I survived. And not just survived—I emerged wiser, battle-tested, and armed with insights that no textbook or certification could provide.

So, why am I sharing this? Because somewhere out there, another project manager is teetering on the edge, contemplating surrender. Maybe, just maybe, my journey can offer a glimmer of hope—a lifeline to keep them afloat.

 

Lessons from the Trenches

What follows are my personal revelations from years ago, working on that one project we all know. I am not advising or guiding here; I am merely sharing my experience throughout the life cycle of the project. You might share similar experiences or see something completely new. Luckily, the project world has evolved over the years, but nothing can match up to the real project experience. Hard-won tricks, battle-tested strategies, and yes, confronting the dreaded burnout head-on.

 

The Burnout: A Dangerous Undertow

Now, let us delve into the next chapter of my journey—the one where burnout took center stage. It was not merely a buzzword; it functioned as a silent assassin. Picture this: nights devoid of sleep, days fuelled by caffeine, and a to-do list that multiplied faster than rabbits in spring. I had been there, but I was fortunate to be surrounded by top talent, including a mentor who guided me throughout. Together, we navigated the treacherous waters of that one project, skillfully avoiding the siren call of burnout.

As a naturally spirited individual, I have always approached life with unwavering positivity. To me, there existed nothing on this earth that could not be rectified, no challenge too daunting, and no issue too tangled to unravel. I excel at solving problems, whether they are complex or simple—until one day, I hit a wall. Wait, was I failing at something? Impossible. I resolved to try harder next time, right? But two weeks later, another failure. It dawned on me—I was caught in a loop, akin to a sales pitch endlessly replayed during an infomercial:

• Are you perpetually failing on a project?
• Are you working extra hours and days to evade failure?
• Are you feeling utterly worthless?

 

These symptoms became my daily companions. I would gather myself overnight, only to wake up to the same emotional hangover the next day. I soldiered on, convinced that this was normal and that I would eventually power through. But stress insidiously crept in—I smoked more, drank more, and hoped it would all magically vanish. The harsh truth? It did not. Burnout was lurking, and I did not even recognize it until it had me in its grip six months down the line.

Burnout does not announce itself with fanfare. It tiptoes in, whispering exhaustion into your bones. And I, the sprinter—the one who thrives on daily victories—was suddenly running a marathon. You see, there are sprinters and marathoners in the project management world. Sprinters excel in short bursts, while marathoners maintain a steady pace over the long haul. Me? I was a sprinter on a six-year project. Sure, you can break down a colossal project into smaller goals, but it is not sustainable. The sprinter craves daily wins, not a development cycle that spans years. The funny thing is, I only realized that I had burned out after the burnout had already taken its toll, which could be six months down the line. The crucial lesson? Recognize burnout while it is happening, not after the fact.

Below were the three fundamental areas that I needed to improve on to survive:

• The first thing I did was to start exercising; even if you just run for a bit, it needs to be for a minimum of 40 minutes at least. If you are in the habit of exercising, just check that you are not swapping out your exercise time for work. There will always be work, so making time for exercising will not cause any harm.
• Watch full-on action movies with a lot happening in them at full volume.
• Replace bad coping mechanisms with healthy ones.

 

Strategic Funding Approach for Ambiguous Requirements

In the realm of project management, grappling with vague requirements is a familiar challenge. When faced with this uncertainty, consider a strategic funding strategy that not only brings clarity but also optimizes your company’s resources.

 

Phase-Specific Funding

Rather than seeking the entire project budget upfront, focus on securing funds exclusively for the requirements phase. By doing so, you establish a clear boundary for the initial work.

Once the requirements phase is successfully completed, you can confidently request additional project funds. This approach minimizes financial risk and aligns funding with tangible progress.

Yes, I did hear we are following agile, agile, agile, and we will request funds as we go. It is all good… Please add all the funds that you have spent so far and link them to what has been delivered. I will stop there.

We followed a hybrid approach here, waterfall the requirements, and then you can follow any framework or methodology you prefer for the rest of the phases. We monitored a few aspects of the budget continuously:

• Approved Budget – How much money did the company approve for the project or phase?
• YTD actuals spend – How much money have you spent already to date?
• YTD planned spend – How much money are you planning on spending for the remainder of the project?
• Quality Check Spend – How much money did you spend, according to the finance team?
• Variance – How much money will you have left at the end of the project?

Oh, and on a side note, do not think you will be called a hero if your budget ends up in a big positive, that is a sign of poor planning. We worked on a 5% variance either way to be good, and I thought it was fair.

 

 

Poor Planning: The Quicksand of Project Execution

Let us discuss the BRS—the unsung hero of projects. BRS stands for Business Requirements Specification—a fusion of the BRD (Business Requirement Document) and the BSS (Business Specification Spec). Think of it as the Rosetta Stone that translated business needs into design blueprints. We hired Business System Analysts instead of your run-of-the-mill Business Analysts (BAs) to save on funds. The BSA crafted an all-in-one document, weaving requirements and designs into a seamless tapestry. We did encounter scope creep where the business would sneak in extra requirements, citing the “we missed it at the start” clause.

Armed with the BRS, we generated work packages—bite-sized tasks that our team could chew on. It was like breaking a colossal chocolate bar into manageable squares.

We tracked the progress of each BRS in the war room (you will hear about this later) with a card like this:

 

Advertisement
[widget id=”custom_html-68″]

 

Development Without Design

Imagine constructing a house without blueprints. Initiating development without clear designs or requirements documents is akin to erecting a skyscraper on shaky ground. It is a recipe for chaos. With the solutions architect on your right and the business analyst on your left, create the as-is and to-be designs, with the plan in the middle—it is that straightforward. The solutions architect must advise you on any risks that might arise as you progress on your project journey, while the business analyst must keep you laser-focused on the customers’ requirements.

 

Untamed Timelines

Committing to timelines without consulting your team is like setting sail without checking the weather forecast. A big no-no. Involve all stakeholders, assess risks, and adjust your course accordingly. I am not talking about adding a buffer based on your experiences; I am just saying that if you are not a developer, then do not put estimates down for a new website to be built; ask the expert.

 

The War Room: Where Strategy Meets Unity

The term “war room” conjures images of battle-hardened generals huddled over maps, plotting tactical maneuvers to outwit the enemy. But in the context of this project, it is less about combat and more about collaboration. Allow me to demystify the war room—a sacred space where ideas clash, plans take shape, and unity prevails.

 

As a die-hard team player, I thrive in the war room’s charged atmosphere. Why? Because it compels us to gather, discuss, and align. Team meetings become our compass, pointing us toward shared goals. Unity emerges—the kind that transcends job titles and department silos. We are no longer lone warriors; we are a battalion with a common mission.

Picture it: four walls, each adorned with a whiteboard. This is your canvas. Now, let us map out the headings—the battle plans—inspired by the V-Model of testing:

• Low/High-level Designs: The blueprints. Architects, developers, and UX designers converge. We sketch, iterate, and breathe life into concepts.
• System/Business Requirements: Here, we decode the client’s vision. What problem are we solving? What outcomes matter? These requirements anchor our journey.
• Development: Our troops mobilize. Timelines, milestones, and resource allocation take shape. It is the heartbeat of execution.
• PDT/AIT/SIT/UAT: The litmus test. Testing engineers scrutinize, validate, and ensure our creation stands tall.

Sounds straightforward, right? But remember, the war room is not just about strategy—it is about camaraderie, resilience, and the art of turning chaos into cohesion. In the maze of project management, requirement cards served as our guiding leads. But these are not ordinary cards—they are color-coded keys to complexity, dependencies, and progress.

We created these cards to help us keep track of how each item is progressing. Each of the cards will represent a specific requirement, and each card will have the following on it:

• Traceability number – Once you have completed your designs and have them up in your war room, you will be able to number every change required to the design. That number will be inserted in this block so that you have traceability between the requirements and the design. This card is only for business requirements, not interface requirements; there is a different card for interfaces. This means that when you walk into the war room, you can easily spot what part of the system you are touching and where it is based on the design.
• Dependency number – Some items are codependent. They need each other to thrive. This box holds the magic number—the item that must precede another. Dependencies, untangled.
• Phases from left to right – BRS, DEV, SIT, UAT, DEPLOYED. depending on which team currently owns this ticket, the indicator will move from BRS to DEV or to whichever stage it is in now: same ticket, different owners… We were busy with a custom version of Kan Ban, or whichever version you prefer… Survival was the key word here.

 

Something like this:

 

Card Color System –

• Red Card The crimson flag. These cards represent the most complex items—the uncharted territories. None of your team members have ventured here, and their experience is limited. Brace for challenges.
• Amber Card: The caution signs. These items have been glimpsed by 1 or 2 resources. Familiar, but not routine. Approach with vigilance.
• Green Card: The Oasis. These cards signify easy items—your team has danced this tango before. They have mastered it and executed it multiple times. Smooth sailing ahead.

Remember, this card is exclusively for business requirements. Interface requirements have their own dance floor. Keep them separate, like parallel universes.

So, when you step into the war room, eyes scanning the system’s blueprint, these cards whisper: “Here is where you tread; here is where you leap.

 

Development (Crazy Stream)

Where Requirements Take Shape

• The Quest for Requirements: Picture it—a developer picks a ticket and vanishes into the coding abyss, only to reappear days later, battle-worn and seeking aid. Sound familiar? We have all danced this tango. But fear not; we devised a remedy.
• The Senior-Junior Alliance: We paired senior developers with their junior counterparts. Mentorship duets. It eased some challenges, but yes, development time took a hit. Still, the defect rate waned, and after three months, we found our rhythm.
• Scope Creep and the Unseen Impact: Alas, scope management is our Achilles’ heel. Product owners, blissfully unaware, kept adding tweaks. “This button’s off,” they would say. “That field’s too snug.” The result? A deluge of tickets drowned our team.
• The Cricket Field Strategy: Desperation breeds innovation. So, we turned to cricket. A whiteboard became our field. Each developer chose their cricket idols. The rules? For every ticket completed, a run is scored. But for every defect found, a wicket fell. Morning stand-ups played out on our “cricket field.” The results? Astounding. Quality soared, spirits soared, and our team hit sixes daily.

The Peer Review Revolution

• Passing the Baton: As soon as a developer finished, they would pass the baton—the code—to the next in line. Peer reviews ensued. Quality improved, and knowledge flowed. It was our secret weapon against mediocrity.

 

User Acceptance Testing

More than halfway through the project, we decided to permanently move key users into the project team permanently. This ended up being the right call. As it was a complex project, by the time we got to user acceptance testing, the users permanently assigned to the project could act as super users in the UAT environment and did assist greatly with fast-tracking any testing that needed to be done. We would also assign a business analyst and a developer to each UAT session to resolve any questions or concerns on the spot.

The second value added to assigning permanent business users to the project for the duration is that they are part of the team, and they will fight for the project in other business forums. We did have a big gap between the project team and business when we started, but this move changed it really into a positive.

On a big, complex project, it is easy to get stuck in the testing cycle due to the business aiming for a bug-free system. There is not one single application that is bug/defect-free; if there is one that you know of, they are not sharing it with you. Coach or guide the business users to log defects but also prioritize them based on financial, reputational, and legal impact. Well, this is what we used. Low-level cosmetic bugs should not stop you from going live. Get a product out by fixing all the high and medium defects, and once live, the low defects can be fixed. But it’s super important to get something out. These days, they call it an MVP (Minimum viable product); we just call it and get it into production so that we can start making a difference.

 

The Operational Handover post went live.

Like the UAT team, it worked best for us to include one or two operational resources permanently on the project, as they would end up supporting the product once it was live. They also assisted in documenting all the information in the operational handover document. You will not be so lucky to do this on all the projects, but at least put it in place on strategic projects.

 

I trust the above will give you motivation to continue your project management journey and never give up.