Red Flags in Project Management

Red Flags are Risks in Project Management

Some weeks ago, Twitter was all abuzz with these ‘Red Flag’ memes. They were hilarious. They touched on so many topics from relationships to marketing, to careers, to TV shows and so much more. People found a funny way to vent and address things they found mildly AND hugely annoying. And I thought… ‘Hey! There are a lot of red flags to look out for in my PM world. Let me share this with some people!’

And here we are. With a project management twist, here are some annoying things we see as project managers that really shouldn’t be overlooked. So, to my fellow magicians out there, I mean, Project Managers, here you go!

Sometimes being a PM can look like being a ‘Debbie or Dennis Downer’ (sorry Debbie; Sorry Dennis). Why do I say such things? Well, because assessing your projects, means assessing risks BEFORE it’s too late. Each project has points of failure. Having only ONE identified point of failure? I’d have to challenge you on that one. Why? Because I’m pretty sure that ONE point of failure can and will cause a domino effect. So, let’s get to analyzing and see where the potential areas of concern can be.

I typically start from the top and work my way down. Meaning, my initial purview is at the project level to see if there are any impacts with resources, tools, access, security, schedule, quality, expectations, scope (in and out), dependencies, and budget. From there, I’ll work with my project leads to discover or uncover other points of failure in their areas of responsibility (most times a system or process level). This level of detail early in the project and throughout will help to mitigate and shake out many areas that can cause surprises later on.

When I’m managing a project, a constraint and a boundary are the same to me. They both are interpreted as potential risks or as potential issues. Typically, there are constraints to consider (time, cost, scope) because an impact in one area is relative to the impact in another, which impacts the overall quality of the project. Each of these areas will have a constraint or a boundary you must work within. At the beginning of each project, it’s imperative to call out and define all constraints.

Example: Time = the timeframe of when the project must be completed. Cost = the budget you must work within. Scope = the thing you are delivering.

BONUS: Stakeholder satisfaction which accounts for the perceived success or failure of the project. This ‘constraint’ focuses on their expectations on how this is done and more importantly, how well things are done. And that includes your interaction with them, your expectation from them, their role and overall impact, as well as how they perceive the value of the project once it has been delivered. How do you work within that constraint? Hint: Interview your key stakeholders and learn what they expect, their interest, as well as their success factors.

Every project has a constraint or boundary. At every stage of the project, the constraints must be assessed. It is most important to identify and expand on the constraints during initiation and discovery. This will naturally flow into risk management. Therefore, any project that does not have identified constraints is not really painting the picture of what you’re working with. Plus, how else would identify value and progress if you don’t have a baseline.

Huh? When I hear this, I cringe. The very nature of a project is to introduce change. If not, then it’s not a project but operational support for a set of tasks done by systems or people.

Change management considers the impact across people, processes, and technologies. Change management must directly address these impacts. There are typically two types of change management on projects. On technology projects, there will typically be a change management process that defines how technology will be implemented upon ‘go live’. You’re either promoting code to different environments with net new functionality or you’re integrating code with existing functionality in which case, our tech gatekeepers will want a ‘CR’ – change request to release across systems that ultimately will be released into ‘production’.

Then there’s organizational change, which is impacted by technology or process changes as well as ‘people’ changes. This is the most underestimated part of projects. What will this technology change do to existing processes, how the people work, and how our customers will be impacted.

A carefully planned change management process early on can uncover points of failure, risks, and readiness for major and minor initiatives that impact on a departmental level and even across the organization. I have seen projects change a particular process but when further analysis was complete, it was determined that an entire department needed to be eliminated and a new department created with entirely new skillsets brought in. An ENTIRE department.

This may seem like a no brainer. However, I cannot tell you how many times in my career I’ve seen this happen. This typically is due to either lack of planning or an unexpected event. With these uncertain times, it is critical and sometimes even crucial to ensure that key resources are available throughout the duration of the project. What does this mean? Prepare for the unexpected. Budget for the unexpected. Mitigate with budget AND resources.

Where possible, you’ll want to ensure that there are people available who understand and can pick up work in the event of unexpected events such as illness or other external factors. You may say that it is not often feasible. Here’s the hard truth: As an organization, having ONE single resource to house CRITICAL knowledge does a disservice to said resource as well as the organization. Cross training, knowledge transfer, and backup plans are needed in all cases. Building strong teams is a strategy for success in any organization. We tend to think this is a luxury. However, with the changing environment, it’s crucial for strategic goal readiness and preparedness.

Let’s face it – TRUE agile means dedicated teams and resources. IF this fundamental criterion is not met, then you’re not agile. You’re probably agile adjacent. In my world, that means, you take the best of these principles and put them to use for your initiatives. It’s important to set expectations when running any methodology. If it’s a hybrid, then say so.

Setting expectations will help to add to the success of any project. Once you state that you’re agile, you’re committing to a full methodology that promises to deliver in a certain manner. The expectation will be to live up to the commitment of sprints WITHOUT the constraints of resources being shared across projects… you’re committing to the team being laser focused on ONE thing and that is THE PROJECT AND ITS DELIVERABLES.

As a Senior Project Manager, I’ve had my share of contracts to read and provide input on. And in my career, I’ve come across quite a few contracts that did not explicitly detail deliverables. This is a major red flag that I’ve immediately pointed out and suggested recommendations. When hiring a partner to help with your goals, you must hold them accountable for the work to be done. Deliverables can be in the form of documentation, systems, modules, training, support, designs, development and much more. Whatever is being worked on or supported will in most every circumstance, produce an outcome or artifacts to support an outcome. Those are the deliverables you’d want to document. If not, how do you know you’re getting what you expect and when?

It’s never a good idea to go into a contract with a big bang delivery with one date that specifies the end of the contract. Here’s why. How do you know if you have everything you need to fulfill the objectives? How will you know if you’re on track with the activities to get to your goal(s)? Project deliverables are a vital component in any contract. If you see that there are no deliverables in a proposed contract, raise more than an eyebrow and a flag… ring the alarm because another project is dying.

A project sponsor does more than pay for a project. A project sponsor should be your champion.

Being a lone project manager is no fun and can be downright stressful. A project champion is needed for any project and a project steering committee should not be seen as a nice to have but a necessity, regardless of the project methodology used.

Key stakeholders should be identified and assigned responsibilities when it comes to supporting the project and its team. The stakeholder or stakeholders can be your point of escalation when support is needed to remove blocks at higher levels. Leading a project successfully can only be done when there is support from the top and sides.

Every project or initiative typically fits into the organization’s or department’s overall roadmap or objective. It is only fitting that there are stakeholders or a stakeholder with strategic interest who would help to support the initiative from all angles.

Don’t go at it alone. Find your champion(s) if none have been identified.

I’ve never been on a project where the budget isn’t analyzed and reviewed monthly. When it comes to multi-year projects, I believe there is even more scrutiny especially when the budget is coming from multiple departments. It’s important to do a pulse check quarterly to ensure that goals are being met and any significant KPIs are met and discussed.

Here’s why… Business is changing rapidly in this new climate of uncertainty. Companies who are staying ahead of the game are actively and intentionally looking for new ways to serve and remain relevant. Objectives and goals set in Q4 for the next year, may change in Q2. Worst case, objectives set for one department that had alignment with the other on your project, may be shifted. This shift could mean a change in budget and/or resources. This change could signify a disruption or pivot to your project. Complexities are added when there is a multi-departmental investment into any initiative.

Every project comes with its own set of risks and no two projects are the same. However, what’s common to every project is RISK and risk management. Good risk management involves looking out for red flags in what’s being said, not said, implied, done, and not done. Be on the lookout for anything that sounds and looks a bit off. It’s best to question anything that doesn’t feel right than to let it go and having it end up biting you later. Your Project Manager red flag radar will serve you well.