Shandra's Insights

Catherine Magazine 2024

This year I was asked by my Alumni ‘Santa Maria’ in Attadale Western Australia to contribute to their annual Catherine Magazine, as in 2024 the focus was around the  students that had chosen a career path in Information Technology. 

As an advocate of encouraging Women to find their passion for numbers and IT, I was given the challenge to write an article titled the ‘The Importance of Women in IT’.  A quick search with Google, and quickly reading articles that had been written by others, I knew I had a challenge to, be different and engaging and actually call to action the next generation of Women in IT.

How I gained the best foundation:

To prepare me for working in IT when women were still being encouraged to study maths.

After leaving Santa Maria, at 18 years old I joined the Australian Signals Corps (Army) where I was tested in both physical and mental endurance, taught discipline at a whole new level and from this life experience I have taken with me in my personal and professional life: nothing is impossible – Just do it… no matter how hard it is just focus on the outcome. Set achievable goals and keep breathing through the impossible times. I also have some amazing memories of the experiences I got to have because of being a soldier in the Australian Army, from spending two days with Prince Charles and Princess Dianna, to working on some amazing projects that had a positive impact on people’s everyday lives.

LinkedIn Articles

Why? Have you asked yourself lately!

Simplicity in the Complex: How Persistence Unlocked What Others Missed

I started my career with a bachelor’s degree in computer science and mathematics. At the time, there wasn’t a “Data Science Degree” as  it is known today, same statistics, just a different stack of coding languages, giving me the skills for being able to think logical, being able to think outside the box to solve business problems. Since then, I’ve spent 20+ years in corporate environments, not on construction sites, but in boardrooms and project rooms where business requirements, exceptions, and frustrations surfaced.

My role was never to swing a hammer or lay bricks — it was to ask the right questions, listen to those with deep expertise, and then transform their frustrations into measurable outputs: metrics, models, charts, and tables that drove accountability and performance.

For the past 18 months, alongside my co-founder who also has over 20 years as a Construction Manager, I’ve applied that same lens to construction. We worked unpaid, in between the jobs that keep the lights on, circling back whenever we could to chip away at a stubborn problem:

Why?

Every platform out there reports on tasks. Every Gantt chart looks tidy. Yet the profit leaks remain.

The answer we uncovered was not in more dashboards or more AI magic — it was in persistence. Sixteen hours of iteration, validation, and refinement. Running the logic, proving it wrong, reworking it, and refusing to stop until the gaps closed.

And here’s the surprise: it wasn’t “rocket science.” It was obvious once seen. The type of solution that makes you wonder: why hasn’t anyone done this before?

The truth is, most teams either:

  • Overthink the problem, chasing complexity.
  • Underestimate the detail, dismissing it as too messy.
  • Or assume it’s already been solved.

But persistence has its own power. As Thomas Edison said: “Genius is one percent inspiration and ninety-nine percent perspiration.”

We didn’t invent AI. We didn’t invent construction workflows. What we did was connect them logically, at a level that mirrors how work is actually done on-site, not just how it looks on paper.

I won’t publish the exact logic here (sometimes simplicity needs protecting), but I will say this:

  • When you listen carefully to experts.
  • When you persist beyond the obvious iterations.
  • When you refuse to stop at “good enough.”

…that’s when the breakthrough comes.

It reminds me of the old story: a truck was stuck under an overpass. Engineers, officials, and intellectuals debated how to free it. It was a child who suggested the obvious: let the air out of the tires.

Sometimes the simplest solutions are invisible — until they aren’t.

This week, we found ours. And I believe it’s going to change how construction projects are managed, by eliminating the “hidden obvious” gaps that cost companies millions.

It wasn’t AI hallucinations. It wasn’t magic. It was persistence, iteration, and the belief that there’s always simplicity within the complex.

#constructionmanagement #projectcontrols #myTaskIQ #trafficlightlogic #ganttcharts #taskreminders #projecthealth #visualthinking #constructiontech #digitaltools #taskmanagement #SaaS  #Venture Capital

What if managing a project was as simple as reading a traffic light?

Why Every Project Manager Needs a Traffic Light Dashboard

We’ve all seen it on the road: green means go, amber means get ready, red means stop. It’s universal, simple, and instantly understood.

Now imagine applying that same clarity to project management.

I’ll be honest — I’ve flip-flopped on this idea myself, but here’s why I think it works.

Construction projects generate hundreds of tasks, timelines, and dependencies. Even with Gantt charts and task lists, it’s easy to get lost in the detail. Managers often need one thing above all else: a quick, no-nonsense way to see the health of their project.

That’s where traffic lights come in.

 

The Challenge: Too Much Data, Not Enough Clarity

Every project produces a flood of information. Dates, dependencies, responsibilities, shifting priorities. If you’re a Construction Manager, you don’t always have time to sift through reports to figure out which tasks are quietly slipping into the danger zone.

You need a signal. Fast.

 

The Power of the Traffic Light System

Traffic lights create an instant visual language for project health:

  • Green = On track.
  • Amber = Approaching risk, action required soon.
  • Red = At risk, overdue, or critical.

The value isn’t just in the colours — it’s in the timing. By setting reminders (e.g., X days before a task becomes critical), managers can shift tasks into amber before they turn red. That small nudge buys breathing space.

And sometimes, all it takes is changing that reminder by a single day to keep things under control. I’ve seen how much of a difference that simple adjustment can make.

 

Why Simplicity Wins

The best tools aren’t the ones that throw endless data at you — they’re the ones that give you clarity at a glance.

Traffic lights work because they:

  • Cut through noise: One glance tells you what’s healthy and what’s not.
  • Drive proactivity: Amber warnings give managers time to act before a crisis.
  • Boost accountability: Clear signals mean nothing gets “lost” in the system.
  • Save time: Less digging, more doing.

At the end of the day, it’s about focus. You don’t need ten dashboards — you just need the right signal at the right time.

 

The Takeaway

A traffic light isn’t just a graphic. It’s a mindset shift for how we manage projects: stay clear, stay proactive, and stay accountable.

At myTaskIQ, we’ve built this thinking directly into our platform. Every task connects to dates, reminders, and a clear traffic light status — giving Construction Managers the visibility they need without the clutter.

Because sometimes the simplest signals make the biggest impact.

 

Over to you: Do you think a traffic light dashboard would make your projects easier to manage?

#constructionmanagement #projectcontrols #myTaskIQ #trafficlightlogic #ganttcharts #taskreminders #projecthealth #visualthinking #constructiontech #digitaltools #taskmanagement #SaaS  #Venture Capital

 

Why Capturing the Smallest Details early can save $M in Projects

Introduction: Every year, billions are lost to project overruns — not because teams aren’t skilled, but because small, critical details are often overlooked early on. When these details aren’t captured from the start, projects require retrofitting: fixing missing data, adjusting schedules, and scrambling to address overlooked risks. By then, the cost and effort to recover can be enormous.

The Cost of Missing Detail: Missing small details isn’t just a minor inconvenience — it can be the difference between a project coming in on budget or massively overshooting. Imagine a tiny task overlooked during planning: a minor electrical installation, a subtask in procurement, or a regulatory check. Individually, they might seem negligible, but collectively, they can delay timelines, increase labor costs, and create ripple effects across the project.

Capturing the lowest level of detail at the outset allows teams to plan accurately, assign resources effectively, and anticipate issues before they become expensive problems. Retrofitting missing information is often double — or triple — the effort and cost of getting it right the first time.

Emerging Risks & Early Detection: The earlier a risk is identified, the cheaper and faster it is to mitigate. By catching issues at the lowest level of detail, teams can resolve them before they escalate. For example, a small discrepancy in material specification might cost $500 to fix immediately — but if left untracked, it could cause a $50,000 delay downstream.

Emerging risks, especially in complex construction or manufacturing projects, often hide in the smallest tasks. Capturing these risks early ensures that schedules stay intact, budgets remain predictable, and teams can focus on delivering rather than firefighting.

Why Most Tools Don’t Capture This: Many project management tools are designed for high-level tracking: Gantt charts, milestone dashboards, and big-picture KPIs. They don’t track the minute details or subtasks that ultimately determine project success. What others see as “extra effort,” we see as essential insight.

myTaskIQ’s Approach: myTaskIQ captures the lowest level of detail from day one. It automatically identifies every task, flags potential risks early, and provides teams with a clear, actionable roadmap. By focusing on granular data from the start, myTaskIQ ensures projects are watertight, avoiding the costly retrofitting most teams face.

Conclusion: In project management, small details matter. Capturing them early saves money, reduces risk, and keeps projects on schedule. By focusing on the lowest level of detail, teams can transform chaos into clarity, ensuring every project reaches its goals efficiently.

If you want to hear more on how myTaskIQ captures every detail to keep your projects watertight, let’s connect as right now myTaskIQ is looking for Venture Capital Investment, and this software solution is what you have been looking for.

#ProjectManagement #ConstructionTech #ManufacturingTech #RiskManagement #SaaS #Efficiency #DataDriven #myTaskIQ #ProjectPlanning #EmergingRisks #VentureCapital #StartupFunding

Dashboards tableau data visualations not always set out for easy readability

Why we're still failing at data projects

It’s not software, It’s databases

Introduction

Back in 2001, I learned the “waterfall” method at university. It was presented as the way to build software: requirements gathering, documentation, design, development, testing, delivery.

But here’s the problem — when we build databases, most organisations still apply this same approach, as if designing a database is the same as developing software. It isn’t. And treating it that way has cost businesses millions.

I’ve seen it first-hand: projects run for months, budgets run into the millions, and yet the final dashboards don’t give stakeholders meaningful insights. Worse, by the time a data modeller or BI developer comes in, they’re forced to start from scratch — asking stakeholders the same questions the business analysts already asked, only this time digging deeper into the actual nuances of the data.

It doesn’t have to be this way.


The Problem with Treating Database Projects Like Software

Here’s the cycle I’ve seen repeated:

  1. Business analysts gather requirements like it’s a software project. They ask stakeholders what they want, produce extensive documentation, and hand it over. The problem? Stakeholders can usually only describe what they already have, not what they truly need. After years of static extracts and cubes, they’ve forgotten what’s possible.
  2. Stakeholders are left frustrated. They pay hundreds of thousands — sometimes just under $1M AUD — for documentation that doesn’t translate into insight. And when I’ve been brought in late to rescue projects, they’re understandably angry that I need their staff’s time again to ask more questions — questions that actually matter to building usable dashboards.
  3. Dashboards are bolted on at the end. Database engineers build schemas optimised for storage, not for analysis. When BI teams finally plug into them, performance tanks — too many joins, slow refreshes, filters that take forever to load. To fix it, engineers create new denormalised tables with preselected variables. More time. More cost. More frustration.
  4. The story is missing. The dashboards end up looking technical but hollow. They fail the “10-second rule”: if you can’t understand the insight in 10 seconds, the dashboard has failed.

The Missing Role: The Statistical Data Architect

Here’s the core issue: database projects aren’t software projects. They don’t need a business analyst translating stakeholder requirements into hundreds of pages of documentation. What they need is someone who understands:

  • Statistics — to select the right variables, define measures properly, and design metrics that are meaningful.
  • Database design — not at the level of a pure engineer, but enough to shape schemas that support fast, reliable analysis.
  • Dashboard storytelling — structuring data so that insights flow naturally, answering questions in seconds.

This hybrid role — call it a Statistical Data Architect — should be brought in before the first table is built.

Instead of asking stakeholders, “What do you want on your dashboard?” (a question they often can’t answer), the Statistical Data Architect uses pseudo-code and their knowledge of statistical analysis to map the right variables into the technical scope from the beginning.

This prevents the expensive loop of “requirements → documentation → rework.” It means that when dashboards are finally built, they’re not just charts on a page — they’re meaningful, efficient, and trusted.


Why This Matters

Over the years, I’ve been called into countless projects where the dashboards had to be rebuilt entirely. That’s double the cost and double the frustration. And every time, the same mistake was made: treating a database project like software development.

The irony is that a simple shift could save organisations millions: bring in the Statistical Data Architect at the very start. Skip the endless BA documentation. Build databases with analysis in mind. Give stakeholders dashboards that tell real stories instead of technical outputs.


Closing Thoughts

It’s been over 20 years since I first studied the waterfall process, and yet the same outdated mindset continues to shape database projects today. And it’s failing us.

If we want better outcomes, we need to stop pretending databases are software. They aren’t. They’re the foundation of insight — and they need to be designed by people who understand both the data and the story it needs to tell.

The solution is simple: embed the Statistical Data Architect early, before a single table is created. Do that, and you’ll save money, reduce rework, and finally deliver dashboards that drive decisions.

Because if data projects are meant to create insight, then the real question is: why are we still designing them as if they’re about documentation?