Project Management Lessons from a Director of Operations
Before She Led Operations, She Led Projects
Before Tara became LEAD2’s Director of Operations, she spent years managing projects, aligning stakeholders and keeping delivery challenges from becoming crises.
Those experiences did more than shape her career. They also influenced how she leads today.
We sat down with Tara to discuss the project management lessons she would share with her younger self. The conversation quickly became a collection of practical insights, familiar frustrations and a few “what not to do” moments that will probably feel very relatable.
Because projects are rarely completely smooth sailing, the same challenges tend to appear in different forms, across different teams and, occasionally, in meetings that could have been emails.
Whether you are a Project Manager, Business Analyst, Project Sponsor or anyone else involved in project delivery, you may recognise a few of them.
1. Treat change management as part of project delivery
Change management: “Change what?”
What is one part of a project that is still too often underestimated?
It is often treated a little like the vegetables on a dinner plate. Everyone agrees it should be there, but it is usually the first thing pushed aside when time, budget or resources become tight.
Teams can see change management as an unnecessary cost or a drain on project resources. What gets overlooked is the role it plays in helping people understand and prepare for what is coming.
When stakeholders feel out of the loop, uncertainty grows. People may become anxious about how the change will affect them, worry about their roles or hold back information that the project team needs.
Change management gives people a map before the journey begins.
When project teams inform and involve people early, those people are more likely to support the change, participate openly and become advocates for the outcome..
Change management and business readiness should therefore be considered from the beginning of the project, not added shortly before go-live.
In other words, change management is not the side dish. It is part of the main course.
2. Reduce dependency on individual subject matter experts
The indispensable SME
What happens when too much business knowledge sits with one person?
Most businesses have at least one subject matter expert, or SME, who seems to know everything: the process, the history behind it and the workaround that no one has documented but everyone somehow uses.
These people are invaluable. The risk comes when the whole project starts relying on them like a human Magic 8 Ball, with every question, decision and clarification needing to go through the same person.
We have seen this play out before. The SME is often balancing business-as-usual responsibilities while supporting the project. Their calendar is full, their operational workload has not disappeared and the project team is left waiting for the one person who can confirm what actually happens behind the scenes.
The answer is not to stop relying on SMEs, but to make sure they are not the only people holding the map.
Cross-training, proper handovers and regular knowledge sharing sessions can help spread their expertise. Key processes should also be documented in up-to-date Standard Operating Procedures, giving Business Analysts a clear starting point without requiring a round of corporate detective work.
The SME can still be the business superhero. They just should not be the only person with the secret password.
3. Use the current state as a starting point, not the destination
The as-is: “We’ve always done it this way”
What is a common mistake when planning the future state?
Spending too much time trying to recreate the past.
The “as-is” describes how the business, system or process operates today. Before changing an application, introducing a new operating model or moving to a new administrator, the business needs to understand this current state.
But it also needs to be clear about what it is trying to achieve.
If the existing process is full of manual steps, workarounds and “we’ve always done it this way” decisions, there is no point in rebuilding the same maze in a shinier system.
Current-state analysis is important, especially if there are gaps in business knowledge. It helps uncover risks, dependencies, controls and pain points. However, it should be the starting point for future-state design, not the final blueprint.
Where does automation fit into the future state?
We often see two extremes: On one side are SMEs who have worked in the same way for 10, 15 or even 20 years and struggle to imagine doing it differently.
On the other is the ambition to automate absolutely everything, regardless of the time, cost or small miracle required.
Automation should solve a real problem. It should reduce errors, lower risk and free people up to focus on more valuable work. It should not be pursued simply because automation sounds more modern.
It also does not automatically mean reducing the size of the team.
When you are unsure whether something should be automated, step back and do a feasibility study. Look at the effort involved, how often things go wrong, what it is costing the business and what impact the change could have further down the line.
Even reducing manual work by 20% can make a real difference.
The lesson is simple: understand how things work today, but do not give every old workaround a new home.
4. Understand vendor capabilities before implementation begins
Vendor selection: “The promise ring”
What should businesses understand before choosing a vendor or application?
What the solution can actually do, not just what it promises to do in the sales pitch.
Vendors are understandably focused on winning the business. The demo looks polished, the answers sound reassuring and it can feel like the perfect match.
Then the contract is signed, implementation begins and you discover the promise ring may not come with the commitment you expected.
When the vendor’s capabilities and the business’s needs do not align, the result is usually frustration, change requests and additional costs no one was particularly excited to find in the budget.
A strong RFP process can help reduce this risk. We explore the difference between RFIs and RFPs, and when to use each, in our article on asset management vendor selection.
Where does automation fit into the future state?
Before selecting a vendor, the business should complete an end-to-end analysis of its current functionality, requirements, operational dependencies and future needs. It should then test whether the proposed solution can support or improve them.
In complex financial services environments, even a seemingly small functionality gap can affect downstream processes, controls, reporting and client servicing.
This is why vendor evaluation should go beyond a polished demonstration. The business needs to understand what is available as standard, what requires configuration, what requires custom development and what the system cannot support.
And have you ever seen a vendor selected even though they did not come first in the RFP evaluation?
We have.
There may be valid reasons for that decision, but they need to be clearly understood and documented, and weighed against the risks already identified during the evaluation process.
Otherwise, the project team may spend implementation dealing with the same gaps the selection process had already highlighted.
The lesson: choose the solution based on what it can deliver, not simply on how good the promise sounds.
5. Hire the right expertise for the project
Hiring the right expertise: “Jack of all trades”
Does industry experience really matter when hiring for a project?
Strong Business Analysts and Project Managers can move between industries and adapt quickly. Good delivery skills, structured thinking and stakeholder management are valuable in almost any environment.
However, some projects need more than strong general delivery skills. They need people who already understand the industry, its terminology, its regulatory context and the challenges that tend to appear along the way.
We sometimes see businesses trying to save money by hiring a generalist for a highly specialised project. The saving can disappear quite quickly when the team spends months learning the basics, revisiting decisions or discovering risks that an experienced specialist would have spotted sooner.
Industry experience also helps teams ask better questions. A specialist is more likely to spot when a requirement is missing detail, an assumption may not work in practice or a decision could cause problems later on.
Paying a little more for the right expertise upfront can save a great deal of time, frustration and cost later.
It is a bit like asking a mechanic to cook dinner. They may be highly skilled but those skills are not necessarily the ones you need in the kitchen. You would probably still prefer the chef. And if you happen to be a mechanic who can cook, good on you, but you get the point.
The lesson is simple: a jack of all trades can add real value, but when a project needs specialist knowledge, make sure you have a master of the right trade.
6. Build genuine collaboration across the project
Collaboration: “Wait, when did that happen?”
What does good collaboration actually look like on a project?
Collaboration is one of those words everyone uses, but not everyone practises.
Most people have sat in a meeting and realised, halfway through, that an important decision was made somewhere else, the project has changed direction and no one thought to mention it.
Suddenly, you are trying to work out what happened while everyone else carries on as if this was always the plan.
There are no solo champions on a project.
The business, project team, vendors and stakeholders all need to work towards the same outcome. When teams start working in isolation, it can quickly create an “us and them” mindset, blurred responsibilities and far too many meetings to get everyone back on the same page.
Good collaboration starts with clarity. Everyone should know who is responsible for what, how decisions will be made, where information will be shared and who needs to be part of each conversation.
Teams need to feel comfortable raising concerns, challenging assumptions and sharing information early, before a small issue becomes a much larger delivery problem.
At LEAD2, we are often told that we work well with different stakeholders. That comes down to keeping the end goal clear, building trust and treating everyone as part of the same team, even when we do not always agree.
The lesson: Collaboration is not simply inviting everyone to the meeting. It is making sure they understand what is happening when they get there.
7. Be honest and realistic about the project status
Project Status: Still green?
What should green, amber and red actually mean?
Ah, the project status meeting. That wonderful weekly ritual where everyone gathers around a traffic light and tries to decide whether the project is actually green, or whether we are simply feeling optimistic.
Over the years, we’ve seen more than a few projects proudly reported as green when, in reality, they were somewhere between amber and bloedrooi.
A Project Manager should not set a project’s RAG status based on how they feel that particular day.
Not: “We had a good week, so let’s keep it green.”
Not: “Nothing has completely fallen apart yet, so technically we’re still green.”
And definitely not: “I don’t want to take a red status to Exco.”
Base it on facts. Have deliverables been met? Are delays recoverable? Is the critical path affected? What risks or blockers have emerged, and do we understand their impact?
The danger comes when a project stays artificially green because nobody wants to be the person bringing bad news upstairs.
Green. Green. Still green.
Then, apparently overnight, red.
Except it was never overnight. The warning signs, delays and unresolved issues were already there. Someone just didn’t want to colour the box red.
A Project Manager who tells Exco, “We have a problem, here is the impact and here is what we are doing about it” builds far more credibility than one who keeps everything green until the problem becomes impossible to hide.
The lesson: RAG status is there to communicate reality, not confidence. Use the evidence, raise concerns early and be transparent about what they mean for delivery.
What these project management lessons have in common
These project management lessons were shaped through years of working with different teams, businesses and delivery challenges. They still influence how Tara leads operations today.
Her experience is also a reminder that leadership is built long before the title arrives.
It develops through the challenges you solve, the questions you learn to ask, the people you bring with you and the lessons you carry from one project into the next.
The systems, organisations and circumstances may change, but the fundamentals of successful project delivery remain remarkably consistent:
- Involve people early.
- Share business knowledge.
- Challenge inefficient processes.
- Test vendor promises properly.
- Bring in the right expertise.
- Work towards one shared outcome.
- Be honest and realistic about the project status.
And, where possible, avoid the meeting that really could have been an email.
FAQs about project delivery
What are the most common project mistakes?
One of the most common issues we see is underestimating the importance of change management. It’s a critical component of any major project whether a large-scale transformation or a system migration, yet it’s frequently overlooked. Project Managers and Change Managers serve distinct functions, and these roles should be kept separate. When everyone understands the journey and the intended outcome, resistance naturally decreases.
Another frequent mistake involves projects with multiple workstreams, where teams fail to identify the touch points between streams what the dependencies are and who owns each interface. Mapping out the full journey upfront helps ensure no critical process or gap is missed along the way.
A third common pitfall is an excessive volume of change requests. This usually stems from one of three causes: requirements that weren’t clearly defined from the outset, insufficient transparency from vendors about their actual capabilities, or stakeholders who don’t fully understand the requirements because they were never properly reviewed and signed off.
Why is change management important in a project?
If people aren’t on the same page, how do you expect them to participate in a project?
Imagine telling a company you’re doing a migration, giving them zero context, and then expecting them to hand over requirements and just fall in line. That’s not how it works.
Change management needs to be there from day one. Not halfway through. Not once things start going wrong. From the onset.
People need to understand the strategic objectives of the project, who it impacts, how it changes their roles in the future state, and what they need to do to succeed in that new state. There are plenty of change management methodologies out there, but at the end of the day, it comes down to this: clear, constant, transparent communication. Make sure the people impacted feel supported and heard, and you’ll cut resistance dramatically.
And stop confusing change management with project management. Yes, they overlap sometimes. No, they are not the same role.
What is the role of a subject matter expert in a project?
When we talk about SMEs on a project, we’re often talking about two different types of people. At Lead2, we have SME project resources: Business Analysts and Project Managers who are subject matter experts across a range of project types, including TA migrations, regulatory projects, and RFP advisory work. We add value from the start by asking the right questions. Because we’ve delivered these types of projects multiple times, we know where the gaps typically are and what needs to be done.
From a business point of view, having SMEs within the organisation is also key, particularly when it comes to understanding the as-is state. However, SMEs can sometimes derail a project, especially if they’re unwilling to share their knowledge. They can also struggle to see the to-be state, often because they fear what it means for their role.
Businesses need to plan for continuity. It’s fine to have SMEs, but no single person should hold all the knowledge. All processes should be documented and reviewed regularly (at least annually) to prevent over-reliance on any one individual.
Why should businesses document the current state before designing the future state?
We encourage clients, before making any strategic changes, especially application changes to undertake a 6-12 week advisory piece of work where we review the current as-is processes. This allows a consultancy to identify gaps, manual processes, overlapping roles and processes, and system constraints. It also helps determine whether the strategic outcome they’re aiming for will actually be achieved by making these changes.
Understanding the current state is essential to shaping and improving the future state. You don’t want to move to a new application and simply carry over the same pain points and struggles from the current world, if that happens, there’s little point in moving at all. That said, the current state should inform the future design, not be automatically recreated in a new system or operating model.
What should a business assess when choosing a vendor for a new application?
At Lead2, we stay agnostic regardless of which vendor the client ultimately chooses. What we do is help guide them through the RFI/RFP process to ensure their decision covers their actual needs and business requirements, eliminating any gaps that might sneak in once the decision has been made.
It’s important that a vendor’s functional capability meets your core business requirements, in other words, your “must-haves.” If a vendor can’t meet your must-haves out of the box, they need to propose a solution that will and the costs involved. Businesses also need to be realistic: you can’t expect a Rolls Royce while only budgeting for a Polo Vivo. Don’t blur the line between your must-haves, nice-to-haves, and wishlist items, be clear and honest about what’s actually essential.
Beyond functional fit, businesses should assess the vendor’s technical fit, implementation approach, industry experience, integration requirements, limitations, cost, and ability to support future needs. All of these factors should be evaluated against clearly documented business requirements.
What do we look for in Project Managers at LEAD2?
At LEAD2, although we would love every project to be green, we know from experience that this is not always the case. Circumstances change, risks materialise, and priorities shift. Successful delivery is not about keeping every project green regardless of reality; it is about understanding the true status of a project, recognising when circumstances change and knowing how to respond.
We are also looking for PMs who are close to the content, not just managing timelines from a distance, but genuinely understanding the detail of what’s being delivered. They get involved, ask questions, and are team players who are willing to get their hands dirty when needed.
In interviews, we are interested in how candidates approach projects when things do not go according to plan. We want to understand how they identify and manage risks, resolve issues, respond to delays or dependencies, adapt plans where necessary and communicate clearly with stakeholders. A strong Project Manager should be able to explain not only what happened on a project, but how they assessed the situation, what decisions they made and why. Projects rarely follow a perfectly predictable path.
Is your next project asking the right questions?
Successful transformation requires more than a good solution
It requires clear requirements, informed decisions, the right expertise and a team that can bring the business, technology and people together.
LEAD2 supports organisations through advisory, transformation and project delivery, from early analysis and vendor selection through to implementation and business readiness.
Speak to our team about your next project.
Discuss your project