Delivering: Abstract Project verses Business Product

Posted on by Mark Myers Leave a comment

In the realm of project management, there’s a recurring tension between delivering a project as a neatly packaged entity (basically a number of signed-off documents from a project manager’s perspective) and delivering a project as a truly useful feature for the business.

Now on one side, pure project managers often focus on precise documentation, formal ownership, and clear boundaries. This approach can streamline budgeting, clarify responsibilities, and minimise risk, particularly helpful if something goes wrong.

On the other side, managers with a business or operational background tend to prioritise tangible outcomes that meet real-world needs, even if this requires a less orderly process. This style, while potentially more chaotic, can often produce better, more enduring results for the business.

Both approaches have clear benefits and drawbacks. A strict adherence to process and paperwork can ensure compliance, financial clarity, and an “adequate” solution that meets requirements; this gives you a sound basis to claim payment against goal-based contracts.

However, it may not fully address real business needs.

Conversely, focusing purely on delivering the best business outcome can lead to scope creep, cost overruns, and never getting a sign-off on the project, but it might also generate a more valuable end product that truly benefits the organisation.
In truth, I like a bit of column A and a bit of column B on this. You try to be as flexible to the business needs as you can while staying within your remit, and to this end, if you are honest with the business and say: “Look, we were made to sign this contract with these deliverables by our mutual bosses, and if we don’t do that, we won’t get paid. So please, can we do those first and then come back to the extra and different stuff you want?” it’s very often a good place to try balancing from.

Corporate term: “Busking for Time”

Posted on by Mark Myers Leave a comment

Definition:

Busking for time is the period of waffle or nonsense people, (normally politicians) talk in the hope that a solution or idea will come to them.

Explanation:

While this is mainly a journalistic term used when talking about political discussion, it works just as well for corporate conference calls.
When taken off guard or when concentrating on something else, we all fumble for the right words for an answer but when we are unwilling to admit this and try and fill that gap with nonsense, then we are “busking for time”.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

 

Working Well with Your Corporate Peers: The Basics for Beginners

Posted on by Mark Myers Leave a comment

 

This post is because not only is my own son solidly working his way up the corporate ladder, but I have been lucky enough to recently do work experience with some new starters in the corporate world, and felt that the tips I gave them would work well written down.
Ever notice how some people treat their coworkers like one-dimensional obstacles rather than human beings on the same team? It’s more common than you’d think.
Yet, in most professional settings, you need the help of peers, managers, and subject-matter experts to get things done. Here are a few foundational tips to ensure you build strong, collaborative relationships with those around you, without resorting to office politics or generally being unprofessional.

1. Don’t Build Empires

What does “empire-building” look like? It’s when someone hoards responsibilities, people, and power to climb the corporate ladder at any cost. Sure, it might seem like a fast track to the top, but it usually backfires in the long run.
Why avoid it? People will notice if you’re grabbing for power or credit, and they’ll start throwing up roadblocks. A lot of energy that should go toward delivering results ends up wasted on infighting.
Better approach: Show that you’re there to deliver on your tasks and goals, not to trample others. Collaboration is more sustainable and garners respect.

2. Publicly Acknowledge Help

Why is this important? When you’re working across departments, you’ll rely on others for information, extra resources, or simply the benefit of their expertise. If someone helps you, be vocal about it.
How to do it: At the next team meeting, in reports, or in a conversation with your manager, highlight the support you received. This makes your colleagues feel valued and more likely to help again.
Bonus benefit: You won’t come across as someone who takes all the credit. Instead, you’ll earn a reputation as a team player who appreciates contributions from others.

3. Keep a Fair Tally of Favors

In some places (like in England), there’s a social custom of buying rounds of drinks instead of everyone just buying their own. People mentally keep track of whose turn it is. The same principle applies in the workplace when it comes to favors.
What this means: If you receive help, be prepared to return the favor down the line.
Why it matters: No one likes a freeloader. If you only take and never give, you’ll quickly gain a reputation for being self-serving, and people will be less inclined to support you in the future.

Final Thoughts

Working effectively with your peers isn’t just about delivering projects on time; it’s about fostering an environment where people genuinely want to help each other succeed. By avoiding empire-building, openly acknowledging the help you receive, and keeping fair tabs on favors,
you’ll cultivate relationships that propel everyone forward. At the end of the day, its wins all round.

Corporate term: “Meeting Cuckoo”

Posted on by Mark Myers Leave a comment

Definition:

A “Meeting Cuckoo” is a manager or project lead who, upon being invited to another team’s meeting, appropriates the discussion to prioritize or promote their own project’s agenda.

Explanation:

Companies often encourage cross-functional collaboration for transparency, efficiency, and resource sharing. In this context, managers or project leads may be invited to attend meetings they are not directly involved with, especially if a topic under discussion overlaps with their own project. Ideally, such invitations serve to streamline communication and ensure all stakeholders have a clear understanding of progress, challenges, and resource allocations.

However, when a Meeting Cuckoo joins a meeting, they will derail its original purpose by redirecting attention to their own priorities. They might use the meeting’s time, resources, and focus to further their projects objectives, rather than contributing value to the host project. This behaviour can cause frustration, lead to conflicts, and dilute the primary agenda of the meeting.

To avoid such issues, a recommended best practice is to make sure they raise items only related to their project only after the main agenda items have been addressed. For instance a well behaved Cuckoo could say, “To save me chasing you separately, could I ask for an update on “Project X” once we’ve covered the main agenda?” This approach ensures that the meeting’s original objectives are preserved while still acknowledging and addressing the visitor’s needs.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

 

Partial data migrations or the danger of the cottage database

Posted on by Mark Myers Leave a comment

 

I’ve dealt with multiple data migrations over the years, moving from one system to another can be surprisingly convoluted, even when you think the process should be straightforward.

One recurring challenge is the temptation to migrate only the “current” or “relevant” data into the new system while stashing historical data somewhere else, like an archive or backup database. At first, this seems like an easy solution.

You move just enough data to get the new system running, and you tell everyone, “If you need to analyze or report on the old data, we have it stored over there.”

But sooner or later, someone needs that historical data for analytics, reporting, or to merge with new information. Because it’s sitting in a separate place, you end up with a small, “cottage industry” of sorts, people who specialise in pulling and analysing the legacy data.

This cottage industry might start small, but over time, new demands arise:

More Reports: Someone wants to combine current and historical data for deeper insights.

Third-Party Integrations: The old data needs to connect with external systems or tools for advanced analytics.

Ongoing Maintenance: The “temporary” archive starts receiving updates, patches, or new data sources.

Before you know it, this cottage database becomes a permanent fixture, growing more complex with each update. It morphs into its own mini data lake, complete with specialised scripts and workflows.

As soon as you try to integrate it back into the main platform or move to yet another new system, you face a new migration project, often bigger and messier than the first one.

This all costs you extra money and extra issues such as:

Hidden Complexity: By storing historical data separately, you create a silo that quickly becomes complicated to manage.

Inconsistent Reporting: Different teams might use different data sources, leading to confusion and inconsistent insights.

Maintaining multiple databases (and the specialised knowledge around them) can be expensive in both time and money.

Lessons Learned

Plan for the Long Haul: Even if historical data seems irrelevant now, plan for a future where you might need to integrate it easily.

Evaluate All Options: Sometimes, a phased or partial migration can work, but do so with a clear strategy for eventually merging the old data.

Streamline Reporting: Encourage a single source of truth to avoid duplicate effort and maintain consistent reporting across the organisation.

Don’t Underestimate Governance: Good data governance from the start saves countless hours and headaches later.

Round up

A partial data migration might seem like a quick fix, but it often creates a “cottage database” problem that can spiral out of control.

By anticipating the need for historical data, and planning an approach that brings everything into one coherent system, you’ll save yourself (and your team) a lot of frustration down the road. Data migrations are rarely simple, but with the right foresight, you can avoid building a hodgepodge of separate repositories that become a long-term drag on your organisation.