# SP Singh Blog > I Transform Your Business By Implementing ERP/CRM Systems With Simplicity And Elegance Language: en URL: https://spsingh.me/ All pages on this site are available as clean Markdown by adding the header `Accept: text/markdown` to any HTTP request. REST API: https://spsingh.me/wp-json/mescio-for-agents/v1/markdown?url={page_url} ## Pages - [ERP Selection | ERP Project | CRM Project](https://spsingh.me/blog/) - [Digital Transformation Consultant | ERP Project Manager](https://spsingh.me/about/) - [Building A Rock Solid Foundation](https://spsingh.me/building-a-rock-solid-foundation/) - [Digital Transformation Consultant](https://spsingh.me/) - [Divi Login Designer](https://spsingh.me/divi-login-designer/): This page is used for Divi Login Designer extension. It will not be visible to your readers. Do not delete it. - [SP Singh FAQ – Digital Transformation Consultant & Sovereign Architect Insights](https://spsingh.me/faq/): 1. Who is SP Singh? Answer: SP Singh is a Perth-based digital-transformation consultant, writer, and founder of Bhani Consulting. Through his blog, he shares insights on leadership, clarity, and organisational change drawn from real-world transformation projects. 2. What is the Sovereign Architect philosophy? ## Blog Posts - [Life Is a Trade](https://spsingh.me/life-is-a-trade/) (2026-05-23): Life Is a Trade Life is all about give and take. We know this. We say it. And then we immediately forget it — because we play the game as if we're here forever, as if the terms don't change, - [The Silo Stack](https://spsingh.me/the-silo-stack/) (2026-05-22): The Silo Stack Many organisations aren't failing at technology. They're failing at sequence. The software goes in before anyone has defined what the business is actually supposed to do end-to-end. The SOPs are written around the tool, not around the - [We Love Quick And Hate Slow!](https://spsingh.me/we-love-quick/) (2026-05-21): We Love Quick. We Hate Root Causes. Your Technology Program Is Paying for It. Look around. The pattern is everywhere. The market for influence is enormous. Books, courses, frameworks — all promising to help you win trust, build authority, shape - [Why the heck You need To Manage Software Vendors?](https://spsingh.me/manage-software-vendors/) (2026-05-20): Enterprise software implementations require software vendors. You will be spending a considerable amount on Professional services with these vendors. So, before engaging them, make sure they are trustworthy. You may also need a client-side Project Manager (PM). The client-side PM - [6 Signs Of Toxic Project Managers Poisoning The Culture!](https://spsingh.me/toxic-project-managers/) (2026-05-20): Project Sponsors, watch out for the following traits of the toxic Project Managers. If your Project Managers are high on the toxicity scale, then protect your team and the culture. Otherwise, the stress levels of the project team and stakeholders - [The Mirror Trap](https://spsingh.me/the-mirror-trap/) (2026-05-20): The Mirror Trap: Why New Software Doesn't Fix Old Drift When your organisation decides it needs new software, the first thing most teams do is document what they currently do. They map the processes. They capture the workflows. They list - [The Tactics Are Not the Problem](https://spsingh.me/the-tactics-are-not-the-problem/) (2026-05-19): The Tactics Are Not the Problem Everyone trying to influence you knows the playbook. Reciprocity. Scarcity. Social proof. Consistency. Body language. Sharp framing at the right moment. These aren't secrets. They're taught in every sales and leadership course written in - [Manage Your Expectations! 6 Things That Will Go Wrong!](https://spsingh.me/manage-your-expectations/) (2026-05-18): Enterprise software implementations are never a smooth sail. There are unknowns, bitter surprises, issues that you often deal with. But, as a Project Sponsor, you must be at the forefront. Tell yourself that it is not going to be easy - [No one wants Vanilla! Secure Enough Budget For Customisations!](https://spsingh.me/budget-for-customisations/) (2026-05-18): Are you sponsoring an enterprise software project? The key message is: Secure enough budget for customisations and enhancements. Don't believe in the claims that standard enterprise software will fully meet your business needs. During the sales process, you may hear: - [Decision-Making Is a Discipline](https://spsingh.me/decision-making-is-a-discipline/) (2026-05-18): Decision-Making Is a Discipline I've been thinking about why smart, experienced people — people who clearly care about doing good work — still end up in situations that feel stuck. Not stuck in an obvious way. Stuck in the way - [The Hidden Cost of Drift](https://spsingh.me/the-hidden-cost-of-drift/) (2026-05-17): The Hidden Cost of Drift Most organisations do not lose value in one big moment. They lose it slowly. A project starts with good intent. A system needs replacing. Reporting needs improving. Processes need to be cleaned up. Everyone agrees - [The Budget Number Is Not What You Think It Is](https://spsingh.me/project-budget/) (2026-05-16): The Budget Number Is Not What You Think It Is Most executives treat a project budget like a fixed truth. An amount of money required to deliver a defined outcome. The vendor quotes it. The board approves it. The program - [Problem Vs Requirement – The Top Budget Killer!](https://spsingh.me/problem-vs-requirement/) (2026-05-16): Problem Vs Requirement - do you know the difference? When you visit a doctor, he asks for symptoms of your problem. He then writes a prescription to solve your problem. Note that he does not ask about your needs or - [Every long-term entity has a Roadmap](https://spsingh.me/every-long-term-entity-has-a-roadmap/) (2026-05-16): Every long-term entity has a Roadmap. The question is who built yours. Life has one. A product has one. Infrastructure has one. A business has one. Technology programs have one. Your career has one. But here's what most executives never - [The Basics Are Not Beneath You!](https://spsingh.me/the-basics-are-not-beneath-you/) (2026-05-15): The Basics Are Not Beneath You Most things worth doing are simple. Not easy. Simple. A healthy body. Financial stability. Strong relationships. The principles aren't complicated — consistency, attention, honest feedback, and a willingness to adjust when something isn't working. - [Your ERP Program Has Five Dimensions](https://spsingh.me/your-erp-program-has-five-dimensions/) (2026-05-14): Your ERP Program Has Five Dimensions. Most Steering Committees Watch One. What you're monitoring, what you're missing, and why the gap between them is where programs go wrong. You get a status report every fortnight. It tells you the program - [Software Selection: The Deceptive World of Software Sales!](https://spsingh.me/software-selection/) (2026-05-13): If you are deciding on Enterprise software for your organisation, then read this carefully! Welcome to the deceptive world of Software Sales Look, if you are not vigilant, you can make a terrible decision very quickly. During software selection, you - [Celebrate Project Closure With Heart And Soul! Your Team Will Love You For It!](https://spsingh.me/celebrate-project-closure/) (2026-05-13): How to celebrate project closure with heart and Soul? We often start projects with a kick-off but seldom finish them with celebration. Very few projects are lucky enough to meet a graceful end, and the team sit together and celebrate. - [Your ERP Project Is Green- Why Is It Still A Problem?](https://spsingh.me/your-erp-project-is-green/) (2026-05-13): Your ERP Project Is Green. The dashboard says everything is on track. Scope — controlled. Budget — within tolerance. Timeline — amber at worst, green most weeks. The steering committee gets its report. The sponsor nods. The project moves forward. - [The cost of drift](https://spsingh.me/the-cost-of-drift/) (2026-05-12): You Are Not Paying for Your ERP Program You are paying for your reluctance to make hard calls inside it- The cost of drift. Most executives assume the cost of a struggling technology program is the number on the variance - [How To Define Change? Insanely, We Don’t!](https://spsingh.me/how-to-define-change/) (2026-05-11): Define Change? I bet you are wondering what does that even mean! Let us start with the basics! Tell me, why is change management such a complex area? Is it complicated, or do we make it so? Look, there are - [Why We Resist Change? Revealing #1 Hidden And Profound Reason!](https://spsingh.me/resist-change/) (2026-05-11): https://youtu.be/nGv1fNUgqmM Do you resist change? Do you know others who resist change? Suppose you rock up to the office and see a letter on your desk. The letter states that you are getting a dedicated luxury cabin in two months. - [The Trap of Doing Everything Ourselves](https://spsingh.me/the-trap-of-doing-everything-ourselves/) (2026-05-11): The Trap of Doing Everything Ourselves Most organisations do not fail because they have no goals. They fail because they treat goals as if they automatically create capacity. An executive team may agree that something is important: improve reporting, fix - [What are you returning to?](https://spsingh.me/what-are-you-returning-to/) (2026-05-10): Why Your Mind Needs What Your Organisation Already Knows There's a question worth sitting with for a moment. Why does the army repeat the same drills every morning? Why does every religion return to the same texts, the same prayers, - [How To Prioritise? 8 Steps To Stop Making Painful Mistakes!](https://spsingh.me/how-to-prioritise/) (2026-05-09): https://www.youtube.com/watch?v=Sn7zrKLxVcA Life does not give us everything we want. Resources are always limited, whereas demands are beyond the limit. How to prioritise is a must-have skill for everyone! I still remember my school days, having five bucks in hand and - [Why Scrum Sucks? Insane Reasons Killing Your Project Right Now!](https://spsingh.me/scrum/) (2026-05-09): https://www.youtube.com/watch?v=txvBBkqm6I8 In the last decade, there has been phenomenal uptake of Scrum in the software industry. It has almost become a fashion statement for customer and vendor organisations. Oh! Do you do Agile?Yes! We use Agile, Scrum. We also have - [Change Starts With Belief](https://spsingh.me/change-starts-with-belief/) (2026-05-09): Change Starts With Belief On the surface, we think people act because of pain and pleasure. We avoid pain. We seek comfort. We look for safety, recognition, certainty and control. In organisations, this is easy to see. People avoid difficult - [Accepting Reality](https://spsingh.me/accepting-reality/) (2026-05-08): The Quiet Work of Accepting Reality One mistake I often make is thinking that if I understand something, I should be able to fix it immediately. If I know I am distracted, I should stop being distracted. If I know - [Play vs. Competition](https://spsingh.me/play-vs-competition/) (2026-05-07): Play vs. Competition The confusion most of us carry — and the cost we don't see Most of us are more tired than the work justifies. The hours are long, yes. The decisions are hard, yes. But if we're honest, a - [How To Check Project Estimates? Revealing 10 Secret Points!](https://spsingh.me/check-project-estimates/) (2026-05-06): https://www.youtube.com/watch?v=5rNS0boNxek As a Project Sponsor, you are responsible for approving the Statement of Work (SOW). Before signing the SOW, you must thoroughly check project estimates. Checking the quality of effort estimate (cost) is one of the most critical tasks during - [How To Search Enterprise Software Online? Save Time And Prevent Headache!](https://spsingh.me/search-enterprise-software/) (2026-05-06): https://www.youtube.com/watch?v=iKbCzb4_p1M Are you searching for enterprise software for your business or department? You may be wondering what to enter in Google to search enterprise software? Which words, phrases, keywords to search? Often you doubt if you are searching for the - [The Wrong Definition of Power](https://spsingh.me/the-wrong-definition-of-power/) (2026-05-06): The Wrong Definition of Power Is Costing You Most of us are chasing the wrong thing. We call it power. What we mean is: the ability to get what we want — from people, from systems, from circumstances. A better - [The Question Your Vendor Will Never Ask You](https://spsingh.me/the-question-your-vendor-will-never-ask-you/) (2026-05-05): The Question Your Vendor Will Never Ask You Most technology programs begin with the wrong assumption. Here's how to find out if yours has. Before a single contract is signed, before a vendor is selected, before a project team is - [ERP Selection – The Quick and Dirty Way!](https://spsingh.me/erp-selection/) (2026-05-04): https://youtu.be/Uwe7mGuOQy4 You can waste months and spend thousands on ERP selection for your business. The fact is that conventional vendor selection often does more harm than good. There is a better way to choose vendors much quicker and intelligently. Caution: - [How To Reduce ERP Project Cost? Revealing One Of The Best Way!](https://spsingh.me/reduce-erp-project-cost/) (2026-05-04): This is the #1 question that every Project Sponsor is asking! How can we reduce ERP Project cost? A significant chunk of ERP cost is the consulting services. If you are serious to reduce ERP project cost, this is where - [Are You Leading This Project, or Is It Leading You?](https://spsingh.me/are-you-leading-this-project-or-is-it-leading-you/) (2026-05-04): You Have a Choice — and Most Sponsors Don't Know It Let me be honest with you. Not corporate-honest, where everything is framed as an opportunity. Actually honest. You became an ERP project sponsor because someone decided you were senior - [YOU MADE A BAD ONE-WAY DECISION. NOW WHAT? ](https://spsingh.me/you-made-a-bad-one-way-decision-now-what/) (2026-05-03): A direct letter to the C-Suite executive who greenlit an ERP implementation they now regret — and who feels too deep in to turn back. You approved it. You signed the business case, shook hands with the vendor, and stood - [How To Review Statement of Work? Never Miss These 6 Checkpoints!](https://spsingh.me/review-statement-of-work/) (2026-05-02): https://youtu.be/kRmgLfl8F20 As a customer Project Sponsor, you cannot afford to overlook Statement of Work (SOW). SOW is one of the most critical documents in ERP implementations. It includes detailed information about project scope, estimate, timeline, role and responsibility. It tells - [How To Implement ERP? 4 Insanely Simple Steps!](https://spsingh.me/how-to-implement-erp/) (2026-05-02): Implementing ERP for your business can be a challenging initiative. You often wonder where to start, whom to talk to? Questions such as how to implement ERP, implementation time, investment, forming a project team may often overwhelm you. As a - [Doing ERP In-House](https://spsingh.me/doing-erp-in-house/) (2026-05-02): The Hidden Cost of “Doing ERP In-House”: When Saving Fees Increases Total Spend 1. The Decision That Feels Prudent It is common to see organisations choose to run ERP programs largely in-house. The logic is straightforward: “We understand our business - [ERP Project Looks Fine- That’s the Risk.](https://spsingh.me/erp-project-looks-fine/) (2026-05-01): Your ERP Project Looks Fine. That’s the Risk. 1. The uncomfortable truth most executives don’t see Across local government and enterprise programs, ERP projects rarely fail suddenly. They drift into failure quietly. Status reports stay green.Steering Committees stay calm.Vendors stay confident. - [ERP Blind Spots – Why do we experience them?](https://spsingh.me/erp-blind-spots/) (2026-04-30): ERP Blind Spots: When Every Stakeholder Plays a Different Game 1. The underlying pattern ERP programs rarely fail because people are careless. They underperform because: Each stakeholder is doing their job well Each is optimising for their own success But no one - [Why We Need ERP? These 11 Reasons Will Reveal Hidden Value!](https://spsingh.me/why-we-need-erp/) (2026-04-29): Clarity on purpose is vital for any investment. Investing in ERP is a crucial decision for a business. So before investing in ERP we must understand why we need ERP? This post reveals 11 solid reasons why you need ERP. - [What is ERP? Insanely Simple Stuff You Must Know!](https://spsingh.me/what-is-erp/) (2026-04-29): ERP stands for Enterprise Resource Planning. The name suggests that the software help organisations for resource planning. It is misleading as ERP have grown much more profound and prominent over the years. ERPs do much more than resource planning. So, - [Why Do We Experience Blind spots?](https://spsingh.me/why-do-we-experience-blind-spots/) (2026-04-29): So, why do we experience blind spots? 1. The assumption most people make We tend to believe blind spots happen because people miss things. We assume: If we had more information If people paid more attention If the team communicated - [What Good ERP Governance Actually Looks Like?](https://spsingh.me/what-good-erp-governance-actually-looks-like/) (2026-04-28): ERP Governance Looks Fine on Paper. So Why Does It Still Fail? Steering Committees are in place.Reports are being produced.Decisions are being recorded. From the outside, governance appears structured and controlled. Yet inside the program: Issues surface late Decisions feel - [What Are The Roles In ERP Project Team? 14 Unique Roles For Solid Delivery!](https://spsingh.me/erp-project-team/) (2026-04-27): ERP Projects are complex. The composition of the ERP Project Team is not always clear. It is one of the most asked questions. In the post, I will cover the various roles within ERP Project Team. Refer to the following - [What Is The Top Reason For ERP Project Failure?](https://spsingh.me/erp-project-failure/) (2026-04-27): ERP Project Failure Many Enterprise software (ERP/CRM) projects are failing due to this single problem! During Analysis, Customers often prescribe ‘Solution design’ rather than ‘Requirements’ to ERP Consultants. You cannot afford to ignore this problem! Otherwise, it can cost you - [ERP Is Not Failing. The Executive Standard Is.](https://spsingh.me/erp-is-not-failing/) (2026-04-27): It is common to see this pattern—across councils, organisations, and programs It is common to see executives invest heavily in ERP initiatives with the expectation that clarity, control, and performance will follow. The program is approved.The system is implemented.The reporting - [ERP Value Leakage: Cost of Capability Development](https://spsingh.me/erp-value-leakage/) (2026-04-26): ERP Value Leakage: The Cost You’re Not Measuring You have invested in core business systems—ERP, HRIS, finance platforms, integrations. These systems are not just tools. They define how your organisation: processes transactions manages financial control runs operations produces reporting makes --- # Full Content --- title: "Life Is a Trade" url: "https://spsingh.me/life-is-a-trade/" lang: "en-AU" type: "post" description: "Life Is a Trade Life is all about give and take. We know this. We say it. And then we immediately forget it — because we play the game as if we're here forever, as if the terms don't change," last_modified: "2026-05-23T13:08:12+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Life Is a Trade" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Life Is a Trade **Life Is a [Trade](https://spsingh.me/what-are-you-prepared-to-give-away/)** Life is all about [give and take](https://spsingh.me/what-are-you-prepared-to-give-away/). We know this. We say it. And then we immediately forget it — because we play the game as if we’re here forever, as if the terms don’t change, as if protecting what we have is the same thing as building something. It isn’t. Every choice is a trade. You give what you value less to receive what you value more. You give time to find stability. You give money to buy peace. You give resources to build the next generation something stronger than what you inherited. You call these things [priorities, commitments, investments](https://spsingh.me/erp-project-looks-fine/) — but the structure underneath is always the same. A trade. And in any trade, you lose something. That’s not cynicism. That’s the mechanic. You cannot win something without giving something up. The question — the only question that actually matters — is whether you’re [conscious of what you’re surrendering](https://spsingh.me/accepting-reality/). Most of us aren’t. We focus on what we’re gaining. We track the wins. We optimise for the thing we can see arriving and stay deliberately vague about the thing quietly leaving. And so we accumulate victories that feel increasingly hollow, because somewhere along the way the terms shifted and we didn’t notice. The terms always shift. What you traded five years ago at a price that felt right may now be [costing you something](https://spsingh.me/what-is-the-cost-of-incompetence/) you can no longer afford to lose. That’s not a mistake you made then. It’s a [blindspot](https://spsingh.me/scrum/) you’re carrying now. You can’t design the perfect trade in advance. No one can. But you can stay awake to what you’re exchanging — right now, in this season, with what this choice is actually costing. That’s the discipline. Not [winning more](https://spsingh.me/digital-capacity-is-like-electricity/). Knowing what you’re [trading to win](https://spsingh.me/you-made-a-bad-one-way-decision-now-what/). When you know that, the wins start to mean something. --- --- title: "The Silo Stack" url: "https://spsingh.me/the-silo-stack/" lang: "en-AU" type: "post" description: "The Silo Stack Many organisations aren't failing at technology. They're failing at sequence. The software goes in before anyone has defined what the business is actually supposed to do end-to-end. The SOPs are written around the tool, not around the" last_modified: "2026-05-22T14:06:36+00:00" categories: [The Sovereign Architect Series, Visioning and Selection] custom_fields: cos_headline_text: "The Silo Stack" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Silo Stack ## **The Silo Stack** Many organisations aren’t failing at technology. They’re failing at sequence. The software goes in before anyone has defined what the business is actually supposed to do end-to-end. The SOPs are written around the tool, not around the work. The integrations are half-built. And then the go-live happens — not because everything is ready, but because the calendar ran out. That’s where the drift begins. **What executives are hearing from their teams** If this is happening in your organisation, you’re probably hearing some version of the following: _“We just need to get this SaaS tool across the line for this team.”_ _“The legacy system can’t handle it, so we’ve built something internally to bridge the gap.”_ _“We tried to get IT involved but it was taking too long, so we’ve moved ahead with what we have.”_ _“There’s another system the other department is using that does something similar, but we need ours to be a bit different.”_ None of these statements are dishonest. Each one is a rational response to a local problem. The person saying it is trying to make progress. What they cannot see — because they’re solving at the SOP level — is that every one of these decisions is adding complexity to a stack that no one is stewarding. You end up with a pile of digital SOPs. Some SaaS. Some home-grown. Some half-built go-lives that technically launched but never fully landed. Staff members across different areas attempting similar fixes independently. A growing number of systems that are connected in ways no one has fully mapped. The reports stay green. The pile gets taller. **What’s actually happening** Organisations don’t end up in this position because of bad technology decisions. They end up here because software selection happened before business architecture was established. The sequence that creates this problem looks like this: Problem is identified → Software is selected to solve it → Implementation proceeds → End-to-end complexity is discovered mid-delivery → Shortcuts are taken to cross the line → The next problem is identified → Another tool is selected. Each cycle adds a layer. Each layer makes the next selection harder. And because each decision was made at the SOP level — quick and dirty, close to the problem, disconnected from the whole — no one accumulates a coherent picture of where the organisation actually is. The cost is not just financial. It’s organisational. Your staff are spending increasing amounts of time managing the interfaces between systems rather than doing the work the systems were meant to support. **What executives should be considering** The mitigation is not a technology decision. It’s an architectural and sequencing decision. Before the next tool is selected, before the next project kicks off, executives need honest answers to three questions: **Do we have a current-state map of our systems, integrations, and data flows?** Not a diagram from three years ago. Not what the IT team thinks it looks like. What it actually looks like — including the home-grown patches, the workarounds, and the systems that were never fully decommissioned. **Have we established an enterprise-level roadmap before we select software?** Software selection at the SOP level optimises for the local problem. It almost always creates a broader one. The architecture conversation has to precede the vendor conversation, not follow it. **Who is accountable for the coherence of the whole?** In most organisations that have drifted into a silo stack, the honest answer is: no one. Each system has an owner. No one owns the relationships between systems, the end-to-end logic, or the question of whether the current state is moving toward or away from where the organisation needs to be. The pattern is common. That doesn’t make it inevitable. Organisations that avoid it don’t have better technology. They have executives who insisted on the architectural conversation before anyone was allowed to start selecting tools. They slowed down at the point where speed felt urgent — and that’s what kept them from spending the next three years undoing decisions that looked sensible in isolation. The question worth asking before the next project brief lands on your desk: are we solving the right problem, or are we solving the closest one? _SP Singh is the founder of [Bhani Consulting](https://bhaniconsulting.com). He provides independent ERP oversight and advisory to WA local government and Aboriginal corporations — across the full program lifecycle, from direction through to post-go-live stewardship._ --- --- title: "We Love Quick And Hate Slow!" url: "https://spsingh.me/we-love-quick/" lang: "en-AU" type: "post" description: "We Love Quick. We Hate Root Causes. Your Technology Program Is Paying for It. Look around. The pattern is everywhere. The market for influence is enormous. Books, courses, frameworks — all promising to help you win trust, build authority, shape" last_modified: "2026-05-21T13:10:22+00:00" categories: [The Sovereign Architect Series, Leadership] custom_fields: cos_headline_text: "We Love Quick And Hate Slow!" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # We Love Quick And Hate Slow! # We Love Quick. We Hate Root Causes. Your Technology Program Is Paying for It. Look around. The pattern is everywhere. The market for influence is enormous. Books, courses, frameworks — all promising to help you win trust, build authority, shape perception. Tactics and hacks, mostly. What’s harder to find, and far less popular, is the quieter proposition: be truthful, serve with genuine intent, and trust will manifest on its own. That path is slower. It requires something from you that tactics don’t. So we buy the tactics. The market for looking young and beautiful is worth billions. Clothes, cosmetics, accessories — products that change how you appear. The market for actually being healthy — for the unglamorous work of sleep, movement, food, stress — is a fraction of the size. Appearance is immediate. Health is cumulative. We know which one sells. Medications for sleep, stress, and fitness anxiety sell fast. Not because people don’t care about their health — they do. But a pill that addresses tonight’s insomnia is available now. Understanding why you can’t sleep requires sitting with something uncomfortable. Most of us would rather not. Social media platforms have made it easy to associate yourself with interesting places, impressive people, and compelling ideas. What they haven’t made easier — what no platform can make easier — is the slow, effortful work of genuine human connection. So we curate. We associate. And human connection keeps deteriorating. Superficial. Lonely. But the feed looks good. **There is a common thread.** We love what is quick, easy, cheap, and ego-boosting. We struggle with what is slow, demanding, simple, and selfless. This is not a character flaw. It is a deeply human pattern. The quick path presents itself as sensible. The slow path asks for something most environments don’t reward. So we take the quick path, again and again, and wonder why the same problems keep returning in slightly different form. Perhaps this, as the observation goes, is the reason for much of our suffering too. **The same dynamic runs through your organisation’s technology programs.** Not because your executives are careless. Not because your team isn’t trying. But because the same human pull — toward the visible, the fast, the manageable — operates inside institutions just as it operates inside individuals. And when it goes unnamed, it shapes decisions in ways nobody quite intends. Here is what it looks like. **Symptom 1: Your steering committee is active, but the same problems keep returning.** Meetings are well-run. Papers are prepared. Actions are logged. Yet three meetings later, a version of the same issue is back on the agenda — reworded, reframed, but structurally identical. This happens because resolving root causes requires someone to say something uncomfortable — to a vendor, to a project team, sometimes to a peer. That’s costly. Running a clean, productive-looking meeting isn’t. So the meeting becomes the product, not the resolution. _What to try:_ Pull your last three sets of minutes. List every issue that appeared more than once. For each one, ask honestly: what specifically changed — not how it was reported, but what actually changed? That gap is where the drift lives. **Symptom 2: Your status reports are green, but something feels wrong.** The vendor is confident. The project manager is across the detail. Every metric says on track. And yet there’s a signal — quiet, hard to name — that something isn’t right. This happens because status reporting systems are designed to track motion, not meaning. Milestones hit. Tasks completed. Risks logged. None of that tells you whether what’s being built still matches what the organisation actually needs. Green means the machine is running. It doesn’t confirm it’s heading in the right direction. _What to try:_ Ask your project lead one question, outside of a formal meeting: “If you could change one thing about how this program is being run, what would it be?” What they say — and how quickly they say it — will tell you more than the last six reports. **Symptom 3: Your vendor fixes things quickly, but the same class of problem keeps appearing.** Responsiveness feels like partnership. A vendor who resolves issues fast reads as competent and engaged. But look across the last ten issues and a pattern emerges — different names, same structural cause. This happens because fixing the symptom is faster and less disruptive than identifying what’s underneath. This is true for the vendor and for your team. Both sides have a quiet incentive to keep the cycle moving rather than stop and examine why the same problem keeps returning in new clothes. _What to try:_ Ask someone with no stake in the answer to categorise your last ten issues by type, not by resolution status. You’re looking for patterns, not incidents. Repeated categories point to something that hasn’t been touched yet. **Symptom 4: The system is live, but nobody can tell you what value it’s delivering.** Go-live happened. The vendor handed over. The team is using the system. But ask what’s materially better — in process efficiency, decision quality, cost control — and the answers are vague. This happens because we invest enormous energy getting to go-live and almost none in defining what “working” was supposed to mean. The business case had numbers. The implementation had milestones. The bridge between the two — the sustained discipline of confirming whether the investment is actually producing what was intended — rarely gets built. Go-live feels like completion. It isn’t. _What to try:_ Go back to the original business case or problem statement. Pick two or three specific outcomes that justified the investment. Ask whether you could, today, demonstrate progress against each one. If you can’t measure it, you can’t steward it. **Symptom 5: Your best internal people have quietly stopped pushing.** They’re still attending. Still contributing when asked. But they’ve stopped volunteering, stopped flagging things they’d have flagged a year ago, stopped investing in the outcome the way they once did. This happens because capable people disengage when they’ve learned that raising hard things doesn’t change hard things. They’ve been through enough cycles to know the program’s appetite for difficult truths is limited. So they conserve themselves. They do the job. They stop caring about the result. _What to try:_ Have a direct, private conversation with the person whose judgment you trust most on this program. Not in a project context. Ask them what they’d want you to know if they were confident you’d act on it. Then sit with what comes back. **None of this requires a failing program.** Most of these symptoms are present in programs that look, from the outside, completely normal. That’s precisely what makes them dangerous. The pull toward visible progress, managed optics, and quick resolution isn’t a sign of bad leadership. It’s a sign of human leadership operating inside a system that hasn’t been designed to counteract it. The question worth asking is a simple one: are the structures around your technology program designed to surface what’s actually happening — or are they, quietly, designed to make it easier not to look? _I write about drift and the discipline required to hold standards. If this is describing something you’re currently navigating, I’m at [spsingh@bhaniconsulting.com](mailto:sp@bhaniconsulting.com)._ --- --- title: "Why the heck You need To Manage Software Vendors?" url: "https://spsingh.me/manage-software-vendors/" lang: "en-AU" type: "post" description: "Enterprise software implementations require software vendors. You will be spending a considerable amount on Professional services with these vendors. So, before engaging them, make sure they are trustworthy. You may also need a client-side Project Manager (PM). The client-side PM" last_modified: "2026-05-22T10:36:23+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-20 22:07:10" --- # Why the heck You need To Manage Software Vendors? [Enterprise software implementations](https://spsingh.me/what-is-erp/) require [software vendors](https://www.appdirect.com/resources/glossary/software-vendor). You will be spending a considerable amount on Professional services with these vendors. So, before engaging them, make sure they are trustworthy. You may also need a client-side Project Manager (PM). The client-side PM role is to work in collaboration with vendors PMs. Both PMs must collaborate to deliver the successful project within scope, quality, budget, and time constraints. It is pretty common to see client PMs justifying their existence through fault-finding. Their focus is to question vendor invoices and timesheets. Thus, you will see them taking much pride in nit-picking vendor work. ![Manage Software Vendors](https://spsingh.me/wp-content/uploads/2021/11/zdenek-machacek-uB9TMm7R0So-unsplash-1024x683.jpg) The client PMs have a critical role to play. Their focus must be on managing all tasks that are client responsibility. For example, Analysis, Data, Testing, Training, and Change Management, to name a few. In addition, they must work constructively with all stakeholders to deliver the expected outcome of the business. ## Understand the ‘Manage Software Vendors’ dynamic In Summary, as a Project Sponsor, make sure you engage trustworthy vendors. The client PM role is critical for project success. Therefore, client PM must work in collaboration with all stakeholders (including vendors). If the client PM has to manage software vendors. In other words, police the vendor’s work, then you are not utilising your resources effectively. Take some time to reflect on this dynamic. Why do you need to pay someone (client PM) to manage someone else who is paid to do the agreed work (vendor)? --- --- title: "6 Signs Of Toxic Project Managers Poisoning The Culture!" url: "https://spsingh.me/toxic-project-managers/" lang: "en-AU" type: "post" description: "Project Sponsors, watch out for the following traits of the toxic Project Managers. If your Project Managers are high on the toxicity scale, then protect your team and the culture. Otherwise, the stress levels of the project team and stakeholders" last_modified: "2026-05-21T18:06:03+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-20 22:00:10" --- # 6 Signs Of Toxic Project Managers Poisoning The Culture! Project Sponsors, watch out for the following traits of the toxic Project Managers. If your Project Managers are high on the toxicity scale, then [protect your team](https://spsingh.me/erp-project-team/) and the culture. Otherwise, the stress levels of the project team and stakeholders will skyrocket. There will be little progress. Bad decisions and a lack of trust will cripple your project. Watch out for these warning signs and check toxicity to take quick action: ![toxic project managers](https://spsingh.me/wp-content/uploads/2021/11/adi-goldstein-KobSuU7b3g-unsplash-1024x683.jpg) ## 1. **Blame** – **Toxic Project Managers Love this one!** You will observe that they are busy on a fault-finding mission. It is always something wrong with vendor resources, project teams, [software applications](https://techmonitor.ai/what-is/what-is-application-software-4910115). They are skilled in distracting from the real problem and blaming others. ## 2. **Never too sure** They never take charge. Seldom do they have good visibility on the project plan, objective, domain knowledge. You will often hear from them: - _Let me get back to you on this:_ **Basically, I don’t know** - _I need to check with the team; what do you think, Simon?_: **Deflection tactic** They are never too sure about the project plan, resources, delivery dates (ETA). ## 3. **They are always concerned** They are concerned about everything. When you ask about specific concerns or the risk, you may hear much fluff. You will observe that everything is a risk according to them. ## **4. Focus on non-value add stuff** They will keep the key tasks on the backburner will be busy nitpicking vendor timesheets, documentation and emails. ## 5. **Justify their existence – rather than adding value** Because they never add much value, their focus is on justifying their existence. So they will complicate simple stuff and pretend to be busy. ## 6. **Freely floating things** You will observe that everything takes a long time to complete. They may never take charge and lead from the front. Meetings result in even more meetings and unnecessary discussions. The above list is not exhaustive. However, these are a few signs you must look at. If your Project Manager is high on the toxicity scale, protect your project and the team from them! --- --- title: "The Mirror Trap" url: "https://spsingh.me/the-mirror-trap/" lang: "en-AU" type: "post" description: "The Mirror Trap: Why New Software Doesn't Fix Old Drift When your organisation decides it needs new software, the first thing most teams do is document what they currently do. They map the processes. They capture the workflows. They list" last_modified: "2026-05-20T13:47:13+00:00" categories: [The Sovereign Architect Series, Visioning and Selection] custom_fields: cos_headline_text: "The Mirror Trap" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Mirror Trap **The Mirror Trap: Why [New Software](https://spsingh.me/the-hidden-cost-of-drift/) Doesn’t Fix Old Drift** When your organisation decides it needs new software, the first thing most teams do is document what they currently do. They map the processes. They capture the workflows. They list the reports they run every month. Then they hand that document to a vendor and ask: _Can your system do this?_ It feels thorough. It feels responsible. It is, quietly, the first mistake. **You are not [selecting software](https://spsingh.me/software-selection/). You are selecting a mirror.** When requirements are built from current practice, you are not designing for what your [organisation needs](https://spsingh.me/why-we-need-erp/). You are photographing what it has become — habits, workarounds, and all. The software that wins the selection is the one that most faithfully reflects your existing constraints back at you. And then you go live. And the constraints come with you. Repackaged. Faster. More expensive to change. **How [the drift](https://spsingh.me/the-hidden-cost-of-drift/) works** No organisation deliberately designs bad processes. Drift doesn’t announce itself. A local council adopts a manual approval step because, years ago, a project went over budget and someone got burned. The step made sense then. Over time, the person who added it leaves. The reason is forgotten. The step remains. New staff learn it as _how we do things here_. It becomes invisible — not because it’s hidden, but because it’s normal. When the time comes to select a [new system](https://spsingh.me/why-no-one-owns-organisational-improvement/), the team documents the approval step. The vendor accommodates it. The system is configured around it. The software goes live. The unnecessary step, now embedded in code, will cost $15,000 to change. This is how organisations buy software that automates their dysfunction. **The lens problem** What makes this hard is not ignorance. It’s proximity. The people who know your systems best — the ones doing the day-to-day work — cannot easily see the drift. They are inside it. Their expertise is in navigating the current constraints, not questioning whether those constraints should exist. They see the world through the lens of what your organisation currently does, which means they don’t always see _why_ it does those things, or whether those reasons still hold. This is not a criticism of operational staff. It is a structural reality. Day-to-day visibility and executive-level visibility are not the same thing. One sees how the work moves. The other needs to see whether the work is moving in the right direction. When [software selection](https://spsingh.me/software-selection/) is handed entirely to the operational layer, you get operational-layer requirements. Legitimate. Detailed. And often anchored to problems that could have been solved before the system was selected. **What the selection process should be asking** The question is not: _Can this system do what we currently do?_ The question is: _What does this organisation need to be capable of — and is what we currently do actually the right path to get there?_ That distinction requires someone to pause before the requirements are written. To ask why the current process exists. To surface the constraints that were once real and are now just habit. To separate the work that creates value from the work that exists because no one has stopped to question it. This is not a technology conversation. It is a leadership conversation. And it needs to happen before the vendor briefing, not after. **The cost of skipping it** Organisations that go into selection without this clarity don’t necessarily choose bad software. They often choose perfectly adequate software. The failure is subtler: the new system is configured to preserve what should have been redesigned. Two years post-go-live, the complaints begin. The system is slow. Inflexible. Doesn’t do what they need. The vendor gets blamed. But the vendor built what they were asked to build. The problem was upstream. It was in the requirements. It was in the assumption that [documenting current practice](https://spsingh.me/the-question-your-vendor-will-never-ask-you/) was the same as understanding genuine need. **What this means for you** Before your organisation writes a single requirement, before you invite a vendor to demonstrate, ask your executive team one question: _Are we selecting software for the organisation we are, or the organisation we need to become?_ If you can’t answer that with confidence, the selection process hasn’t started yet. The technology decision is the last decision. The first decision is what you actually need — and why what you’re currently doing isn’t already delivering it. That clarity is worth more than any software feature list. _SP Singh is an independent ERP advisor based in Perth, WA. He works with executives in local government and mid-sized organisations to provide oversight and direction on technology programs — before, during, and after go-live. [bhaniconsulting.com](https://bhaniconsulting.com)_ --- --- title: "The Tactics Are Not the Problem" url: "https://spsingh.me/the-tactics-are-not-the-problem/" lang: "en-AU" type: "post" description: "The Tactics Are Not the Problem Everyone trying to influence you knows the playbook. Reciprocity. Scarcity. Social proof. Consistency. Body language. Sharp framing at the right moment. These aren't secrets. They're taught in every sales and leadership course written in" last_modified: "2026-05-19T13:24:39+00:00" categories: [The Sovereign Architect Series, Leadership] custom_fields: cos_headline_text: "The Tactics Are Not the Problem" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Tactics Are Not the Problem # The Tactics Are Not the Problem Everyone trying to influence you knows the playbook. Reciprocity. Scarcity. Social proof. Consistency. Body language. Sharp framing at the right moment. These aren’t secrets. They’re taught in every sales and leadership course written in the last thirty years. By now, most experienced executives have either been trained in them or have absorbed them through enough exposure to know what they look like. Knowing the tactics exist isn’t the problem. Using them isn’t even the problem. The problem is when they become a substitute for something else. **What they’re substituting for** When someone is genuinely trying to serve your mission — your organisation, your program, your outcome — the tactics aren’t tactics. They’re just how competent people communicate. They frame things clearly. They know when to create urgency and when to wait. They read the room. It works because the intent underneath it is real. The moment that intent shifts — from serving your purpose to serving theirs — the mechanics stay identical. The words are still correct. The framing is still sharp. The energy is different. Most people feel this before they can name it. A vendor answer that covers the question without quite resolving it. A project update that hits every metric and explains nothing about what’s actually happening. A consultant who always seems to be managing your perception of the program rather than helping you see it clearly. The tactics didn’t change. The purpose underneath them did. **What this means on the delivery side** If you lead, advise, sell, or influence — the discipline here is uncomfortable but simple. Nothing you know about communication will save you once your purpose has drifted. You can be technically proficient in every influence technique ever documented and still lose the room, lose the relationship, lose the engagement — because people are not just processing your words. They’re processing the whole signal. Body, language, energy, intent. When those are in sync, you operate at a different level. When they aren’t, the gap is felt even when it can’t be named. The most common drift I see is subtle. It doesn’t start with dishonesty. It starts with someone who was once genuinely trying to help the client beginning — slowly, almost imperceptibly — to protect their own position instead. To manage the narrative rather than report it. To keep the engagement alive rather than say the hard thing that might end it. By the time it becomes visible, the tactics have been covering it for months. **What this means on the receiving end** For executives on the receiving end — being briefed, being advised, being sold to — the discipline is different but equally important. You don’t need to become a student of influence psychology to protect yourself. You need one thing: to trust the signal when something feels off. Not because you can always articulate what’s wrong. But because the dissonance usually precedes the evidence. The advisor who always has a reassuring answer. The vendor whose updates are comprehensive and somehow uninformative. The steering committee presentation that leaves you less clear than when you walked in, not more. Your job isn’t to run counter-tactics. Your job is to ask the question that cuts through the framing: _what is this person’s interest in the answer they’re giving me?_ That single question — asked honestly — will tell you more than any amount of training in persuasion techniques. **The thing underneath the thing** Knowing the tactics is useful. Understanding their limits is more useful. They work when the purpose is genuine. They fail — slowly, then suddenly — when the purpose has shifted from service to self-interest. No amount of sharp language covers that gap permanently. Not in a relationship, not in a program, not in an organisation. The body knows. The room knows. Eventually, the outcomes confirm it. The discipline — whether you’re the one influencing or the one being influenced — is to stay honest about which side of that line you’re on. _SP Singh writes daily about drift, discipline, and the cost of holding standards. He provides independent ERP oversight and advisory to WA local government and Aboriginal corporations._ --- --- title: "Manage Your Expectations! 6 Things That Will Go Wrong!" url: "https://spsingh.me/manage-your-expectations/" lang: "en-AU" type: "post" description: "Enterprise software implementations are never a smooth sail. There are unknowns, bitter surprises, issues that you often deal with. But, as a Project Sponsor, you must be at the forefront. Tell yourself that it is not going to be easy" last_modified: "2026-05-20T04:28:08+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" cos_headline_text: "Manage Your Expectations! 6 Things That Will Go Wrong!" cos_seo_score: 0 cos_headline_score: 0 wpar_republish_meta_query: "2026-05-18 21:09:56" --- # Manage Your Expectations! 6 Things That Will Go Wrong! [Enterprise software](https://spsingh.me/what-is-erp/) implementations are never a smooth sail. There are unknowns, bitter surprises, issues that you often deal with. But, as a Project Sponsor, you must be at the forefront. Tell yourself that it is not going to be easy because it may not! Manage your expectations and prepare for a bumpy ride. As you get ready for it, you will observe that it is actually not too bad. The key is to prepare and plan for the implementation to ensure a successful project. ![manage your expectations](https://spsingh.me/wp-content/uploads/2021/11/jannes-glas-P6iOpqQpwwU-unsplash-1024x509.jpg) So, manage your expectations and prepare for these scenarios: ## 1. **Resources will come and go** Enterprise software projects can take up to 18 months. During this time, it is common for that member of the Project team to move on. These [resources](https://spsingh.me/erp-project-team/) can be a vendor or your internal team. But, there is little that you can do about it. So, be ready for it and support your Project Manager to ensure a proper handover. Ensure to get a better replacement and strengthen the team during this disruption. ## 2. **Vendors may not deliver as per their promise** During the sales process, your expectations may be set too high. But, in reality, the [software vendor](https://www.lawinsider.com/dictionary/software-vendor#:~:text=Software%20Vendor%20or%20%E2%80%9C%20Vendor%20%E2%80%9D%20means%20the,Partner%20%E2%80%99s%20to%20market%20and%20resell%20the%20Products.) may not be able to keep their promise. It is not acceptable, but it is pretty common too. So, get involved if you experience that the vendor does not have a suitable solution. The vendor may offer to develop a custom solution to fit your business needs at an extra cost. Be prepared for this conversation. Always have a contingency budget in the back pocket from the project start. ## 3. **Priorities of your business changes** Due to the factors outside your control, the business priorities may change. Your project may be put on hold or even get cancelled. The business dynamics are such that priorities can change overnight. So, be prepared for this possibility. ## 4. **The Business is not engaged** Enterprise solutions are all about change. It is challenging the current state and moving to the new. You are likely to experience a few Business stakeholders that are unsupportive. Often this is due to the anxiety that change brings with it. So, support your team by preparing a plan and strategy for business engagement and change management. ## 5. **The Solution is not that easy as you think ** During the sales process, we all make many rough assumptions. We make a wild guess and hypothetically paint a picture for future Solutions. Initially, it makes sense. However, after project initiation, our initial assumptions do not always hold. We may experience that the Solution is much more complex. So, it may take more time and effort. This is a common scenario, so have a contingency for the project timeline, but keep it a secret. ## 6. **Incompetent resources are crippling the project** During the project, the Business stakeholders may keep changing their minds. They may not respond in time. You can experience a similar issue from vendor resources. The key is to get the right people upfront. Set the right expectations at the start. Keeping a close eye on the progress. Take quick action on incompetence. ## Summary – Manage your expectations Look, enterprise projects are complex. So, it would help if you are prepared for a possible bumpy road upfront. The key is to take minimum assumptions. Note and validate your assumptions. Set realistic expectations about the implementation. Good luck! --- --- title: "No one wants Vanilla! Secure Enough Budget For Customisations!" url: "https://spsingh.me/budget-for-customisations/" lang: "en-AU" type: "post" description: "Are you sponsoring an enterprise software project? The key message is: Secure enough budget for customisations and enhancements. Don't believe in the claims that standard enterprise software will fully meet your business needs. During the sales process, you may hear:" last_modified: "2026-05-19T17:36:04+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-18 20:54:56" --- # No one wants Vanilla! Secure Enough Budget For Customisations! Are you sponsoring an [enterprise software](https://spsingh.me/what-is-erp/) project? **The key message is:** Secure enough budget for customisations and enhancements. Don't believe in the claims that standard enterprise software will fully meet your business needs. During the sales process, you may hear: > “We recommend using the vanilla version of our product.” Or > “Our out of box solution will work for you.” Or > “We recommend not customising the solution. Instead, follow the best practice, change your business processes according to the software.” The message that the Sales team is giving you is: _Adopt the standard product. Make minimum customisations to minimise implementation costs. For example, change the business processes instead of significant changes in the software._ This message is valid within reason. Once you have selected the right Enterprise software (ERP/CRM) product, use its strengths to your advantage. However, you should never assume: ## Vanilla will satisfy everyone The standard out of box solution (vanilla version) will fulfil all the business needs. However, you need a budget to customise the user interface, workflows and automate manual processes. Further, you need a budget for reports, integrations, stationary/outputs (Invoice, PO). ## Customisations are bad If the customisations are improving efficiency (fewer clicks, automation), then encourage them. But do not fundamentally change the software. ## The Software Vendor’s assumptions are correct To keep the initial software implementation quote low, the vendors take many assumptions. They assume the standard product will meet your needs. Your team will learn the software and right and design all the reports, outputs. Further, they allow a limited budget for data migration, change management and User Acceptance Testing. During the implementation, you will experience change requests (extra budget requests) slipping in. ## Summary: Secure Enough Budget For Customisations! These assumptions are pretty common and misleading. So, be careful and test these assumptions with your team. Encourage your team to learn and adapt to the new enterprise solution. First, look at the solution with an open mind. Then, change the way you do things where appropriate. However, do not assume that a standard out of the box solution will satisfy all the business needs. You will need to customise the system to improve efficiency and automate processes. Hence, you need to allocate enough budget to customise the system to suit your needs. If you buy a Home and Land package, it is not wise to assume that all standard inclusions will satisfy your needs. For example, you will have additional requirements (premium windows, artificial grass). Further, the standard package does not always cover all basic needs (painting, paving). So, you must allow a budget for it. Remember, no one goes to Baskin Robbins and ask for Vanilla ice cream. We want to top it up with chocolate, caramel and nuts. It cost more, so carry enough cash. You will need it near the cash counter! ![budget for customisations](https://spsingh.me/wp-content/uploads/2021/11/anna-bratiychuk-3w2AuRZeeSU-unsplash-683x1024.jpg) Good luck! --- --- title: "Decision-Making Is a Discipline" url: "https://spsingh.me/decision-making-is-a-discipline/" lang: "en-AU" type: "post" description: "Decision-Making Is a Discipline I've been thinking about why smart, experienced people — people who clearly care about doing good work — still end up in situations that feel stuck. Not stuck in an obvious way. Stuck in the way" last_modified: "2026-05-18T13:06:41+00:00" categories: [The Sovereign Architect Series, Decision making] custom_fields: cos_headline_text: "Decision-Making Is a Discipline" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Decision-Making Is a Discipline # Decision-Making Is a Discipline I’ve been thinking about why smart, experienced people — people who clearly care about doing good work — still end up in situations that feel stuck. Not stuck in an obvious way. Stuck in the way where things look fine on the surface, the meetings are happening, the reports are going out, and yet somewhere underneath it all there’s a quiet unease. A sense that something important isn’t quite right, but it’s hard to name. I think a significant part of it comes down to this: most of us were never taught to treat decision-making as something you build deliberately. We were taught to make decisions. Not to understand them. That’s worth sitting with. ## Not All Decisions Are the Same Weight One thing that’s helped me think more clearly is recognising that we’re making three fundamentally different types of decisions — and they deserve very different amounts of our attention. **Micro decisions** are the daily automatic ones. Which meeting to take. How to respond to an email. These should cost us almost nothing. If they’re draining significant energy, that’s usually a signal that something in our systems or delegation isn’t working — not that we’re deciding badly. **Macro decisions** are the ones that shape direction. Which system to commit to. How to restructure a team. Who gets a critical role. These carry compounding consequences in both directions — and they’re expensive to reverse. A macro decision made in 2022 can still be shaping outcomes in 2026, through symptoms that nobody traces back to the original choice. **Strategic decisions** are the rarest. These are what Jeff Bezos called one-way doors — decisions where reversing course is genuinely costly or impossible. They deserve disproportionate care, not because the stakes are always visible in the moment, but because by the time they become visible, the decision has already been made. The pattern I notice most often — in organisations I work with, and honestly in my own thinking — is applying micro-decision energy to macro and strategic choices. Moving quickly because movement feels productive. Treating a two-hour workshop as a decision-making process when the decision actually needed weeks of careful consideration. ## What Gets in the Way We don’t usually struggle to decide. We struggle to understand what we’re actually deciding. **The cost of a bad decision is often invisible until it isn’t.** There’s a well-documented case from UK retail — a major ERP implementation where steering committees received green status reports for over a year. The system went live. Within months, significant inventory discrepancies surfaced, costing tens of millions to unwind. The critical decision wasn’t the go-live. It was made quietly, months earlier, when nobody adequately questioned data readiness. It took less time than a routine ops meeting. The problem wasn’t the decision itself. It was that nobody in the room had a clear picture of what getting it wrong would cost. I’ve sat in similar rooms. The pressure to keep moving is real. The discomfort of slowing down to ask hard questions is real. It’s not a character failure — it’s a system that rewards motion over meaning. **External noise can quietly replace internal judgment.** When “digital transformation” became the dominant industry narrative, many organisations committed to major programs not because they had a clear picture of their own need, but because not committing felt like falling behind. Some of those programs are still running — years past original timelines, well over budget, with benefits still unmeasured. We’re all subject to this. The last conference we attended, the vendor with the compelling demo, what peers in similar organisations are doing — these shape our thinking without always announcing themselves. Noticing that influence, and separating it from what your organisation actually needs, takes deliberate effort. **The decision often isn’t named clearly enough to be made well.** This one is subtle. Kodak’s leadership didn’t decide to ignore digital photography. They decided to protect film margins — which is a different decision, made with a different frame, producing a different outcome. The decision they thought they were making and the decision they were actually making weren’t the same thing. When we don’t name the decision accurately, we can optimise for the wrong outcome with perfect precision and complete sincerity. ## What the Discipline Might Look Like A few things seem to matter most. **Naming the decision type before making it.** Is this micro, macro, or strategic? One-way or two-way door? If that’s hard to answer quickly, it might be worth pausing before moving forward. **Matching effort to consequence.** Most of our attention goes to what’s urgent. Strategic decisions are rarely urgent — until they are. Creating protected time for the decisions that matter most, before they become crises, is something worth considering as a deliberate practice rather than an aspiration. **Creating conditions where truth can surface early.** The organisations that tend to make better decisions aren’t necessarily smarter. They’ve usually built environments where problems can be named before the status report is written, before the vendor relationship becomes political, before the sponsor has publicly committed. That kind of culture doesn’t happen by accident. **Expanding decision inputs deliberately.** Our instincts are shaped by our own experience — which means they have the sample size of one career. Independent perspectives, whether through advisors, mentors, or structured challenge, aren’t a sign of uncertainty. They’re a recognition that the higher we sit, the less unfiltered information tends to reach us. ## What I Keep Coming Back To Organisations don’t drift into difficulty because people stop caring or stop deciding. They drift because the decisions keep happening — at pace, habitually — without anyone examining whether the quality of the decision-making itself is holding up. The reports stay green. The milestones get checked. And somewhere underneath all of it, a decision made a year ago is quietly compounding into a problem that will take far longer and cost far more to correct than the original choice would have. That’s not a technology problem. It’s not usually a people problem either. It’s what happens when decision-making runs on autopilot — when we’re so focused on moving that we don’t stop to ask whether we actually understand what we’re deciding, and what it might cost if we’re wrong. The question worth sitting with isn’t whether we’re making decisions. We all are, constantly. It’s whether we’re building the discipline to make them well — or whether we’re leaving that to chance, and hoping the reports stay green long enough. _SP Singh is the founder of [Bhani Consulting](https://bhaniconsulting.com). He provides independent ERP oversight and advisory to executives in WA local government, Aboriginal corporations, and mid-sized organisations. [bhaniconsulting.com](https://bhaniconsulting.com)_ --- --- title: "The Hidden Cost of Drift" url: "https://spsingh.me/the-hidden-cost-of-drift/" lang: "en-AU" type: "post" description: "The Hidden Cost of Drift Most organisations do not lose value in one big moment. They lose it slowly. A project starts with good intent. A system needs replacing. Reporting needs improving. Processes need to be cleaned up. Everyone agrees" last_modified: "2026-05-17T13:02:24+00:00" categories: [The Sovereign Architect Series, Project Assurance] custom_fields: cos_headline_text: "The Hidden Cost of Drift" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Hidden Cost of Drift # [The Hidden Cost of Drift](https://spsingh.me/the-cost-of-drift/) Most organisations do not lose value in one big moment. They lose it slowly. A project starts with good intent. A system needs replacing. Reporting needs improving. Processes need to be cleaned up. Everyone agrees something needs to change. At the start, the direction feels clear. Then drift begins. A few decisions are delayed. A few workarounds are accepted. A few risks are softened. A few people [assume](https://spsingh.me/why-organisations-feel-complex/), “We can handle this ourselves.” A few meetings happen without real decisions. Nothing looks seriously wrong. But the project has started moving away from the outcome it was meant to deliver. That is drift. ## Drift Looks Like Progress This is why drift is dangerous. The project still looks active. Workshops are happening. Vendors are attending meetings. Status reports are being shared. People are working hard. Money is being spent. But activity is not the same as progress. The organisation may be spending capital, time, and resources while slowly losing direction. And because the loss is not always measured, it can stay hidden for too long. The bottom line is being affected, but not always in a way that appears clearly in the project budget. ## [The Cost Is Bigger Than Money](https://spsingh.me/the-cost-of-drift/) When direction is lost, the organisation does not only lose money. It loses opportunity. It loses reputation. It loses trust. It loses internal confidence. It also creates a bad taste for future change. People remember difficult projects. They remember unclear decisions, repeated workshops, poor communication, and systems that go live but do not make work easier. The next time leadership announces a new [initiative](https://spsingh.me/what-is-digital-transformation/), people may not say much. But inside, they think: “Here we go again.” That is one of the biggest costs of drift. ## [Doing It All Internally Can Increase the Risk](https://spsingh.me/the-trap-of-doing-everything-ourselves/) Many executives assume the organisation can manage a technology initiative internally because their people know the business. And they do. But knowing the business is not the same as knowing how to lead a technology change. A payroll system is not just payroll. It touches HR, finance, timesheets, leave, awards, reporting, approvals, compliance, and manager accountability. An ERP is not just a system. It shapes how the organisation buys, pays, reports, controls, manages, and makes decisions. A CRM is not just a customer database. It only creates value if people use it consistently and leaders trust the information. If internal teams have not led this kind of work before, the risk is not incompetence. The risk is blind spots. ## [The Real Problem](https://spsingh.me/what-good-erp-governance-actually-looks-like/) The problem is not doing the work internally. The problem is doing it without enough structure, challenge, and experience. That is when small decisions create large consequences. Old processes get copied into new systems. Reporting is left for later. Workarounds become permanent. Vendors are not challenged properly. People focus on getting to go-live instead of protecting the business outcome. [The project may still finish](https://spsingh.me/erp-project-looks-fine/). But the value may not arrive. ## What [Executives Should Watch](https://spsingh.me/what-good-erp-governance-actually-looks-like/) Executives should watch for simple signs of drift: decisions keep moving; risks sound vague; reports are positive but thin; people are busy but unclear; benefits are no longer discussed; the vendor is driving the agenda; the goal becomes “just get to go-live.” When this happens, the project may still be alive, but the value may already be leaking. ## The Point Drift is quiet. It does not always announce itself as failure. It hides behind meetings, updates, activity, and effort. But the cost is real. [Loss of direction](https://spsingh.me/erp-is-not-failing/). Loss of opportunity. Loss of reputation. Loss of trust. Loss of capital. Loss of time. Loss of resources. Loss of energy. And eventually, loss of belief. That is why technology initiatives need more than good intent and capable people. They need direction, structure, challenge, and honest measurement. Otherwise, the organisation may reach go-live and still lose the value it set out to create. --- --- title: "The Budget Number Is Not What You Think It Is" url: "https://spsingh.me/project-budget/" lang: "en-AU" type: "post" description: "The Budget Number Is Not What You Think It Is Most executives treat a project budget like a fixed truth. An amount of money required to deliver a defined outcome. The vendor quotes it. The board approves it. The program" last_modified: "2026-05-19T13:31:51+00:00" categories: [Project Sponsorship] tags: [budget, Project budget, software project budget] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-16 20:53:25" cos_headline_text: "The Budget Number Is Not What You Think It Is" cos_seo_score: 0 cos_headline_score: 0 --- # The Budget Number Is Not What You Think It Is ## The Budget Number Is Not What You Think It Is Most executives treat a project budget like a fixed truth. An amount of money required to deliver a defined outcome. The vendor quotes it. The board approves it. The program is measured against it. That framing is costing you more than you realise. A project budget is not a truth. It is an anchor. The first number set in a negotiation — and like all anchors, its primary function is to shape everything that comes after it. Here is what that looks like in practice. ## Scenario 1 Your vendor estimates internally that the implementation will cost $500K. They add $250K contingency and propose $750K on a time-and-material basis. You accept. They deliver at $700K. You celebrate. Under budget. Well managed. Everyone is pleased. The reality: assuming the original estimates were accurate and no scope was added, the vendor spent $200K more than the work required. You paid it without knowing. The budget was never a reflection of what the work should cost — it was a ceiling set high enough to look good when they came in under it. The anchor did its job. ## Scenario 2 The same vendor estimates $500K internally. This time, they challenge their team on the estimates, tighten the scope, and propose $400K. You accept. Mid-delivery, they identify a genuine gap and request an additional $50K with documented justification. You are frustrated. This feels like a blowout. You approve it reluctantly. The project completes at $450K. You have saved $250K compared to Scenario One. The work cost what it should have cost. And yet the experience felt worse — because the anchor was set honestly and the reality brushed against it. ## What this tells you The budget game is not neutral. It rewards vendors who set high anchors and punishes vendors who set honest ones. The executive who received Scenario Two got a better outcome and a worse feeling. The executive who received Scenario One overpaid by $200K and called it a win. ![Project budget](https://spsingh.me/wp-content/uploads/2021/10/krakenimages-376KN_ISplE-unsplash-1024x683.jpg) This is not a market failure. It is a rational response to how project budgets are evaluated. Vendors learn quickly that the number to manage is not the actual cost — it is the expectation set at the start. Understanding this does not make you cynical. It makes you a more capable sponsor. When you receive a budget proposal, the question is not “can they deliver under this number?” The question is: _what assumptions is this number built on, and who benefits if those assumptions are generous?_ Ask for the estimate that sits underneath the budget. Ask what contingency has been included and on what basis. Ask what the vendor’s internal target is, not just what they’re proposing to you. The budget is where the program’s honesty is first established — or first obscured. Everything that follows is shaped by what happens at that point. _SP Singh provides independent ERP oversight and advisory to WA local government and Aboriginal corporations. He writes daily at spsingh.me._ --- --- title: "Problem Vs Requirement – The Top Budget Killer!" url: "https://spsingh.me/problem-vs-requirement/" lang: "en-AU" type: "post" description: "Problem Vs Requirement - do you know the difference? When you visit a doctor, he asks for symptoms of your problem. He then writes a prescription to solve your problem. Note that he does not ask about your needs or" last_modified: "2026-05-17T18:36:03+00:00" categories: [Project Sponsorship] custom_fields: ampforwp-amp-on-off: "default" cos_headline_score: 0 cos_seo_score: 0 cos_headline_text: "Problem Vs Requirement - The Top Budget Killer!" wpar_republish_meta_query: "2026-05-16 20:51:25" --- # Problem Vs Requirement – The Top Budget Killer! Problem Vs Requirement – do you know the difference? When you visit a doctor, he asks for symptoms of your problem. He then writes a prescription to solve your problem. Note that he does not ask about your needs or requirements. Note the difference between Problem Vs Requirement. [Enterprise Solution (ERP/CRM) ](https://spsingh.me/what-is-erp/)consultants should be no different. First, they should assess the symptoms and root cause of the problems. Then, with the help of a given ERP/CRM product, propose a solution to address the given problems. But, often, they ask the Business stakeholders – “What are your requirements?” - _What are the requirements of the [Sales Order](https://tallysolutions.com/inventory/sales-order/) entry process?_ - _What are the requirements for the Accounts Payable invoice approval?_ - _What are the requirements of the input fields?_ - _Which buttons do you like us to be available on the screen/form/program?_ Sounds familiar? Then, they go on a pursuit of customising the packaged solution to meet the requirements. The standard response on querying about heavy customisations is: _“These are customer requirements!”_ Due to this lousy approach, the project cost skyrockets—the delivery time and stress increase manifold. It is the top budget killer! As a sponsor, consider whether consultants are ‘analysing problems’ or ‘asking for requirements’. If you spot the latter, then stop it immediately at every cost! ![Problem Vs Requirement](https://spsingh.me/wp-content/uploads/2021/10/Problem.png) --- --- title: "Every long-term entity has a Roadmap" url: "https://spsingh.me/every-long-term-entity-has-a-roadmap/" lang: "en-AU" type: "post" description: "Every long-term entity has a Roadmap. The question is who built yours. Life has one. A product has one. Infrastructure has one. A business has one. Technology programs have one. Your career has one. But here's what most executives never" last_modified: "2026-05-16T12:47:28+00:00" categories: [The Sovereign Architect Series, Project Assurance] custom_fields: cos_headline_text: "Every long-term entity has a Roadmap" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Every long-term entity has a Roadmap ## **[Every long-term entity has a Roadmap](https://spsingh.me/are-you-leading-this-project-or-is-it-leading-you/). The question is who built yours.** Life has one. A product has one. Infrastructure has one. A business has one. Technology programs have one. Your career has one. But here’s what most executives never stop to examine: a significant number of the roadmaps you’re operating on right now were never designed by you. They were handed to you. And you followed them anyway — not because you chose to, but because the path was already paved before you arrived. Think about it. The milestones of a human life — school, university, first job, mortgage, marriage, children, retirement — these aren’t universally chosen. They’re inherited. Built into the culture, the curriculum, the financial system. The roads you drive on, the platforms your organisation runs on, the processes your team follows — most of these predate your decisions. [You stepped into them](https://spsingh.me/why-do-we-complicate-things/). You adapted to them. You optimised within them. That’s not failure. That’s how systems work. The problem is when we mistake _[following a predefined roadmap](https://spsingh.me/the-question-your-vendor-will-never-ask-you/)_ for _having a strategy_. There are really only four ways a roadmap gets built: **Strategically** — You start with your goals and develop the roadmap to reach them. The map serves the destination. **Blindly** — You inherit a roadmap predefined for you and follow it without questioning whether it leads where you actually want to go. **Reactively** — You develop your roadmap around what’s urgent. Not what’s important. The loudest problems become the plan. **Retrospectively** — You build the roadmap backwards, to justify decisions already made. The strategy is written after the knee-jerk. The documentation catches up to the action. Most organisations — if they’re honest — are operating on some combination of the last three. The retrospective roadmap is the one that should concern executives most. It looks like planning. The slides are professional. The logic is coherent. But the sequence is inverted. The decision came first. The roadmap was constructed to defend it. This isn’t dishonesty, usually. It’s the natural result of pressure, speed, and the organisational instinct to protect commitments once made. But it means your roadmap isn’t leading your goals. It’s trailing your ego. Out of all four approaches, only one is likely to help you achieve what you actually set out to achieve: a [strategic roadmap](https://spsingh.me/why-no-one-owns-organisational-improvement/) that begins with clarity about where you’re going — before you commit resources, before you sign contracts, before the urgency machine takes over. It sounds obvious. Most important things do. The harder question is whether your current roadmaps — across your technology programs, your organisation, your own career — were built strategically, or whether they were inherited, reactive, or constructed after the fact to make sense of decisions already locked in. Most leaders, when they examine it honestly, find the answer is more complicated than they expected. Are you ready to look? _This is the work I do with executives sponsoring technology programs — not building the roadmap for them, but helping them see clearly whether the one they’re operating on is actually theirs._ --- --- title: "The Basics Are Not Beneath You!" url: "https://spsingh.me/the-basics-are-not-beneath-you/" lang: "en-AU" type: "post" description: "The Basics Are Not Beneath You Most things worth doing are simple. Not easy. Simple. A healthy body. Financial stability. Strong relationships. The principles aren't complicated — consistency, attention, honest feedback, and a willingness to adjust when something isn't working." last_modified: "2026-05-15T14:33:45+00:00" categories: [The Sovereign Architect Series, Project Assurance] tags: [ERP] custom_fields: cos_headline_text: "The Basics Are Not Beneath You!" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Basics Are Not Beneath You! # The Basics Are Not Beneath You Most things worth doing are simple. Not easy. Simple. A healthy body. Financial stability. Strong relationships. The principles aren’t complicated — consistency, attention, honest feedback, and a willingness to adjust when something isn’t working. Most people know this. Most people also skip it. They look for the sophisticated approach. The advanced framework. The shortcut that justifies bypassing the fundamentals. Successful ERP implementations follow the same logic. Learn the basics. Apply them consistently. Observe what’s actually happening. Refine. Repeat. The principle is the same across all of it. The discipline required to follow it is also the same. So why do so many ERP programs fail? ## The Executive Assumption Here is what I observe, consistently, across programs that drift into trouble. Executives assume they already know the basics. That assumption is the problem. Not the vendor. Not the software. Not the implementation team — though the team will carry the weight of the failure when it arrives. The assumption shows up in four specific behaviours: **We tell more than we listen.** A steering committee is not a reporting session. It is a diagnostic session. The executive’s job is to ask the questions that surface what the status report is hiding — not to confirm what the project team already believes. When executives do most of the talking, they forfeit the one thing their position gives them: the ability to hear the truth before it becomes a crisis. **We keep ourselves busy with optimistic views.** Optimism is not a governance strategy. A project that looks fine in every report while quietly accumulating scope creep, unresolved decisions, and vendor dependency is not a healthy project — it is a project where the reporting has been calibrated to match the executive’s mood. If the news is always good, the system is broken, not the news. **We give raw, untested decisions.** Executives are expected to make decisions. What is less understood is that the quality of executive decisions in ERP programs depends almost entirely on the quality of information feeding those decisions. When an executive arrives at a steering committee without having read the materials, without independent visibility, and without a clear framework for what they’re governing — the decisions they make are not informed. They are instinctive. And instinct, applied to complex technology programs mid-delivery, tends to produce expensive mistakes. **We confuse presence with governance.** Attending a steering committee is not the same as governing a program. Signing off on a status report is not oversight. These are motions. Real governance requires a clear standard — defined in advance — for what executive control is supposed to look like. Without it, there is nothing to hold the line on when the program starts to drift. ## No Wonder And then we wonder why ERP projects fail. No wonder. We haven’t followed the basics. A healthy body requires consistent attention to fundamentals — sleep, nutrition, movement — not just when something goes wrong, but as a standing discipline. A financially stable organisation requires consistent attention to cash flow, not just at year-end. Strong relationships require consistent honesty, not just during conflict. ERP governance is no different. The basics are not beneath you. They are the work. The discipline of showing up with independent information, asking uncomfortable questions, and holding a defined standard — that is what executive governance actually looks like. It is not glamorous. It does not require a sophisticated framework. It requires consistency, honesty, and the willingness to hear things you would rather not. Most programs that drift into failure do not lack sophisticated technology. They lack executives who were willing to follow the basics — consistently, honestly, and before the cost of correction became too high. The principle is simple. Applying it requires something harder than intelligence. It requires discipline. _SP Singh is the founder of [Bhani Consulting](https://bhaniconsulting.com), providing independent ERP oversight and advisory to WA local government and Aboriginal corporations. He writes daily at spsingh.me._ --- --- title: "Your ERP Program Has Five Dimensions" url: "https://spsingh.me/your-erp-program-has-five-dimensions/" lang: "en-AU" type: "post" description: "Your ERP Program Has Five Dimensions. Most Steering Committees Watch One. What you're monitoring, what you're missing, and why the gap between them is where programs go wrong. You get a status report every fortnight. It tells you the program" last_modified: "2026-05-14T14:06:40+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Your ERP Program Has Five Dimensions" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Your ERP Program Has Five Dimensions # Your ERP Program Has Five Dimensions. Most [Steering Committees](https://spsingh.me/what-your-steering-committee-is-missing/) Watch One. _What you’re monitoring, what you’re missing, and why the gap between them is where programs go wrong._ You get a status report every fortnight. It tells you the program is on track. Milestones are green. Budget is within tolerance. The vendor is confident. Your project team is busy. And somewhere underneath all of that, something nags. You can’t name it precisely. You’re not a technical person — that’s not your job. Your job is to make sure the organisation gets what it paid for. But the reports you’re receiving are written to manage your concerns, not to surface them. And you sense that. That instinct is correct. The problem isn’t that your program is failing. The problem is that the monitoring structure you’ve been given is watching the wrong things — or more accurately, not enough of the right things. Most [steering committees](https://spsingh.me/why-most-steering-committees-add-no-value/) monitor one dimension of an ERP program: [delivery](https://spsingh.me/your-erp-project-is-green/). Are we on [scope](https://spsingh.me/what-your-steering-committee-is-missing/)? Are we on budget? Are we on time? These matter. But delivery is just one of five dimensions running simultaneously through every technology program. The other four are moving whether anyone is watching them or not. This article walks through all five. For each one, I’ll tell you what you can see from the front of the room — and what you should also be able to see, but probably can’t. ## 1. Delivery: The one dimension everyone watches — and still misreads What you can see: [scope](https://spsingh.me/why-most-steering-committees-add-no-value/), budget, timeline, quality gates. The classic project triangle. Your status report covers all of this. You have a RAG status. You have milestone dates. What you should also be asking: are those milestones still measuring what they were designed to measure? This is the subtlest and most common failure in delivery oversight. Milestones drift in definition without anyone formally changing them. A sign-off that was supposed to represent genuine acceptance of completed work becomes a courtesy gesture — a date being preserved because renegotiating it would require a difficult conversation. A budget that was “within tolerance” in Month 4 is within a tolerance that has been quietly redefined since Month 2. The scope question is the same. Scope changes are supposed to be formally governed — assessed, approved, logged, and their implications worked through. In practice, they are often absorbed. The program team accommodates a change to keep the vendor relationship smooth, or to avoid slowing things down. Nobody lies. Nobody formally agrees to change the scope. It just narrows. What you’re left with is a program that is technically on track, delivering something materially different from what was approved. The honest question here isn’t “are we on scope?” It’s: _who has independently verified that what we’re building still matches what was approved — and that [acceptance criteria](https://spsingh.me/what-your-steering-committee-is-missing/) are being met, not just signed?_ ## 2. [Data and system readiness](https://spsingh.me/why-erp-programs-become-messy/): The dimension that’s always ‘in progress’ You’ve heard the phrase “data migration is underway” so many times it no longer produces anxiety. It should. What you can see: a data migration workstream. Status: in progress. Percentage complete: climbing slowly. What you should also be seeing: a data quality profile that was done at the beginning of the program — showing where the gaps are, what clean looks like, and who owns the remediation. A named person accountable for getting your data into a state that the new system can actually use. A date by which that work must be done, working backwards from go-live with real margin. Most programs don’t have this. They have a workstream. The workstream has tasks. The tasks are moving. But no one has formally confronted the question: _is the data actually going to be ready — and what happens to the program if it isn’t?_ The same pattern appears in security and privacy, architecture compliance, and scalability. These aren’t things that get done at the end. They are disciplines that run through the whole program. If they’re not being monitored as independent dimensions — with owners, standards, and governance — they get deferred. And deferred technical work has a way of becoming post-go-live crisis. The honest question: not “is data migration in progress?” but _what is the current quality of our data against the requirements of the new system, and what is the confirmed plan to close the gap before go-live?_ ## 3. [Reporting and visibility](https://spsingh.me/what-good-erp-governance-actually-looks-like/): The dimension that determines whether you can see the others This one is different from the rest. It doesn’t describe something happening in the program. It describes your ability to see what’s happening in the program. If this dimension is broken, everything else goes dark. What you can see: status reports, RAG dashboards, steering committee presentations. They exist. They arrive on schedule. They have structure. What you should also be asking: are these reports designed to surface risk, or to manage it? There’s a structural problem in most program reporting. The people preparing the reports are either part of the delivery team, or dependent on it for their information. They are not independent. That doesn’t make them dishonest. It means they are subject to the same pressures the whole team is subject to: don’t slow things down, don’t alarm the executive, don’t escalate unless you have to. The result is reports that accurately describe motion — tasks completed, meetings held, issues logged — without accurately describing meaning. Whether the decisions being made are the right decisions. Whether the issues being logged are the ones that actually matter. Whether the milestones being hit still represent what they were supposed to represent. The decision audit trail is part of this. When scope changes, when budget revisions occur, when the timeline shifts — is there a written record of who decided and on what basis? Or do those decisions happen in conversations, and the steering pack just shows the new baseline as though it always existed? The honest question: _if something were seriously wrong in this program right now — would your current reporting structure surface it, or suppress it?_ ## 4. People and change: The dimension that’s always a slide in the steering pack This is where most programs quietly fail. Not at the technology layer. At the human one. What you can see: a change management workstream. A communications plan. Training scheduled. A go-live date with user preparation activities listed. What you should also be seeing: evidence that the organisation is actually changing, not just being informed about change. Ongoing signals about how end users are responding — not anecdotally, but systematically tracked. A training program designed around the specific system going live, not a generic curriculum built six months before the configuration was finalised. A plan for what happens when staff turn over after go-live, which they will. The gap between the project team’s confidence and the end user population’s readiness is one of the most reliable leading indicators of a troubled go-live. The project team has been living in this system for months. They know how it works. They believe in it. They have forgotten how foreign it will feel to someone encountering it for the first time, under operational pressure, with no runway to make mistakes. The other thing to watch is whether the organisation is genuinely improving its processes through this program — or simply replicating the old ones in new software. ERP implementations have a way of allowing years of accumulated workarounds and broken processes to get quietly baked in to the new system. The technology becomes a permanent home for dysfunction that should have been addressed. The honest question: _if you asked twenty end users today what they know about the new system and whether they feel prepared, what would they tell you — and does your steering committee know the honest answer?_ ## 5. [Strategic value](https://spsingh.me/your-erp-project-is-green/): The dimension that was defined at the beginning and forgotten by Month 3 Your program was approved on the basis of a business case. That case made commitments — financial, operational, strategic. Efficiency gains. Improved reporting. Cost reductions. Better governance. Someone presented those numbers. Someone signed off on them. What you can see: the program is delivering the agreed scope, within the agreed budget, against the agreed timeline. What you should also be asking: is what’s being delivered still connected to what was promised? Business cases get orphaned. Not through any decision to abandon them — just through drift. As scope gets absorbed, adjusted, quietly narrowed, the program shifts away from the original intent. The [benefits](https://spsingh.me/your-erp-project-is-green/) that were promised start to depend on things that are no longer being built. Nobody notices, because nobody is watching the business case against the program with any regularity. Benefits realisation is part of this. Most programs have a benefits owner in name. In practice, that person is waiting for post-go-live to start tracking anything — because the benefits were projected to materialise after implementation. But leading indicators exist. And if nobody is tracking them now, the post-go-live discovery that benefits aren’t materialising will be framed as a surprise. It isn’t a surprise. It’s a gap that was visible from the beginning to anyone watching the right things. The honest question: _can you connect what your program is currently building, right now, to the specific commitments made in the approved business case — and do you have a plan to actually measure whether those commitments were delivered?_ ## What this adds up to Five dimensions. Most steering committees have structured oversight of one. The others are either embedded in delivery reporting (where they can get quietly managed), deferred to post-go-live, or simply not being monitored. The risk is not that your program is failing. The risk is that you won’t know it’s failing until the cost of correction has compounded. Each of these dimensions needs a nominated owner, a monitoring standard, and a reporting rhythm that is independent from the delivery team’s incentives. Together, they give you one complete answer to one question that you should be able to answer with confidence at every steering committee: _What is actually happening in this program — and where is it drifting?_ If you can’t answer that question cleanly, the issue isn’t the program. The issue is what you’ve been given to watch it with. _SP Singh is the founder of [Bhani Consulting](https://bhaniconsulting.com). He provides independent ERP oversight and advisory to WA local government, Aboriginal corporations, and mid-sized organisations. He is a WALGA panel member and has twenty years of experience inside enterprise software programs from both sides of the table._ _If you’re mid-delivery and suspect something is drifting, the [Executive Visibility Review](https://bhaniconsulting.com/) gives you independent visibility into what’s actually happening — in three to five weeks._ --- --- title: "Software Selection: The Deceptive World of Software Sales!" url: "https://spsingh.me/software-selection/" lang: "en-AU" type: "post" description: "If you are deciding on Enterprise software for your organisation, then read this carefully! Welcome to the deceptive world of Software Sales Look, if you are not vigilant, you can make a terrible decision very quickly. During software selection, you" last_modified: "2026-05-15T05:45:01+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" cos_headline_text: "Software Selection: The Deceptive World of Software Sales!" cos_seo_score: 0 cos_headline_score: 0 wpar_republish_meta_query: "2026-05-13 21:22:44" --- # Software Selection: The Deceptive World of Software Sales! If you are deciding on [Enterprise software](https://spsingh.me/what-is-erp/) for your organisation, then read this carefully! ![software selection](https://spsingh.me/wp-content/uploads/2021/10/leon-bzqU01v-G54-unsplash-1024x683.jpg) ## **Welcome to the deceptive world of Software Sales** Look, if you are not vigilant, you can make a terrible decision very quickly. During software selection, you are dealing with one of the best salespeople. So, you must be hearing all the right words from them. You may develop a good level of trust and relationship. There is nothing wrong with this as long as you do not decide a software with blind trust, emotion or pressure. Software Sales professionals are trained to win your confidence. They develop a legitimate-looking relationship and win trust. Unfortunately, while they may be good people, they may not have a good product. The product demos you have seen so far can be smoke and mirrors. They can be pretty deceptive. ## **The priorities are different** Software Sales remuneration depends on the sale of licenses and professional services. Therefore, irrespective of title (Business Development Manager, Account Manager), the sales bonus is tied to the volume of licenses sales. Unfortunately, it is not based on the success of your project. So, beware of blind trust and be ruthless in your pursuit to find the right software for your business. ## **The Presales Consultant** That consultant who appears to know your business quite well. The one who is showing you a dream software solution. He is part of presales and not delivery. So, please do not assume that he is there to stay on your project. His job is to get you over the line and support the Sales team for another sale. So, you must find out the capability of the Delivery team. The Sales team hands it over to the Delivery team after you sign the dotted lines. So, before you sign the contract, ensure that you have quality project resources on the project. ## **Software selection is a complex activity** On the surface, enterprise software selection may look simple. Yet, there are so many things for you to consider: - Current business needs - Future business needs - Implementation cost - Software license cost - Support cost - Onsite resources and availability - Support of different time zones, languages, country-specific legislation, and rules - Integrations - Data Migration - Reports - Outputs - Training and Testing - Go Live Support - Business process and change management - Reference checks - Contract review and negotiations ## **Buy an insurance policy for Software Selection** It would help if you were not on this journey alone. Seek help from the [independent consultant](https://spsingh.me/services/) and avoid making a costly mistake. The investment in consulting services is like an insurance policy. Cover yourself and engage a capable consultant who can help you. Get the right people for this job, follow a tried and tested process. Then, make informed decisions supported by facts with the Big picture in mind. Good luck! --- --- title: "Celebrate Project Closure With Heart And Soul! Your Team Will Love You For It!" url: "https://spsingh.me/celebrate-project-closure/" lang: "en-AU" type: "post" description: "How to celebrate project closure with heart and Soul? We often start projects with a kick-off but seldom finish them with celebration. Very few projects are lucky enough to meet a graceful end, and the team sit together and celebrate." last_modified: "2026-05-14T17:36:03+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-13 21:21:44" --- # Celebrate Project Closure With Heart And Soul! Your Team Will Love You For It! How to celebrate project closure with heart and Soul? We often start projects with a kick-off but seldom finish them with celebration. Very few projects are lucky enough to meet a graceful end, and the team sit together and celebrate. > Why is that? Maybe, you as [Project Sponsor](https://www.projectmanager.com/blog/what-is-a-project-sponsor#:~:text=The%20project%20sponsor%20is%20a,the%20reason%20for%20the%20project.) or Manager, is too busy to bother? There is always a next big thing (a distraction) that serves as an excuse not to bother to celebrate with the team.** If you are one of such busy managers, then stop and pay attention to the rest of the article!** ![celebrate project](https://spsingh.me/wp-content/uploads/2021/10/kelsey-chance-ZrhtQyGFG6s-unsplash-1024x683.jpg) Look, [technology projects](https://spsingh.me/what-is-erp/) are full of challenges and bitter surprises. The project team puts much effort to make the project a success. It is difficult to deliver solutions in the tight constraints of budget, time and quality. We all know the feeling when we are stuck with a problem but do not know a viable solution. So we think day and night to work out a solution. You Project teams go through such cycles of sleepless nights many times within the project. Few of them often put their heart and soul into the project. So, it is uncool not to stop, say thank you and celebrate project closure with them! To ensure you do not put this celebration on a backburner, schedule a day to celebrate and announce it. When the day is locked, rest everything will now come to its place. ## **Let us talk about what celebrate project closure is not:** - It is not celebrating that the project is finally over - It is not lessons learnt discussion - It is not a project review or audit - It is not choosing star project resources and giving them badges - It is certainly not about you and your contribution to the project Instead, it is about getting together as one team and acknowledging the team’s hard work and dedication. So, prepare for this by sharing real stories and experiences, focusing on the contribution of the project team. Pick examples where the team has gone above and beyond their responsibility to get the project over the line. Your focus should be project team, and you must prepare to make this celebration worthwhile and rememberable. You may think to announce your sacrifices on the project. But, as much it sounds great to share your challenges, contribution, and rescue strategies during the celebration, save them for some other day. You are celebrating the achievements of your team! So, wholeheartedly acknowledge the hard work, contribution and dedication of your team. Share memories to cherish! Bring awesome food! Create a special environment! Stop everything else! Celebrate project closure from your Heart and Soul! I hope you have a great time with your team! --- --- title: "Your ERP Project Is Green- Why Is It Still A Problem?" url: "https://spsingh.me/your-erp-project-is-green/" lang: "en-AU" type: "post" description: "Your ERP Project Is Green. The dashboard says everything is on track. Scope — controlled. Budget — within tolerance. Timeline — amber at worst, green most weeks. The steering committee gets its report. The sponsor nods. The project moves forward." last_modified: "2026-05-13T13:08:55+00:00" categories: [Project Assurance, The Sovereign Architect Series] custom_fields: cos_headline_text: "Your ERP Project Is Green- Why Is It Still A Problem?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Your ERP Project Is Green- Why Is It Still A Problem? # [Your ERP Project Is Green](https://spsingh.me/what-good-erp-governance-actually-looks-like/). The dashboard says everything is on track. [Scope — controlled](https://spsingh.me/what-good-erp-governance-actually-looks-like/). [Budget — within tolerance](https://spsingh.me/what-good-erp-governance-actually-looks-like/). Timeline — amber at worst, green most weeks. [The steering committee](https://spsingh.me/what-your-steering-committee-is-missing/) gets its report. The sponsor nods. The project moves forward. What could go wrong? # The Five Numbers Executives Are Taught to Trust There is a standard model for tracking project health. It has been taught in project management courses, embedded in governance frameworks, and repeated in steering committee templates across every industry for thirty years. It goes like this: if you monitor five dimensions — scope, budget, timeline, quality, and risks and issues — you will know whether your program is in trouble. This model is not wrong. It is incomplete in a way that looks like being right. Executives who rely on it are not being careless. They are being rational. They are using the instrument they were given, reading the dials they were told to watch, and making decisions based on what those dials say. The problem is not the executives. The problem is what the instrument cannot see. # What the Reports Don’t Show Here is what I have watched happen, more than once, in programs where every dimension stayed green: The project reaches [go-live](https://spsingh.me/erp-journey-actually-begins-after-go-live/). Months pass. The business benefits that justified the investment never materialise. No one can point to where they went — they were simply never operationalised. The project team, supposedly wound down, is still being pulled in to fix issues that should have been resolved before cutover. Data quality is poor enough that people have stopped trusting reports from the new system — which means the system is being ignored in the decisions it was meant to inform. Integration with other enterprise applications is partial or broken. And quietly, without announcement, end users have rebuilt their spreadsheets. The system is running. The workarounds are running alongside it. The [reports were green](https://spsingh.me/why-erp-programs-become-messy/). The outcomes were not. # Why the Model Fails at the Finish Line The five dimensions measure the delivery of a project. They do not measure the realisation of its purpose. **Scope asks**: did we build what we said we’d build? It does not ask: was what we built actually adopted, embedded, and used to change how decisions get made? **Budget asks**: did we spend what we planned to spend? It does not ask: did that spending produce the return it was supposed to produce? **Timeline asks**: did we go live when we said we would? It does not ask: were the people, processes, and integrations actually ready when we did? The model was designed to protect delivery. Organisations use it as if it protects outcomes. Those are different things, and the gap between them is where value leaks. There is a structural reason this persists. [Project governance](https://spsingh.me/what-your-steering-committee-is-missing/) is built around the delivery phase. [The steering committee](https://spsingh.me/why-most-steering-committees-add-no-value/) meets regularly while the program is in flight. Once [go-live](https://spsingh.me/who-owns-erp-after-go-live/) happens, the governance dissolves — right at the moment when the real work of embedding begins. The instrument gets switched off just when the most consequential reading needs to be taken. # The Cost of Finding Out Late The consequences of a green-reported failure are not just financial, though they are always financial. They are institutional. When the system goes live and the benefits don’t follow, what erodes first is trust — in the system, in the team that delivered it, and in the executive who sponsored it. End users lose confidence and find workarounds. Those workarounds become entrenched. The organisation pays twice: once for the system it bought, and again to maintain the shadow processes that replaced it. The harder the sponsoring executive pushed for the project, the more reluctant they become to name what went wrong. Protecting the decision becomes more important than correcting it. And so the drift continues — not because no one sees it, but because naming it has a political cost that staying quiet does not. # The Question Worth Asking in the Boardroom [The right question](https://spsingh.me/the-question-your-vendor-will-never-ask-you/) is not: did the project deliver on its dimensions? The right question is: what did we build this for — and is the organisation now living differently because of it? That reframe shifts the unit of accountability. It moves from the project team to the executive sponsor. It connects delivery to outcomes rather than treating them as separate events. And it changes what governance needs to watch. A holistic view of a technology program includes the traditional five dimensions, but it also includes the rationale that justified the investment, the post-go-live ecosystem that determines whether the system gets used, and the human change that has to happen before any of that is possible. These are not soft add-ons. They are the conditions under which the money spent returns as value. If your governance framework doesn’t cover them, you are not flying blind — you are flying with instruments that only show part of the picture, while assuming they show all of it. # The Conversation to Have Before the Next Steering Committee If you are currently sponsoring a technology program, or preparing to sign off on one, there are three questions worth sitting with: **What outcome did we commit to — and how will we know if we’ve achieved it?** Not delivery. Not go-live. The outcome. If this can’t be answered in one clear sentence, the governance framework has a gap at its foundation. **What happens after go-live?** Who is responsible for adoption, for integration, for the human change that has to accompany the technical change? If the answer is “the project team wraps up and the business takes over,” ask what that handover actually looks like in practice. **What am I not being shown?** Every Steering Committee report is curated. Not dishonestly — but optimistically, and by people whose job it is to keep the program moving. An independent set of eyes, with no stake in the delivery outcome, will see things the internal view cannot. Green is not the same as fine. The sooner that distinction is built into how programs are governed, the less expensive the lesson becomes. --- --- title: "The cost of drift" url: "https://spsingh.me/the-cost-of-drift/" lang: "en-AU" type: "post" description: "You Are Not Paying for Your ERP Program You are paying for your reluctance to make hard calls inside it- The cost of drift. Most executives assume the cost of a struggling technology program is the number on the variance" last_modified: "2026-05-12T13:47:44+00:00" categories: [The Sovereign Architect Series, Project Assurance] custom_fields: cos_headline_text: "The cost of drift" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The cost of drift **You Are Not Paying for Your ERP Program** You are paying for your reluctance to make hard calls inside it- [The cost of drift](https://spsingh.me/hard-to-fight-against-the-status-quo/). Most executives assume [the cost of a struggling technology program](https://spsingh.me/what-is-the-cost-of-incompetence/) is the number on the variance report — the budget overrun that needs explaining at the next steering committee. That number is visible. It feels like the problem. It isn’t. The visible number is almost never where the real cost lives. What accumulates while you wait for the situation to resolve itself doesn’t show up on a dashboard. It doesn’t appear in a RAG status update. It sits in four places that no one is formally tracking — and it compounds quietly while the reports stay green. There is the executive you kept too long. The one who burned relationships with your vendors, your staff, your council — relationships you spent years building. You kept them because replacing them mid-program felt disruptive. The disruption you were trying to avoid has already happened. You simply haven’t named it yet. There is the legacy system you are still running — the one that “once worked.” Your team has built workarounds around the workarounds. Institutional knowledge now lives inside those patches, not inside any documented process. Every month you delay, extraction gets harder. The system doesn’t get easier to leave. It gets more embedded. There is the software decision you won’t revisit. You selected a platform. It may have been the wrong fit. But the sunk cost feels too large to confront — so you keep funding the implementation of something that was never going to give you what you needed. The investment grows. The doubt stays quiet. And there are the meetings that produce more meetings. Your steering committee discusses. Your vendor presents. Your team responds. Nothing changes at the structural level. The conversation has become a substitute for the decision. None of this is laziness. None of it is incompetence. Understanding why it happens doesn’t require a behavioural framework or a consultant’s model. It requires one honest observation about how people actually function under pressure. Drift is the natural human response to temporary comfort. Every hard decision — replacing a person, cutting a system, stopping a program, making a call you’ll have to defend — carries short-term pain that is immediate and visible. The cost of _not_ making that decision is deferred and invisible. So organisations choose the invisible cost, every time, until it isn’t invisible anymore. By then, the correction is three times harder. This is what that comfort is actually costing you. Staff who have lost faith in leadership’s ability to act — and are quietly updating their CVs. Vendors who have learned that your organisation does not hold lines — and price their contracts accordingly. Executives above you who are starting to wonder whether the program is the problem, or whether the sponsor is. And a system that will go live — if it goes live — carrying every unresolved compromise from the months you spent not deciding. You will not see most of this in a status report. Status reports are designed to show motion. What they cannot show is the cost of the absence of meaning. Which is why the question most executives are asking is the wrong one. The question is not: _what will it cost to fix this?_ The question is: _[what is it already costing me](https://spsingh.me/you-made-a-bad-one-way-decision-now-what/) to leave it as it is?_ Hard decisions are just hard. That doesn’t make them optional. The executive who understands drift doesn’t wait for the situation to become undeniable. They learn to read the quiet signals — the reports that are always green, the conversations that never resolve, the discomfort that everyone in the room feels but no one names. That discomfort is data. The cost of ignoring it compounds daily. Start with one question in your next steering committee — not as provocation, but as a genuine diagnostic: _“What decision have we been avoiding — and what is it costing us to keep avoiding it?”_ If no one can answer it, that is your answer. If your program needs an independent set of eyes — someone who will name what your team and vendor cannot — that is what the Executive Visibility Review exists for. [The cost of drift](https://spsingh.me/hard-to-fight-against-the-status-quo/) is real. It is already on your books. You just haven’t seen the invoice yet. --- --- title: "How To Define Change? Insanely, We Don’t!" url: "https://spsingh.me/how-to-define-change/" lang: "en-AU" type: "post" description: "Define Change? I bet you are wondering what does that even mean! Let us start with the basics! Tell me, why is change management such a complex area? Is it complicated, or do we make it so? Look, there are" last_modified: "2026-05-13T08:06:04+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" cos_headline_text: "How To Define Change? Insanely, We Don't!" cos_seo_score: 0 cos_headline_score: 0 wpar_republish_meta_query: "2026-05-11 21:16:52" --- # How To Define Change? Insanely, We Don’t! Define Change? I bet you are wondering what does that even mean! Let us start with the basics! Tell me, why is change management such a complex area? Is it complicated, or do we make it so? Look, there are many reasons for the complexity within change management. But, one of the main reasons is that we often ignore the basics. We do not follow a common-sense approach—instead, we slap projects with popular methodologies like [Prosci](https://www.prosci.com/change-management), [APMG](http://www.apmg-international.com/en/qualifications/change-management). Let us unfold what I mean by the common sense approach. Let me ask you… > If you are solving a problem, what would be your first step? I guess you will define the problem and understand it from various aspects. Common sense! But, when you are [managing change](https://spsingh.me/resist-change/), **how often did you define change**? You may be thinking, what do I mean by **define change**. Look, strategic business change has many facets/attributes. Some of which we can see and explain, others comes to us as a surprise. So, before delivering change, we must define a 3-D model and understand various change attributes. We can do this by defining the change. Let us consider an example: Consider your business decides to roll out software to optimise procurement. How can you define this change? To define, we need to view the change from various viewpoints: - Who is the instigator of the change? What are their expectations? - Who the change can affect (directly and indirectly)? - What are the threats to the proposed change? - What are the opportunities that change may bring for the business? - Who is the catalyst of the change? - Who will be the winners and losers after we implement change? So, who will receive benefit and who can experience loss? The change definition helps you to understand its impact at a much deeper level. Once you define the change, it becomes much simpler to manage it. It also helps you have a much broader context about the change.  ## How we can define change? There can be many ways for defining change. One of the simplest ways is to document all the attributes of the change.  Refer to the generic example below for you: ![define change](https://spsingh.me/wp-content/uploads/2021/08/image.png) Now let us define change with the help of an example:  Let’s assume that the State government has passed a plan to build a new bridge in the busy area within the city. You are responsible to develop a change management plan for project implementation. Using the table above and undertaking analysis, you define the change as: **Change definition:** A bridge will be built between ‘Rock’ and ‘Star’ streets. It will be 250 meters long and allow four lanes. Following are the attributes of change: ![define change](https://spsingh.me/wp-content/uploads/2021/08/image-2.png) Do you think it is worth spending time defining change? Here are few more reasons you should consider defining change: - Change definition helps to develop a shared understanding of change among all stakeholders - It allows you to create more robust and cohesive change strategies and plans - It helps to develop powerful communications for different groups (e.g. Winners, Losers) - Change definition is based on facts and analysis. So, it acts as a source of truth throughout project implementation In your next project, do justice with change management. Make sure that team takes time to define the change. It will make a massive difference in your success in managing the change.  If you need any help, do not hesitate to contact me. I wish you good luck with your project! --- --- title: "Why We Resist Change? Revealing #1 Hidden And Profound Reason!" url: "https://spsingh.me/resist-change/" lang: "en-AU" type: "post" description: "https://youtu.be/nGv1fNUgqmM Do you resist change? Do you know others who resist change? Suppose you rock up to the office and see a letter on your desk. The letter states that you are getting a dedicated luxury cabin in two months." last_modified: "2026-05-12T17:50:39+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" cos_headline_text: "Why We Resist Change? Revealing #1 Hidden And Profound Reason!" cos_seo_score: 0 cos_headline_score: 0 wpar_republish_meta_query: "2026-05-11 21:15:52" --- # Why We Resist Change? Revealing #1 Hidden And Profound Reason! https://youtu.be/nGv1fNUgqmM Do you resist change? Do you know others who resist change? Suppose you rock up to the office and see a letter on your desk. The letter states that you are getting a dedicated luxury cabin in two months. You will have a choice of working from an open space or cabin. How much will you resist this change? How many of us resist change in salary, promotions, employee benefits? The fact is that we accept such changes with delight! Then, which type of changes do we resist? We all resist perceived negative changes. So let us unfold this a little. The change can be one of the following three types: - **Positive**: We perceive the change will help us. It may improve our well-being, status, authority. - **Negative**: We perceive the change will negatively affect us. For example, we may lose something; it can be a perceived threat, discomfort, uncertainty. - **Neutral**: We do not care So, we establish that we resist only the perceived negative changes. Just hold on to this observation! ## **It is others who resist change****** We have this misconception that it is always others who resist negative change. But, as managers of change, we never step into people’s shoes that are on the receiving end. Consider a pretty common scenario of an [ERP software](https://spsingh.me/what-is-erp/) rollout. There are two main groups, Managers and Staff. In the Manager’s world, there are lengthy discussions on how to get staff to adopt change. There is an expected change in the company’s operating model. Staff will resist the change. It is a risk, and how we can manage it? But, the same Manager’s group often resist learning new software too. So, they also do not like the change that affects them. The fact is that, as humans, we have a general tendency to resist change. And it is not always a terrible thing either! Look, the main problem is that we often give lip service to change management. A common assumption is that if someone resists change, it is a job of a [Change Manager](https://www.prosci.com/resources/articles/change-management-job-description) to resolve. The fact is that we resist change for a reason. As managers of change, we must understand the underlying causes of change resistance. ## **Why we resist change**? The root cause! So, we now understand that we all have a natural tendency to resist negative change. But what is the root cause of this resistance? Why do we prefer the status quo instead of embracing the change? To understand this, look at the following diagram. It shows a generic viewpoint of employee and manager for an organisational change. ![resist change](https://spsingh.me/wp-content/uploads/2021/08/change-management-root-cause-1024x927.png) The left-hand side shows the employee’s viewpoint. You can see that employee is uncertain about few things (unknowns, job security). Further, the employee has concerns about new learnings due to the change. The right-hand side shows the manager’s viewpoint. Like the employees’ group, the managers have their concerns about the change. Their problems relate to Decision making, Extra workload. To conclude, the fact is that we all resist change. Our perception of given change can be different (positive, negative, neutral). It depends on our position in the whole schema of things—for example, our job role, culture, education and other dynamics. So, we established that we all resist change, but what is the root cause of this resistance. The root cause is our internal fear and anxiety. It is our instinct to be safe. If there is an expected change in our habitat, we experience fear and anxiety. As managers of change, we must understand this natural phenomenon. We must note the symptoms and the root cause of change resistance. So, in the next project, write down these symptoms. Notice why the business stakeholders say what they say. What are their underlying concerns, fear, and anxiety? Try to address the root cause, and people will support you in every step of your project! Good luck! --- --- title: "The Trap of Doing Everything Ourselves" url: "https://spsingh.me/the-trap-of-doing-everything-ourselves/" lang: "en-AU" type: "post" description: "The Trap of Doing Everything Ourselves Most organisations do not fail because they have no goals. They fail because they treat goals as if they automatically create capacity. An executive team may agree that something is important: improve reporting, fix" last_modified: "2026-05-11T13:08:54+00:00" categories: [Project Sponsorship] custom_fields: cos_headline_text: "The Trap of Doing Everything Ourselves" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Trap of Doing Everything Ourselves ## The Trap of Doing Everything Ourselves Most organisations do not fail because they have no goals. They fail because they treat goals as if they automatically create capacity. An executive team may agree that something is important: improve reporting, fix broken processes, implement a new system, lift customer service, reduce risk, or modernise operations. Everyone nods. The goal is accepted. But then the work quietly falls back onto the same people who are already running the business. That is where the trap begins. The organisation assumes that because the goal is important, people will somehow find the time, energy, skill, and focus to deliver it. But importance does not create capacity. Urgency does not create capability. And executive agreement does not automatically create execution. This is why many good initiatives move slowly. Not because staff are lazy. Not because leaders do not care. Not because the idea is weak. They move slowly because the organisation is trying to deliver new outcomes with old constraints. A finance team is asked to redesign finance processes while still closing month-end. An ICT team is asked to support transformation while still keeping systems running. Managers are asked to lead change while still managing staff, service issues, risk, and operational pressure. Executives are asked to govern delivery without having clear visibility of what is really blocking progress. Everyone is busy. But busy does not mean the organisation is moving forward. That is the hidden problem. Many organisations mistake effort for progress. They create meetings, registers, working groups, project updates, and action lists. These things may be useful, but they do not solve the core issue if the real gap is capability, structure, decision clarity, or execution capacity. This is where leaders need to step out of standard thinking. The standard thinking says: “We should be able to do this ourselves.” The better question is: “What is the safest and fastest way to achieve the outcome?” That question changes the conversation. It moves the focus away from pride, internal politics, and false self-sufficiency. It brings the focus back to the outcome. Sometimes the organisation does have the internal capacity to deliver. In that case, use it. But sometimes the organisation needs a partner, not because internal people are weak, but because they are already stretched. A good partner brings structure, challenge, pattern recognition, and momentum. They help the organisation see what it cannot see from inside its own pressure. For example, a council may want to improve procurement. Internally, people may already know the process is slow, manual, and inconsistent. But knowing the pain is not the same as solving it. Someone still needs to map the process, identify the root causes, separate system issues from policy issues, test options, engage stakeholders, prepare decisions, and create a practical implementation path. If that work is added to already busy staff, it drifts. If it is structured properly, it moves. The same applies to ERP, reporting, customer service, finance processes, asset management, HR systems, and business improvement. The issue is rarely only the system. It is usually the combination of people, process, decision rights, data, governance, and capability. Executives should therefore ask a sharper set of questions before launching another initiative: - Do we have the capacity to do this properly? - Do we have the capability required? - Are we asking already overloaded people to carry more work? - Are we clear on the decisions that need to be made? - Are we solving the root cause or managing symptoms? - Are we trapped inside our own assumptions? - Who can help us move faster without taking ownership away from us? - These questions matter because the cost of poor execution is not always visible at the start. It appears later as delay, fatigue, rework, poor adoption, weak reporting, unclear accountability, and benefits that never fully arrive. The way out is not to outsource responsibility. The way out is to design the right execution model. Internal teams must still own the business outcome. They understand the organisation, the people, the history, and the operational reality. But they do not need to carry every burden alone. The right partner can help convert intent into movement. The executive role is to create the conditions for success, not simply approve more work. That means being honest about the gap between ambition and capacity. It means recognising when the organisation needs extra structure. It means challenging the default belief that internal delivery is always safer, cheaper, or more responsible. Sometimes doing everything internally feels cheaper. But if the work stalls, the real cost is much higher. The stronger leadership move is not to ask, “Can we do this ourselves?” It is to ask: **“What combination of internal ownership and external support will give this goal the best chance of success?”** That is how organisations escape the trap. They stop treating partnership as a weakness. They start treating it as an accelerator. --- --- title: "What are you returning to?" url: "https://spsingh.me/what-are-you-returning-to/" lang: "en-AU" type: "post" description: "Why Your Mind Needs What Your Organisation Already Knows There's a question worth sitting with for a moment. Why does the army repeat the same drills every morning? Why does every religion return to the same texts, the same prayers," last_modified: "2026-05-10T13:50:36+00:00" categories: [Leadership] custom_fields: cos_headline_text: "What are you returning to?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # What are you returning to? # Why Your Mind Needs What Your Organisation Already Knows There’s a question worth sitting with for a moment. Why does the army repeat the same drills every morning? Why does every religion return to the same texts, the same prayers, the same rituals — year after year, generation after generation? Why do good leaders repeat the same values to the same team who already heard them last quarter? It seems inefficient. Redundant, even. It isn’t. ## The Problem Isn’t Forgetting. It’s Drift. Your team didn’t forget the mission statement. Soldiers didn’t forget how to march. Your employees have heard the safety briefing enough times to recite it back. But repetition was never about memory. It’s about alignment. And alignment is not a destination — it’s a condition that requires constant maintenance. Think about it this way. A ship’s captain doesn’t set a course and walk away from the wheel. Ocean currents, wind, and pressure are always working against the intended heading. Holding the line requires constant, small corrections — not because the crew forgot where they were going, but because drift is the natural state of things in motion. Our mind works the same way. Left unchecked, attention drifts toward comfort, toward noise, toward whatever is loud and immediate. Not because you’re weak. Because that’s what minds do. The question is whether you have a structure that brings you back. ## What the Institutions Already Understood The military, religious traditions, and serious organisations didn’t stumble into repetition accidentally. They discovered something through centuries of trial: that values, standards, and focus are not preserved through statements. They are preserved through practice. A Sikh warrior recites the same morning prayer not because the words are new, but because the recitation is the discipline. The act of returning — daily, deliberately — is what keeps the orientation intact. West Point doesn’t repeat its honour code to cadets because cadets are forgetful. It repeats it because the pressure of real situations will test that code constantly. Repetition is rehearsal for the moment it matters. A good CEO who keeps returning to the same three priorities in every all-hands isn’t being repetitive. They’re doing the structural work that keeps a 500-person organisation from fragmenting in 500 different directions. ## This Applies to You, Personally Most executives are extraordinarily disciplined about their organisations. They build reporting structures, governance frameworks, review cycles — all of it designed to prevent drift at the institutional level. But the same rigour rarely gets applied inward. The strategic clarity you had at the start of the year — the three things that actually matter — where is it now? Still on the slide deck. But is it still genuinely directing your attention each morning, or has it been quietly replaced by whatever is loudest in your inbox? Saying something once or twice doesn’t hold. Even to yourself. This isn’t a character flaw. It’s how attention works under pressure. The executives who stay anchored aren’t the ones who need less repetition. They’re the ones who’ve built structures that deliver it. ## Some Things Worth Considering – What are you returning to? Not prescriptions. Just patterns worth examining in your own context. **1. What are you returning to — and is it deliberate?** Most executives have some form of morning routine. The question is whether it’s oriented toward what actually matters, or toward what’s immediately demanding. There’s a difference between starting the day informed and starting the day reactive. **2. Do your team rituals reinforce direction, or just activity?** Weekly standups, monthly reporting cycles, quarterly reviews — these are already repetition structures. The question is what they’re repeating. Motion, or meaning? **3. Where have you said something important only once?** The strategy you announced. The standard you set. The expectation you communicated. If you said it once and moved on, the organisation almost certainly didn’t absorb it. Repetition isn’t nagging — it’s the cost of leading at scale. **4. What structure brings you back to what matters?** For some it’s journaling. For others, a weekly review. For others, a trusted advisor or peer who asks the uncomfortable question. The mechanism matters less than its consistency. Drift is not a crisis event. It’s the quiet, cumulative result of attention going unmanaged. The organisations and traditions that understood this built repetition into their architecture — not because they distrusted their people, but because they understood the nature of minds under pressure. The same principle applies to the person at the top of the organisation. What are you returning to? --- --- title: "How To Prioritise? 8 Steps To Stop Making Painful Mistakes!" url: "https://spsingh.me/how-to-prioritise/" lang: "en-AU" type: "post" description: "https://www.youtube.com/watch?v=Sn7zrKLxVcA Life does not give us everything we want. Resources are always limited, whereas demands are beyond the limit. How to prioritise is a must-have skill for everyone! I still remember my school days, having five bucks in hand and" last_modified: "2026-05-11T08:36:03+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-09 22:33:34" --- # How To Prioritise? 8 Steps To Stop Making Painful Mistakes! https://www.youtube.com/watch?v=Sn7zrKLxVcA Life does not give us everything we want. Resources are always limited, whereas demands are beyond the limit. How to prioritise is a must-have skill for everyone! I still remember my school days, having five bucks in hand and queuing up in front of the canteen window. While talking, laughing with friends, one question that I often think was: > **What is the best combination of goodies that I can buy today?** ![How to Prioritise](https://spsingh.me/wp-content/uploads/2021/07/austin-pacheco-FtL07GM9Q7Y-unsplash-1024x683.jpg) Well, things are not much different now; in my personal life, I still have the same question. What is the best combination of goodies that I can buy for my house and family? In my professional life, I focus on tasks that deliver the best value to my customers. In the end, it goes back to the art of prioritisation. I thought it is a good idea to design a framework that can help prioritise almost anything. Ready? ## 8 Step process to learn how to prioritise anything! Here you go: ### 1. **Know your vision/mission** Understanding of [big picture](https://writingexplained.org/idiom-dictionary/the-big-picture) is critical. Before prioritising, note down your vision/mission. For example, if you are prioritising among several [Enterprise projects](https://spsingh.me/what-is-erp/). You cannot execute all at once. First, note that what is your business vision/mission. It will help you to access which projects are aligned to the big picture. The projects that are in line with the big picture should be at the top of the list. ### 2. **Write down your goal** If you have a specific objective, then write it down. For example, your goal can be to improving the customer experience by 20%. Note that the goal must be aligned to the big picture. Let us continue with our example. Again, out of the projects list, select projects that improve the customer experience. ### 3. **Find constraints** We are always experiencing constraints of limited time, budget, regulatory conditions. Find the list of conditions under which you are prioritising. For example, the given budget for the projects in the fiscal year is $2M. So, the project’s execution must be complete and approved within this fiscal year. ### 4. **Group the options into a logical sequence** If you have an extensive list of options to prioritise then group similar options. It will help you to develop a more concise and manageable list. For example, groups the similar projects by adding tags such as – C_ustomer experience, Operations improvement, Human resources and Regulatory._ ### 5. **Find dependencies for each option** The list of options you are considering prioritising may be interdependent on each other or dependent on external factors. These factors can be_ – specialist resource, executive approval, audit, timebound events_ For example, the group of Regulatory projects may be dependent on internal audits. There can be interdependencies between Customer experience and Operations improvement projects due to resources, technical or other reasons. So, list all dependencies and interdependencies for the projects you are prioritising. ### 6. **Estimate on the prioritised list** Prepare an estimate for each option. Write down how much each option costs you. Note that in the above step, we already noted our resource dependencies. This step helps to understand the estimated expenditure on each option. For example, the Estimated budget for projects 1, 2 and 3 is $200K, $220K and $500K, respectively. ### 7. **Measure impact and benefits of each option** Measure the monitory, reputation, risk management benefits for each option. Find what are your returns on investment? This step is all about finding out what you will get in return for your investment (Returns On Investment – ROI) For example, the ROI on projects 1, 2 and 3 is $150K, 80K and $800K, respectively. But, note that the impact and benefits should not be limited to monetary value. It would help if you looked at a more holistic picture. So, evaluate how each option offer benefits from reputation, risk management, moral, vision and community development perspectives. ### 8. **Determine your approach** You have prerequisite information to make a call on priority. You can now make informed prioritisation decisions. Think outside the box, be creative, look for options and strategies to make the most impact with the known constraints. Then, make the decision considering the vision/mission and goals (point 1,2 above). **Here are few additional tips:** - **Determine ‘AND’ options rather than ‘OR’ – **Often, we decide one option over the other. It does not always need to be like that. Analyse if there are any ‘AND’ options available. For example, instead of choosing Project 1 over Project 2, check if we can run both projects in parallel. - **Focus on low hanging fruit:** These are the options that are easy wins. That should be higher on your priority list - **Iterate options to prepare a prioritised list – **Now you have a more complete information to prioritise the final list. Based on the points covered above, adjust the options, and prepare a final priority list that satisfies your goal, dependencies, constraints, and approach. Finally, like many other management challenges, there is no silver bullet to how to prioritise. Different techniques work in a separate set of situations. The key is to assess and refine your tool-set. Now, over to you! You have a decision to make! You can choose to make random decisions based on emotions of fear/passion, or, follow a framework that will assist you in making sensible priority decisions every single time. This framework has served me well. I would encourage you to use the framework for your upcoming prioritisation challenges. Feel free to reach out if you need assistance. Good luck! --- --- title: "Why Scrum Sucks? Insane Reasons Killing Your Project Right Now!" url: "https://spsingh.me/scrum/" lang: "en-AU" type: "post" description: "https://www.youtube.com/watch?v=txvBBkqm6I8 In the last decade, there has been phenomenal uptake of Scrum in the software industry. It has almost become a fashion statement for customer and vendor organisations. Oh! Do you do Agile?Yes! We use Agile, Scrum. We also have" last_modified: "2026-05-10T17:36:03+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-09 22:20:34" --- # Why Scrum Sucks? Insane Reasons Killing Your Project Right Now! https://www.youtube.com/watch?v=txvBBkqm6I8 In the last decade, there has been phenomenal uptake of [Scrum](https://www.mountaingoatsoftware.com/agile/scrum) in the software industry. It has almost become a fashion statement for customer and vendor organisations. > **Oh! Do you do Agile?** _Yes! We use Agile, Scrum. We also have a hybrid method – best of both worlds (Agile and Waterfall)_…. We often pretend that Scrum is a saviour for all our project management problems. Unfortunately, it is far from the truth! ![Scrum](https://spsingh.me/wp-content/uploads/2021/07/leon-Oalh2MojUuk-unsplash-1024x683.jpg) The fact is that Scrum has much value to add. But it has its place! ## Scrum is not a silver bullet Let us stop pretending that Scrum will fix all project problems! For example, the following are common project implementation problems. It does not matter if we are using Scrum or not. We must address these problems. Let us not assume that with Scrum, these problems will automatically resolve. Let us have a look at a few common project management problems: ### 1. **Lack of Big Picture understanding** Customer and software vendor organisations lack a [Big picture view](https://spsingh.me/how-to-implement-erp/) of the project: - What is the project objective? - How will the proposed solution help to meet its project objective? - Who are the stakeholders? How to engage them? - How to manage change? Ignoring these vital questions, we start by cutting code within the Scrum framework. We often fool ourselves by assuming that Scrum will take care of it all. ### 2. **No architecture** We often consider architecture work as waste. The common thinking is that the customer needs software, not an architecture diagram. So, let us start configuring and coding to get there asap. The thought process is that we are using Scrum, so we should be fine. ### 3. **No Project Plan** Project Managers were already lazy enough to produce a proper project schedule. With Scrum, there is not even an attempt to build one. The implementation teams are becoming more and more short-sighted. They are reactive to what is ahead in the next sprint. This mentality is crippling big picture thinking and extended team planning. The irony is that while there is a massive uptake of Scrum, very few understand Scrum. ## Scrum is not what you may think! Scrum is like a religion. Religion has values and certain rituals that support them. Without values, rituals are meaningless. Scrum sucks when we follow its rituals without living the values. For example, we do Daily Scrum, Sprint reviews without understanding its following values: - Focus - Courage - Openness - Commitment - Respect We do not even talk about the three Scrum pillars (Transparency, Inspections and Adaptation). Their implementation is too down our priority list. Ignoring Scrum values and merely following Scrum rituals is behaving like well-trained dogs. Look, each methodology has its philosophy and guiding principles (Core). Then, around the core, there are general rules and tools. Over time, the rules, and tools change, but the core stays the same. So, implement methodology by embracing its core. ## How to implement Scrum the right way? Note that clarity on the big picture and long-term planning is critical for a successful project. Scrum does not suggest ignoring these artefacts. If we are serious about Scrum, the executive team must stop giving lip service and act. People in management needs to come out of their comfort zones. Scrum needs profound change management. The team culture requires a change, so they must start living the Scrum values and principles. It is a long-term commitment and investment, but the results are incredible! Finally, let us not forget that Scrum is one of many ways to get stuff done. So, our focus should be on the project we are delivering, not how well we implement Scrum in the project. For instance, if the project does not solve the given business problem but we execute it with a perfect Scrum framework. It is still a failed project! I hope this post will trigger discussions and you will take steps to improve the situation in your organisation. If you need help, do not feel shy to get in contact! --- --- title: "Change Starts With Belief" url: "https://spsingh.me/change-starts-with-belief/" lang: "en-AU" type: "post" description: "Change Starts With Belief On the surface, we think people act because of pain and pleasure. We avoid pain. We seek comfort. We look for safety, recognition, certainty and control. In organisations, this is easy to see. People avoid difficult" last_modified: "2026-05-09T14:15:37+00:00" categories: [The Sovereign Architect Series, Change Management] custom_fields: cos_headline_text: "Change Starts With Belief" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Change Starts With Belief ## Change Starts With Belief On the surface, we think people act because of pain and pleasure. We avoid pain. We seek comfort. We look for safety, recognition, certainty and control. In organisations, this is easy to see. People avoid difficult conversations. They hold on to old spreadsheets. They resist new systems. They delay decisions. They protect familiar ways of working. So, as leaders, we often try to influence change through the same surface-level triggers. We explain the benefits. We set deadlines. We provide training. We create incentives. We repeat the business case. But sometimes, even after all this, people still do not change. That is because pain and pleasure are not always the deepest drivers of behaviour. Belief is. People will avoid pain for ordinary things. But they will accept pain for something they believe in. They will work longer hours for a mission they care about. They will learn difficult skills when they believe the outcome matters. They will let go of comfort when they believe the future is worth it. This is where many change programs fail. They assume resistance is an information problem. So they communicate more. But resistance is often a belief problem. When people resist change, they are usually protecting something. They may be protecting their confidence, their role, their workload, their team, or a process that has helped them survive for years. From the outside, this may look like negativity. From the inside, it feels like safety. That is why leaders must look deeper. The better question is not, “Why are people resisting?” The better question is, “What belief is making the current behaviour feel safer than the new behaviour?” This changes the nature of leadership. Leadership is not only about explaining change. It is about shaping belief. People need to believe the change has purpose. They need to believe leadership is serious. They need to believe they will be supported through the discomfort. They need to believe the new way is worth the effort. Without this belief, people may comply on the surface but continue old behaviours underneath. They attend the workshop but keep the spreadsheet. They agree in the meeting but avoid the new process. They use the system when watched but return to shortcuts under pressure. Real change does not happen when people simply hear the message. It happens when they start to believe something different. This is why leaders cannot lecture their way into lasting change. They must touch both the head and the heart. The head needs logic. The heart needs trust. The head needs clarity. The heart needs meaning. And most importantly, leaders must become evidence of the change. People listen to what leaders say, but they believe what leaders do. If leaders say the system matters but still ask for offline reports, people notice. If leaders talk about collaboration but reward silo behaviour, people notice. If leaders say transformation is important but avoid hard decisions, people notice. Every leadership action either strengthens belief or weakens it. The real work of change is not to force people to move. It is to understand why staying still feels safer. Once leaders understand that, they can remove barriers, address fears, rebuild trust and make the future more believable. Pain and pleasure may trigger action. But belief sustains it. So, before leaders ask people to change, they must first ask what people currently believe. Because lasting change does not begin with a project plan, a presentation, or a training session. It begins when people believe the new way is worth the pain of leaving the old one. --- --- title: "Accepting Reality" url: "https://spsingh.me/accepting-reality/" lang: "en-AU" type: "post" description: "The Quiet Work of Accepting Reality One mistake I often make is thinking that if I understand something, I should be able to fix it immediately. If I know I am distracted, I should stop being distracted. If I know" last_modified: "2026-05-08T13:48:00+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Accepting Reality" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Accepting Reality ## The Quiet Work of Accepting Reality One mistake I often make is thinking that if I understand something, I should be able to fix it immediately. If I know I am distracted, I should stop being distracted. If I know I am wasting energy, I should redirect it. If I know I am repeating an old pattern, I should simply move on. But reality does not work that cleanly. There is a gap between seeing the problem and changing the behaviour. That gap can be frustrating. It makes us question ourselves. Why am I still doing this? Why do I keep coming back to the same place? Why can I not just move on? This is where the real struggle begins. Not because the issue is unknown, but because it is known and still difficult. We often think growth means removing the problem. But sometimes growth begins by accepting that the problem exists. Not accepting it as permanent. Not using it as an excuse. Just seeing it clearly without adding another layer of frustration on top. When we resist reality, we waste energy fighting the fact that something is happening. When we accept reality, we get some of that energy back. We can then use it to observe, practise, adjust, and try again. This does not mean becoming passive. It means starting from the truth. I am distracted. I am frustrated. I am repeating a pattern. I am not where I want to be yet. Once this is accepted, the next step becomes simpler. Not easy, but simpler. Keep practising. Keep noticing. Keep correcting. Keep learning. Progress is often not a dramatic breakthrough. It is a quiet return to the same place with slightly more awareness than before. That awareness matters. Because over time, it changes the relationship with the problem. The issue may still appear, but it does not control the whole story. It becomes something to work with, not something to be defeated by force. Maybe that is the dynamic. We do not improve by hating where we are. We improve by seeing where we are clearly enough to take the next honest step. --- --- title: "Play vs. Competition" url: "https://spsingh.me/play-vs-competition/" lang: "en-AU" type: "post" description: "Play vs. Competition The confusion most of us carry — and the cost we don't see Most of us are more tired than the work justifies. The hours are long, yes. The decisions are hard, yes. But if we're honest, a" last_modified: "2026-05-07T13:56:43+00:00" categories: [The Sovereign Architect Series, Leadership] custom_fields: cos_headline_text: "Play vs. Competition" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Play vs. Competition **Play vs. Competition** _The confusion most of us carry — and the cost we don’t see_ Most of us are more tired than the work justifies. The hours are long, yes. The decisions are hard, yes. But if we’re honest, a lot of the exhaustion isn’t coming from the work itself. It’s coming from the performance around the work. **Two modes. One distinction.** Play stems from freedom. When you’re playing, you follow the rules, engage fully, win some and lose some. None of that threatens who you are. You practise, you improve, and over time you become a better version of yourself — not because you had to prove anything, but because the game itself pulled something better out of you. Competition stems from performance to win. When you’re competing, you place yourself — your role, your reputation, your team’s standing — at the centre. Then everything gets organised around protecting and advancing that centre. Every interaction becomes a stage. Every outcome becomes a verdict on your worth. From the outside, both look like effort. Both look like engagement. The experience of each is completely different. **Where the confusion actually lives.** In projects, it looks like this: two capable people on the same team — both technically aligned on the goal — but subtly working at cross-purposes. Not because they disagree on direction. Because each needs to be the one who was right. Decisions get defended long after the evidence has turned. Problems get minimised rather than surfaced. The program drifts while the status reports stay green — because pointing to the drift means someone has to accept they missed it. The project doesn’t fail because of the technology. It fails because somewhere along the way, being seen to be right became more important than actually getting it right. In sales, it looks like this: someone enters a conversation with a potential client already building the case for why they should be chosen. They’re performing competence before they’ve understood the need. The client feels it — they can’t always name it, but they feel it. The conversation becomes two people talking past each other. One is selling. The other is looking for a reason to trust. Neither gets what they came for. In families — and it’s worth naming this because we carry our habits home — it looks like adults who compete for the last word, who can’t let small things go, who need to be seen as right more than they need to actually resolve anything. The competition that started at work doesn’t stay at work. It’s a posture, not a setting. **What competition-mode actually does to us.** When we’re in competition-mode, feedback becomes dangerous. Every honest observation is a potential threat to the version of ourselves we’ve been building. So we rationalise it, dismiss it, or find a way to make it about the person who gave it. Slowly, we lose access to an accurate picture of what’s actually happening around us. When we’re in competition-mode, learning stalls. Learning requires sitting with not-knowing — and not-knowing feels too close to losing. So we perform instead of absorb. We accumulate credentials and talking points faster than we accumulate actual understanding. When we’re in competition-mode, the people around us adjust. They don’t always have words for it. But they sense that the real question in the room isn’t “how do we solve this together” — it’s “how does this person need to come out of this looking.” And they start performing back. The whole environment shifts. Everyone gets a little more careful, a little more political, a little less honest. None of this is intentional. That’s the thing. Most people in competition-mode don’t experience themselves as competing. They experience themselves as caring. As holding high standards. As not being willing to accept mediocrity. The distinction is invisible from the inside. **Play looks different in practice.** In play-mode, losing a round doesn’t cost you your identity — because your identity was never resting on the outcome. You can say “I got that wrong” without it requiring a recovery strategy. You can let someone else’s good idea be good without needing to have a version of it first. You can stay curious under pressure. That might be the most useful capability a leader can have — and it’s almost impossible in competition-mode. The player practises, absorbs, adjusts, comes back sharper. Over years, this compounds quietly. Not because they won every round, but because they actually used every round. **A few questions worth sitting with — not as a test, just as a mirror.** When someone on your team gets recognised publicly, what happens in you? When a peer gets the role you wanted, what’s your first internal move? In meetings, are you listening or waiting to speak? When you give someone feedback, is it calibrated to help them — or to maintain your position? When a decision you made starts looking wrong, can you hold it lightly enough to revisit it? There’s no right answer to perform here. These are just the places where the confusion tends to live — if it’s there at all. **The real cost.** We suffer in our careers not because we worked hard and it didn’t pay off — but because we competed where we should have been playing, and then couldn’t understand why the results felt hollow. We suffer in our organisations because leaders in competition-mode, entirely without meaning to, create environments where honesty is expensive and performance is cheap. Where the signals that something is drifting get filtered out before they reach the people who need to act on them. We suffer in our families because we’re still performing when we get home — and the people closest to us are the ones who pay the price for that. The confusion between play and competition is not a character flaw. It’s a pattern. And patterns, once you can see them clearly, are at least possible to work with. The goal isn’t to stop caring about outcomes. It’s to notice when the outcome has quietly become about you — rather than about what you’re actually trying to build. That’s a small distinction. But over years, it produces completely different lives. --- --- title: "How To Check Project Estimates? Revealing 10 Secret Points!" url: "https://spsingh.me/check-project-estimates/" lang: "en-AU" type: "post" description: "https://www.youtube.com/watch?v=5rNS0boNxek As a Project Sponsor, you are responsible for approving the Statement of Work (SOW). Before signing the SOW, you must thoroughly check project estimates. Checking the quality of effort estimate (cost) is one of the most critical tasks during" last_modified: "2026-05-08T06:06:03+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-06 22:19:30" --- # How To Check Project Estimates? Revealing 10 Secret Points! https://www.youtube.com/watch?v=5rNS0boNxek As a Project Sponsor, you are responsible for approving the [Statement of Work (SOW)](https://spsingh.me/review-statement-of-work/). Before signing the SOW, you must thoroughly check project estimates. Checking the quality of [effort estimate (cost)](https://www.wrike.com/project-management-guide/faq/what-is-effort-estimation/) is one of the most critical tasks during the approval process. Before signing SOW, you may have many questions about project estimates, like: - Does the vendor has provided realistic estimates? - Is the vendor overcharging? - Is the vendor low balling now, and I may receive bitter surprises during the project? ![Project Estimate](https://spsingh.me/wp-content/uploads/2021/07/cytonn-photography-GJao3ZTX9gU-unsplash-1024x684.jpg) In this post, I am sharing ten points you must check before approving the SOW. These points will guide you about the risks and common pitfalls. Use the following points as a checklist to manage risks due to the lousy estimates in SOW. Make sure to tick the following points before signing the SOW. Let us have a look now: ## 1. Check Project Estimates to ensure coverage Ensure that the vendor has covered the complete [project scope](https://creately.com/blog/project-management/project-scope-management/?msID=9ad98300-4e7b-442e-895b-96684a7691cf). Sometimes, vendors skip critical project tasks in the SOW to keep the project cost low. However, during the project implementation, they come up as a bitter surprise. So, work with your team to check that the estimates cover the entire project scope. ## 2. Does assistance tasks have enough budget allowance? This is another tactic to keep the project cost low during SOW approval. In every project, few tasks are the client’s (yours) responsibility. The vendor only assist you with these activities —for example, Data migration, User Acceptance Testing and End User training. To keep the project estimate low, vendors often include a minimal budget for these assistance activities. So, ensure that there is enough budget for the vendor’s assistance activities. ## 3. What are the assumptions? All estimates have underlying assumptions. As a sponsor, you want to check those vendor assumptions are valid and realistic. So, carefully review the assumptions under which the vendor has prepared the estimate. Then, check if the assumptions are reasonable. For example, consider the following assumptions: - Reports: The customer (you) is responsible for developing all the reports - Standard reports: The customer will use standard ERP reports With the above two assumptions, the vendor handballs the report development to your team. If there is no prior agreement on this, then you must raise all such assumptions with the vendor. So, firstly ensure that the vendor list all assumptions clearly in SOW. Secondly, take time to understand and get an agreement on the assumptions with the vendor. ## 4. What exactly is the vendor delivering? Get your team to review SOW to understand the project deliverables clearly. During project implementation, the vendor handles many deliverables and outcomes. For example, documentation, presentations, product showcase, support activities (Testing support, Training support). Ensure that SOW lists all the project deliverables, outcomes and associated estimates. ## 5. Role and responsibility of your team in the project The SOW should clearly state what does vendor expect your team to do? The SOW should illustrate the role and responsibility of the vendor and your team. Get your team to review their commitment to the project. They must agree and onboard to take on the required work as per the plan. Any ambiguity on the responsibility of your team can be an unexpected cost. So, take the time upfront to understand the role of your team in the project. ## 6. QA the Project estimates Do not assume that consulting rate, subtotal, totals are always correct in SOW. Check that the estimate within SOW has a correct consulting rate. Double-check the subtotals and totals in SOW. Ensure that the SOW includes any ongoing cost such as managed services. Any project expenses, such as travel; should be part of the estimates. ## 7. Check the experience of the vendor During presales, you must assess the vendor’s expertise within the context of your project. The quality of the estimate is as good as the people who are as estimating it. So, suppose the vendor has a lot of experience in the projects like yours. In that case, there is a high probability that the vendor will provide solid estimates. But, if your project is a new concept to the vendor, then estimates can be a hit or miss. ## 8. How complex is your project Uncertainly of the estimate is directly proportional to the project’s complexity. If your project is overly complex, then there are high chances of a low-quality estimate. So, always have a reasonable contingency to cover for unknowns during the implementation. ## 9. Specify budget contingency separately Ensure that SOW lists any budget contingency separately. It will help you to track when the project is using a contingency budget. You can also set tight budget controls and safeguard budget contingency. ## 10. Have you given right amount of information to the vendor? The quality of estimates depends on how much the vendor know about your project. If you have given a vague project brief, you should expect a rough ballpark estimate. But, if you provided detailed project background, objective, problem statements, then you should expect a quality estimate. In summary, before signing the SOW, ensure that the project estimates are realistic. Evaluate your risks and develop risk management strategies during the commercial and contract negotiations. Finally, take the time it takes to be on top of it before SOW approval. It is worth it! Use the above points as your checklist to validate estimates in SOW. Note that as an SOW approver, you are accountable for the project delivery. SOW is the baseline and agreement on deliverables, cost and plan between yourself and the vendor. So, make the required effort to ensure that the quality of estimates before signing the dotted lines. Good luck! --- --- title: "How To Search Enterprise Software Online? Save Time And Prevent Headache!" url: "https://spsingh.me/search-enterprise-software/" lang: "en-AU" type: "post" description: "https://www.youtube.com/watch?v=iKbCzb4_p1M Are you searching for enterprise software for your business or department? You may be wondering what to enter in Google to search enterprise software? Which words, phrases, keywords to search? Often you doubt if you are searching for the" last_modified: "2026-05-07T21:05:55+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" cos_headline_text: "How To Search Enterprise Software Online? Save Time And Prevent Headache!" cos_seo_score: 0 cos_headline_score: 0 wpar_republish_meta_query: "2026-05-06 22:05:30" --- # How To Search Enterprise Software Online? Save Time And Prevent Headache! Are you searching for enterprise software for your business or department? You may be wondering what to enter in [Google](https://www.google.com/) to search enterprise software? Which words, phrases, keywords to search? Often you doubt if you are searching for the right keywords? ![Searching Enterprise Software](https://spsingh.me/wp-content/uploads/2021/07/edho-pratama-yeB9jDmHm6M-unsplash-1024x683.jpg) In this post, I will address this issue. By the end of this post, you have clarity on the exact steps to follow and keywords to look for. Note that the steps outlined in the post are for a preliminary online search. So, at this stage, you know very little about the kind of software you may need. ## **Covering the base** Let us cover some bases here. The Enterprise software comes in different shapes and flavours. So, first, understand how the new software will fit within the existing systems landscape. For example, the new software will replace or integrate with the [existing ERP](https://spsingh.me/what-is-erp/). Let us unpack this! Consider your business is looking to enhance Customer Experience capability. The rest of the operational capabilities are fine. So, you need Customer Experience software that works with your existing ERP. Consider another example where you may be are looking to replace existing bespoke systems with one ERP system. So, you look for an ERP that offers capability within different lines of services. i.e Finance, Supply Chain, Sales. In summary, undertake some preliminary work to understand the scope of software and how it will fit in your current Systems landscape. So, develop a good understanding as: - What are your the high level needs from the software? - How will the software fit in your current systems landscape? Now that you have a clearer understanding of what are you need, let us now look for the magic keywords. ## **Search for Keywords** – Search Enterprise Software For searching anything on the web, you need to know keywords. Software is no different! Use the following list as your reference: ### 1. Software to improve Customer experience (CX) CX software covers a broad range of capabilities to improve customer experience. These packages include many different aspects of the customer lifecycle. - Customer Experience (CX) - Software Customer Relationship Management (CRM) Software - Customer Success Software The above keywords will help you to search for software with broad and deep customer experience capabilities. However, if you are searching for more specific aspects of customer experience the use the following keywords: - Sales Pipeline Management Software - Leads Management Software - Customer Complaints Management Software - Customer Contact Centre Software Field Service ### 2. **Software for all lines of service within your business – [Enterprise Resource Planning (ERP)](https://spsingh.me/what-is-erp/)** ERP is integrated software that manages all the departments within your business. While searching, you must be more specific. So, you [need ERP](https://spsingh.me/why-we-need-erp/) that specialise in your particular domain. For example: - Textile Manufacturing ERP - Retail ERP - HealthCare ERP - Professional Services ERP - Telecommunications ERP - Construction ERP When you search your industry-specific words, you always get better search results. How about if you searching for enterprise software that will integrate into your existing ERP? Let us have a look in the next section. ### 3. **Search for enterprise software that integrates with your existing ERP** You may have a need to search for software to fulfil specific needs for the business. Again, look for keywords that can give you the most relevant results. The following are few examples: ### 3.1 **Software to managing company assets – Asset Management** Asset management software can be very simple or complex. Some organisations have to make huge investments in fixed assets. For example, complex manufacturing, mining, construction. These organisations have complex needs to map, manage and maintain their assets. Other organisations have simpler needs. They only need a software tool to record assets, raise work orders and some simple reporting. So, assess your needs and use the following are few keywords, as you see relevant. - Asset Management software - Enterprise Asset Management software - IT Assets Management software - Facility Management software - Preventive Maintenance software As discuss before, be specific in what you are searching. ### 3.2 **Software to manage Human resource – HR Software** HR software comes in different flavours too. ERP software covers general HR functions. If you have special requirements, look for the software that meets your needs. Use the following keywords if you are searching for a specific HR function: - Payroll Software - Talent Management Software - Recruitment Software - Workforce Management Software For a broader range of HR capabilities search with the following keywords: - Human Capital Management (HCM) - Human Resource Management (HRM) ## **To conclude** This post is a humble attempt to share the importance of searching with the correct keywords. Look, the search engines return results based on keywords we enter. Vague keywords lead to misleading search results. So, take time to assess the software requirements. Then, develop some understanding of the scope of the software. For example, replace ERP or implement specialist software to integrate with ERP. Finally, search for keywords that represent your ideal software. I hope this post will help you with the primary keywords. If you need further help, do not hesitate to get in contact with me. Happy searching! --- --- title: "The Wrong Definition of Power" url: "https://spsingh.me/the-wrong-definition-of-power/" lang: "en-AU" type: "post" description: "The Wrong Definition of Power Is Costing You Most of us are chasing the wrong thing. We call it power. What we mean is: the ability to get what we want — from people, from systems, from circumstances. A better" last_modified: "2026-05-06T13:52:33+00:00" categories: [The Sovereign Architect Series, Leadership] custom_fields: cos_headline_text: "The Wrong Definition of Power" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Wrong Definition of Power ## The Wrong Definition of Power Is Costing You Most of us are chasing the wrong thing. We call it power. What we mean is: the ability to get what we want — from people, from systems, from circumstances. A better title. A bigger budget. A yes when we need one. That’s not power. That’s dependency with a confident face. Real power looks completely different. And once you see the difference, you can’t unsee it. **Real power is when you genuinely don’t need anything from anyone.** Not as a performance. Not as a negotiating posture. As a lived reality. When you need nothing, you can’t be controlled. When you can’t be controlled, you can finally act from principle instead of from pressure. That’s where freedom lives — and freedom has absolute power. Here’s how you get there. It’s not complicated. It is hard. **You need less than you think you do.** Most of what we’re chasing, we already have — or never needed. The moment you stop inflating your requirements, you stop being hostage to them. **Material things are immaterial.** This isn’t poverty thinking. It’s clarity thinking. When your sense of standing doesn’t depend on what you own, no one can threaten your standing by threatening what you own. **Zero reliance on others. Zero expectations of others.** This is the discipline most people avoid because it asks something uncomfortable: stop outsourcing your stability to people who have their own instability to manage. Other people are not infrastructure. Treat them as gifts when they show up. Don’t build your load-bearing walls out of them. **Give more than you get.** This sounds counterintuitive. It’s actually structural. When your orientation is contribution rather than extraction, you stop keeping score. And when you stop keeping score, you stop being diminished by the result. **Keep going. Keep learning. Keep expanding.** Not for an outcome — for the practice itself. The person who is genuinely curious and genuinely growing is never fully stuck. There is always a next move. **Stay alert and awake — to the world within you and the world around you.** Most people are asleep to one or both. They react to the outside without understanding what’s driving them. They reflect inward without ever reading the room. Awareness of both is what keeps you calibrated. What you get, on the other side of all of this, is not comfort. It’s something better. You are complete within yourself. You have alternatives. You can create options — because your thinking isn’t clouded by desperation, and your decisions aren’t hostage to whoever is currently withholding something you think you need. That’s the real definition of a powerful person. Not someone who always gets what they want. Someone who has quietly arranged their life so they don’t need to. _The freedom isn’t in the having. It’s in the not needing._ --- --- title: "The Question Your Vendor Will Never Ask You" url: "https://spsingh.me/the-question-your-vendor-will-never-ask-you/" lang: "en-AU" type: "post" description: "The Question Your Vendor Will Never Ask You Most technology programs begin with the wrong assumption. Here's how to find out if yours has. Before a single contract is signed, before a vendor is selected, before a project team is" last_modified: "2026-05-05T13:54:23+00:00" categories: [Project Sponsorship, The Sovereign Architect Series] custom_fields: cos_headline_text: "The Question Your Vendor Will Never Ask You" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Question Your Vendor Will Never Ask You ## ## The Question Your Vendor Will Never Ask You **Most technology programs begin with the wrong assumption. Here’s how to find out if yours has.** Before a single contract is signed, before a vendor is selected, before a project team is formed — there is one question that determines whether your program will deliver lasting value or just a functioning system. **Are you doing a Transformation, or are you doing an Implementation?** These are not the same thing. They are not even close to the same thing. But in boardrooms and steering committees across every sector, they are treated as interchangeable — and that confusion is where value goes to die. ### What Transformation Actually Is Transformation is not a project. It does not close.Transformation begins with a different question entirely: _What does this organisation need to become — and what will it take to get there and stay there?_It requires understanding your business goals, vision, and mission before touching a single system. It requires designing the architecture — business processes, information flows, organisational capabilities — to support those goals. It requires a roadmap that sequences change across time, not just a Gantt chart that sequences tasks.But here is what makes transformation structurally different from implementation — and what most programs get wrong: **Transformation does not end at go-live. It accelerates after it.** Going live is not the destination. It is the moment when the real work begins. After go-live, the organisation must: - Manage the change and embed new behaviours — not just train users, but change how people actually work - Reinforce new culture and ways of operating across the organisation - Develop continuous improvement, governance, and support infrastructure - Consolidate what was gained and iterate to build new capabilities None of that appears in a vendor’s statement of work. None of that is on the project closure checklist. None of that is measured by whether the software is functioning. Transformation asks: _Did we become what we needed to become — and are we sustaining it?_ ### Why Vendors and IT Teams Have a Simple View This is not a criticism. It is a structural observation. Vendors are paid to deliver software. Their commercial model is built around go-live. Their success metrics are uptime, configuration accuracy, and user adoption rates at handover. When the system works and the project closes, they have done their job. Everything that happens to your organisation after that is outside their contract and outside their interest. IT teams, similarly, are oriented toward technical delivery. They think in system terms — integrations, infrastructure, data, security. These are necessary. They are not sufficient. Neither the vendor nor the IT team is paid to ask: _What does this organisation need to change about how it operates, and who is responsible for holding that change over time?_ That question belongs to the executive sponsor. And in most programs, no one assigns it there — or if they do, no one defines what holding it actually looks like. ### The Dangerous Middle Ground Here is the pattern that appears in failing programs. The executive sponsor approves a transformation. The language in the business case is transformation language — capability uplift, process improvement, cultural change. The board signs off on transformation-level investment. But the program that gets designed and delivered is an implementation. The vendor scopes for software delivery. The project team manages tasks and milestones. The steering committee reviews RAG status reports. The go-live happens. The project closes. The vendor leaves. Twelve months later, the system is running — but the organisation operates almost exactly as it did before. The processes that were supposed to change haven’t changed. The governance that was supposed to improve hasn’t improved. The capabilities that were promised are theoretical, not operational. The reports stayed green. The value never arrived. This is not failure through incompetence. It is failure through misalignment — between what was approved and what was actually designed and governed. ### The Question to Ask in Your Next Steering Committee If you are a project sponsor, here is how to determine which program you are actually running — regardless of what the business case says. Ask your project manager: _What does success look like twelve months after go-live?_ If the answer describes system performance — uptime, user counts, reports functioning — you are running an implementation. If the answer describes organisational performance — how decisions are made, how the organisation operates differently, what capabilities now exist that didn’t before — you may be running a transformation. Then ask: _Who is responsible for the post-go-live work — the behaviour change, the governance, the continuous improvement — and what does their accountability look like?_ If there is no clear answer, or if the answer is “the vendor will support us,” you have your diagnosis. The vendor will not be there. That work is yours. The question is whether anyone designed it, resourced it, and built accountability around it — or whether everyone assumed it would happen on its own after the system went live. It won’t. ### What This Means for You as Sponsor You approved an investment on the premise of transformation. Your job is to make sure that’s what you’re actually getting — not a well-configured system with transformation language in the business case. That requires you to be able to answer three questions at any point in the program: - **Direction** — Is the program still aligned to the organisational goals that justified the investment? - **Oversight** — While the program is in flight, is the work happening as designed — or has it drifted into pure delivery mode? - **Stewardship** — After go-live, who is actively protecting the value — governing the change, embedding the behaviours, building the capabilities? If you cannot answer all three, you are not sponsoring a transformation. You are watching an implementation happen in transformation’s name. That distinction will cost you — in value unrealised, in change unmade, and in a second program to do what the first one should have done. --- --- title: "ERP Selection – The Quick and Dirty Way!" url: "https://spsingh.me/erp-selection/" lang: "en-AU" type: "post" description: "https://youtu.be/Uwe7mGuOQy4 You can waste months and spend thousands on ERP selection for your business. The fact is that conventional vendor selection often does more harm than good. There is a better way to choose vendors much quicker and intelligently. Caution:" last_modified: "2026-05-06T09:36:04+00:00" categories: [Visioning and Selection] tags: [ERP, ERP selection, ERP Selection process, Selection Process] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-05-04 22:02:02" --- # ERP Selection – The Quick and Dirty Way! https://youtu.be/Uwe7mGuOQy4 You can waste months and spend thousands on [ERP](https://spsingh.me/what-is-erp/) selection for your business. The fact is that conventional vendor selection often does more harm than good. There is a better way to choose vendors much quicker and intelligently. **Caution:** **This article is not intended for the following audience:** ![erp selection ](https://spsingh.me/wp-content/uploads/2021/05/pexels-anete-lusina-5723269-1-1024x683.jpg) - Government and other organisations that have [red tape](https://dictionary.cambridge.org/dictionary/english/red-tape) structures in place - Rather than channelling your time and resources, your priority is to cover yourself - If you have a unique business that does not fit within traditional business types like manufacturing, retail, professional services ## **Ripping apart the standard Vendor selection process** ERP consultants run workshops to understand and document the business requirements. They write the requirements, create a selection criterion to evaluate the software. They mark each need with tags like – Must Have, Should Have, Nice to Have. Then, depending upon various dynamics, you may request ERP vendors for RFP, RFT submissions. Next, there is a multi-stage selection process, contract negotiation and vendor selection finalisation. The process takes between 3 to 6 months and costs you between $60-$120K. On the surface, it may look like a logical process. But, do we bother about this? ## **Getting back to basics and using common sense** For selecting a home builder, will you go to a consulting firm to assist with Builder selection? Instead, you may ask around your friends, look out for their reviews and liaise with the handful. ## **Unwrapping quick and dirty ERP selection approach** Consider you are an executive within a retail hardware business. MD of the company asked you to choose ERP for the business. Instead of outsourcing the work, you decided to get your hands dirty. This is what you did: - You prepared a list of companies that are similar to your’s (offering, size, complexity) - You dig out contacts from these companies and asked for assistance in sharing their ERP journey - You have engaged appropriate stakeholders from your company in this process - You took detailed notes about the star ERP products, vendors, and key lessons learnt - You validated your notes based on ERP Selection portals like TEC, ERP Focus - You also noted industry-specific IP (Customisations/Mods) that the vendors have developed With this information, you go to the market well informed – what to ask for? Who to go to? Potential risks to look for. You get the point. Now this approach, though simple, is very profound. All it needs is for you to be uncomfortable. If you are prepared to get out of your comfort zone, the rewards are enormous! Look, this approach is not for everyone. But suppose you have the flexibility and freedom to adopt it. In that case, you can cut a considerable amount of time and cost. It is a common-sense approach. You will need you to get up from your comfy chair and learn from the people who have done this before. Please do not hold back. Give it your best shot! You will not believe it; even your competitors will hold your hand and tell their ERP story. Good luck! --- --- title: "How To Reduce ERP Project Cost? Revealing One Of The Best Way!" url: "https://spsingh.me/reduce-erp-project-cost/" lang: "en-AU" type: "post" description: "This is the #1 question that every Project Sponsor is asking! How can we reduce ERP Project cost? A significant chunk of ERP cost is the consulting services. If you are serious to reduce ERP project cost, this is where" last_modified: "2026-05-05T18:02:08+00:00" categories: [Project Execution] custom_fields: ampforwp-amp-on-off: "default" cos_headline_score: 0 cos_seo_score: 0 cos_headline_text: "How To Reduce ERP Project Cost? Revealing One Of The Best Way!" wpar_republish_meta_query: "2026-05-04 21:51:02" --- # How To Reduce ERP Project Cost? Revealing One Of The Best Way! This is the #1 question that every Project Sponsor is asking! How can we reduce [ERP ](https://spsingh.me/?s=what+is+erp)Project cost? ![reduce the ERP project cost](https://spsingh.me/wp-content/uploads/2021/05/bruce-mars-xj8qrWvuOEs-unsplash-1024x683.jpg) A significant chunk of ERP cost is the consulting services. If you are serious to reduce ERP project cost, this is where we should be looking. Now the question is how we can reduce the ERP consulting services cost? Let me illustrate with the help of a simple analogy taking two examples: **You are building a house – The typical way** _After the initial consultation, you work with the builder on your requirements. You and the builder sign an agreement. The builder builds the house and handover the keys to you. Simple!_ **You are building a house – The modern ERP way** _After the initial consultation, you work with the builder on your requirements. You identify there are certain things that you should take responsibility for. So, you took ownership of tiling, carpets and landscaping. You get your family members and other small businesses to work on these. It helps you to save cost on building the house._ ## Nailing, How to Reduce ERP Project Cost? Look, the design of modern ERPs wants you to take control. They are very configurable, flexible and you can personalise them without technical input. The key thing is being active and taking ownership of the implementation project. The most successful projects are the ones where the Customer (you) take ownership. Often, the Customer takes complete responsibility of: - [Data Migration](https://www.netsuite.com/portal/resource/articles/erp/erp-data-migration.shtml#:~:text=ERP%20data%20migration%20is%20the,into%20a%20single%2C%20common%20structure.) - UAT - Business Analysis and ownership of requirements If customers have technical resources in their business, they can also take responsibility of: - Designing and developing Outputs (e.g. Invoices, Statements, Purchase Orders) - Integrations (integration of ERP with other systems) - Reports and Dashboards development - ERP Customisations to meet business needs Note that you as a Project Sponsor must lead ERP projects from the front. Develop a cohesive environment where the vendor and your team works together. Ensure that ERP integration partner promotes to use of the standard ERP system. There must be a good reason for customisations, even if your team is capable of doing them. The key is to learn the basics of ERP upfront. For example, learning about: - Key terms (Item Master, Work Order, Chart of Accounts structure) - Standard processes (Procure to Pay, Order to Cash) - General navigation - Standard tools (reports, personalisations, security set-up) - ERP knowledge transfer should be one of the first tasks when you start an ERP implementation. I know this is a different mindset. Our typical approach is asking a vendor to do everything within the project. Modern ERPs have evolved to provide power back to business. Business stakeholders should understand this and leverage the opportunity and take control. As a Project Sponsor, cultivate the mindset to deliver a successful ERP at a reasonable cost. --- --- title: "Are You Leading This Project, or Is It Leading You?" url: "https://spsingh.me/are-you-leading-this-project-or-is-it-leading-you/" lang: "en-AU" type: "post" description: "You Have a Choice — and Most Sponsors Don't Know It Let me be honest with you. Not corporate-honest, where everything is framed as an opportunity. Actually honest. You became an ERP project sponsor because someone decided you were senior" last_modified: "2026-05-04T13:50:04+00:00" categories: [Home, Project Sponsorship, The Sovereign Architect Series] custom_fields: cos_headline_text: "Are You Leading This Project, or Is It Leading You?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Are You Leading This Project, or Is It Leading You? You Have a Choice — and Most Sponsors Don’t Know It Let me be honest with you. Not corporate-honest, where everything is framed as an opportunity. Actually honest. You became an ERP project sponsor because someone decided you were senior enough, influential enough, credible enough. Maybe you volunteered. Maybe it landed in your lap. Either way, here you are — your name on the charter, your face in the steering committee, your reputation quietly attached to something that has a well-known track record of going sideways. And here’s what nobody says out loud: the pressure you’re feeling right now isn’t just about the project. It’s older than the project. It’s the same pressure that got you into this chair in the first place. We look outward — to norms, to reputation, to what people at our level are supposed to do — rather than inward, to what we actually know and believe. I sketched something in a notebook the other day. A mind map about freedom. At the centre was a simple question: do we actually have a choice, or do we just follow the path that’s been laid out for us? The more I sat with it, the more I realised it applies almost perfectly to where you’re sitting right now. There’s a version of ERP sponsorship that is essentially a performance. You attend the right meetings. You send the right signals upward. You approve the consultant’s slide deck. You frame every risk as being managed. You push toward go-live because the board wants momentum, the vendor wants to invoice, and the project manager has a Gantt chart that says it’s time. This version feels safe. It looks like leadership. And it almost always ends badly — not for the optics, but for the actual humans using the system, and for the organisation that needed real change and got a very expensive replication of its old problems. The corporate ladder. Reputation. Peer pressure. Looking good rather than actually being good. These aren’t abstract concepts — they’re the invisible hands steering sponsorship decisions every single day on ERP projects around the world. You probably know exactly what I’m talking about. You’ve seen it, or you’ve felt yourself moving toward it. Here’s what I think freedom looks like in this role. It starts with being honest about why you’re really sponsoring this project. Not the official answer. The real one. Is it because you believe this transformation will genuinely make life better for the people in your organisation? Or is it because it’s your turn, and this is what people at your level do? There’s no judgement in the question. But there’s everything in the answer, because the two paths lead to completely different decisions when things get hard — and they will get hard. Freedom in this role looks like asking the question nobody wants to ask: are we actually changing, or just automating the old way? Most ERP projects fail not because of the software, but because the organisation configured a new system around old processes and old politics. The sponsor is the only person with enough authority to stop that from happening. But only if they’re willing to be disruptive. It looks like delaying go-live when people aren’t ready, even when the vendor is pressuring you, even when the board is watching, even when every instinct says just get it live and deal with it later. That moment — that one decision — is where real sponsorship lives. It looks like knowing yourself well enough to understand your own blind spots. Which parts of this project are you protecting because they matter, and which parts are you protecting because they’re yours? I’m not going to pretend the free path is comfortable. It isn’t. It means having conversations that feel politically dangerous. It means holding the line when the whole room wants you to move. It means caring about the outcome more than about how you look in the process. But the sponsors who lead this way — the ones genuinely trying to create something rather than consume a project — they’re the ones who remember the work fondly. They’re the ones their teams talk about years later. Not because everything went perfectly, but because something real changed. The others — the ones who played it safe, who approved the go-live to protect their reputation, who let the consultants drive because it was easier — they tend to carry a quieter kind of regret. The system went live. The consultants left. And the people left behind quietly found workarounds for the next three years. You do have a choice. That’s the thing I wanted you to know. It doesn’t always feel like it, but you do. You can look inward — at what you actually believe, what you see in this organisation, what kind of leader you want to be — and let that drive your decisions. Or you can look outward — at the norms, the politics, the reputation, the optics — and let those drive instead. Both paths are available to you right now, in this project, probably this week. The free path is harder. It asks more of you. But it’s the one that leads somewhere worth going. I’d love to know which one you’re on and the question remains- Are you leading this project, or is it leading you? --- --- title: "YOU MADE A BAD ONE-WAY DECISION. NOW WHAT? " url: "https://spsingh.me/you-made-a-bad-one-way-decision-now-what/" lang: "en-AU" type: "post" description: "A direct letter to the C-Suite executive who greenlit an ERP implementation they now regret — and who feels too deep in to turn back. You approved it. You signed the business case, shook hands with the vendor, and stood" last_modified: "2026-05-03T14:05:33+00:00" categories: [The Sovereign Architect Series, Project Assurance] custom_fields: cos_headline_text: "YOU MADE A BAD ONE-WAY DECISION. NOW WHAT? " cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # YOU MADE A BAD ONE-WAY DECISION. NOW WHAT?  _A direct letter to the C-Suite executive who greenlit an ERP implementation they now regret — and who feels too deep in to turn back._ You approved it. You signed the business case, shook hands with the vendor, and stood in front of your board and declared it transformational. Eighteen months later, you are sitting across from a project that is over budget, under-delivered, and politically radioactive. Your team is exhausted. Your CFO is asking questions you do not have clean answers to. And quietly, in the back of your mind, a thought keeps surfacing: I made a mistake. This article is for you. Not to judge the decision. Not to relitigate it. But to help you understand what kind of decision you made — and more importantly, what to do now. “One wrong choice doesn’t end the story. It changes the direction. And direction, unlike a decision, can always be redirected.” In technology strategy, there are two kinds of decisions. Reversible ones — where you can course-correct cheaply. And one-way doors — where once you walk through, the cost of going back is enormous. ERP selection is almost always the latter. A bad one-way decision in ERP doesn’t just affect your technology stack. It begins reshaping everything downstream: your team’s habits, your operating model, your organisation’s behaviour, your data integrity, and ultimately, the culture of how your people interact with systems. The ripple doesn’t stop at go-live. It keeps moving. And here is what no one tells the Project Sponsor: you don’t just feel the business impact. You feel it personally. There is guilt — a quiet regretting of the original choice. There is pain — the tension of trying to preserve your professional credibility while the platform struggles to perform. And there is shame — for the meetings you can no longer walk into with confidence, for the benefits that were promised and not realised. That emotional weight is real. And it is also a distraction from the only question that matters now: what do you do from here? The single most dangerous thing a C-Suite executive does after a bad ERP decision is double down to protect the original call. You’ve seen it. The escalating commitment. The “we just need to push through.” The refusal to re-scope because re-scoping feels like admitting failure. It is not failure. It is adaptation. And adaptation is the only currency that matters now. Here is the truth your advisors may not be saying directly: the organisation already knows something is wrong. Your people know. Your middle managers know. The question is not whether this will be talked about — it already is. The question is whether you lead the narrative, or whether the narrative leads you. “Commit: no more bad one-way decisions. That doesn’t mean paralysis — it means clarity. From here, every major call gets pressure-tested before it becomes irreversible.” This is not about writing off what has been spent. It is about projecting the future you can actually construct — with the constraints you now have. That is a different, more honest, and ultimately more powerful exercise than the original business case. First, name the situation clearly — internally first. Stop using language that obscures reality. “Challenges” and “learnings” are fine for public communications, but in your leadership team, speak plainly. A shared honest diagnosis is the foundation for any recovery. Second, separate the sunk cost from the forward decision. What has been spent is gone. The only decision in front of you is: what is the best path forward from this position? Model three futures — continue as-is, re-scope aggressively, or strategic pivot — and evaluate each on forward cost and forward value only. Third, change your relationship with the vendor — now. If the implementation partner is the wrong fit, that conversation cannot wait for the next steering committee. Renegotiate scope, escalate to executive contacts, bring in an independent advisor, or consider a structured exit. Silence is not a strategy. Fourth, do a lot of work on yourself as a sponsor. This is the uncomfortable truth: ERP implementations fail most often at governance and sponsorship, not technology. Review your own involvement. Are you getting the right information? Are you making decisions fast enough? Are you shielding the team or creating pressure that distorts reporting upward? Fifth, project your potential future — and commit to it publicly. Once you have a credible forward path, own it with the same conviction you brought to the original decision. Not false optimism — honest vision. Here is what we now know. Here is what we are doing. Here is what we will achieve. That shift in posture changes everything. This is the part no one says out loud in a board presentation, but it is the part that matters most: you do not walk through an experience like this unchanged. The executives who handle failed ERP implementations with clarity, honesty, and decisive adaptation do not just survive professionally — they become markedly better leaders. The sacrifice is real. There will be difficult conversations. There will be write-downs and re-forecasts. There will be a lot of work on yourself and your organisation. But on the other side of that work is something most executives never develop: the judgment that only comes from having navigated a high-stakes failure and chosen truth over self-protection. That judgment is worth far more than the avoided embarrassment of any single decision. “Keep taking care of yourself and working hard to make your future goal your reality. The decision is behind you. The direction is still yours.” If you are a Project Sponsor sitting inside a technology implementation that is not working, the most important thing you can do today is resist the urge to protect the past — and start building the most credible future you can construct from where you actually stand. The organisation is watching how you lead from here. Make it worth watching. --- --- title: "How To Review Statement of Work? Never Miss These 6 Checkpoints!" url: "https://spsingh.me/review-statement-of-work/" lang: "en-AU" type: "post" description: "https://youtu.be/kRmgLfl8F20 As a customer Project Sponsor, you cannot afford to overlook Statement of Work (SOW). SOW is one of the most critical documents in ERP implementations. It includes detailed information about project scope, estimate, timeline, role and responsibility. It tells" last_modified: "2026-05-04T06:02:44+00:00" categories: [Home] custom_fields: ampforwp-amp-on-off: "default" cos_headline_score: 0 cos_seo_score: 0 cos_headline_text: "How To Review Statement of Work? Never Miss These 6 Checkpoints!" wpar_republish_meta_query: "2026-05-02 22:12:38" --- # How To Review Statement of Work? Never Miss These 6 Checkpoints! https://youtu.be/kRmgLfl8F20 As a customer Project Sponsor, you cannot afford to overlook Statement of Work (SOW). SOW is one of the most critical documents in [ERP implementations](https://spsingh.me/what-is-erp/). It includes detailed information about project scope, estimate, timeline, role and responsibility. It tells you what you will get from the vendor with the investment you will be making. The approved document sets a baseline for scope, budget and project timeline. Any changes to this baseline attract a separate Work Order. We call this a [Change request](https://www.inloox.com/project-management-glossary/change-request/) or Variation request. It means that you pay an extra sum to cover any Change requests within the Project. By signing the SOW, you make your commitment to the capital expenditure and internal resources for the Project. Before making this commitment, it is vital to understand SOW inside out along with your team. ![Statement of Work](https://spsingh.me/wp-content/uploads/2021/05/sebastian-herrmann-6jAq8MkbULo-unsplash-1024x683.jpg) If you are not careful, you are likely to experience bitter surprises during the Project. So, take the time, assesses the risks and manages them. While reviewing and approving SOW, your main aim should be: - Working with the vendor for a win-win partnership - Risk Assessment and Management - Clarity and alignment between vendor and your organisation The following points will guide you on which areas you should direct your focus: ## 1. Project Scope – The ins and outs in Statement of Work In an SOW, there are various elements of the project scope. The following are a few examples: - ERP modules planned for implementation - Integration among different systems - Sites intended for ERP rollout - Financial companies that are in scope - Functional and non-functional requirements - Data Migration - Reports, Dashboards, Outputs and Business Intelligence reporting You need responsible individuals within your organisation to review the scope. They should report if the scope is unclear or SOW has unnecessary scope. For example, if specific ERP modules are not in scope but listed under SOW. ## 2. Responsibility – Who is doing what? Ensure there is no confusion on who will be doing what when the Project starts. SOW should define the role and responsibilities of the project team. For example, SOW should list which tasks out of the following is the vendor responsibility: - Configuring the ERP system - Developing customisations with ERP, where required - Various types of testing (Unit, System Integration, Load and Stress Testing, Security) - Migrating data from existing system(s) to ERP - ERP integration(s) with the other systems - Standard operational reports (Executive, Sales, Finance, Manufacturing) - Designing and developing outputs (Invoice, Purchase Order, Credit Note, Statement) - End-User training - Change Management/Project Management For the items that are the responsibility of the vendor, identify what your team has to do? How much effort your team needs to commit? If there are many vendors, then clarity of the role and responsibility of each vendor is vital. There should be clear owners of each project activity and deliverables. ## 3. Estimate – The summary of project budget Get your team to check that consulting rate, [effort estimate](https://spsingh.me/check-project-estimates/), and calculations are accurate. For estimates, check vendor assumptions and assess if they are realistic or too vague. Consider the following example: **Item: **_Reports_ **Estimate: **_30 hours _ **Assumptions:**_ 5 simple reports_ The vendor assumption is that you need 5 reports that are simple to develop. So, check with your team how many reports you need. Work with the vendor to define the meaning of a simple report. You will see such examples throughout the SOW, so be careful. ## 4. Plan – The Project journey Get your team to assess the Project Schedule/Plan proposed by the vendor. Check if your team understands and agrees on their responsibility within the Project. Ensure that the vendor has allocated enough time for the tasks that your team will do. The plan should be realistic and considerate of busy times within your business. For example, month-end, audit. ## 5. Assumptions – Interrogate them all! Get your team to assess all assumptions thoroughly. Ensure that the statements are reasonable. Note that this is the area in SOW where most of the risks are transferred to you. So, check every assumption and try to reduce them as much as possible. ## 6. No pressure – Take your time! You may get pressure from the vendor to sign the Statement of Work by a particular day. For example, the discounts are valid by Month-end/Financial year-end. Though deadlines are essential, though in this instance, you should not rush. Take your time, do the right things to understand SOW, assess risk, and sign it confidently. To conclude, though you may be responsible for approving the SOW, you may not know all the finer details within the SOW. So, engage with the right resources in your team and check the different SOW aspects. Remember that your objective is to work with the vendor for a win-win partnership. You want to ensure that both your team and vendors teams fully understand SOW. This way, you mitigate risks and set a foundation for successful ERP implementation. Take the time and effort to do justice with the document at the start. You will be glad you have done this right upfront! --- --- title: "How To Implement ERP? 4 Insanely Simple Steps!" url: "https://spsingh.me/how-to-implement-erp/" lang: "en-AU" type: "post" description: "Implementing ERP for your business can be a challenging initiative. You often wonder where to start, whom to talk to? Questions such as how to implement ERP, implementation time, investment, forming a project team may often overwhelm you. As a" last_modified: "2026-05-03T21:36:03+00:00" categories: [Project Execution] tags: [ERP, ERP implementation, ERP implementation planning, ERP implementation steps, ERP plan, How to implement ERP, how to plan ERP implementation] custom_fields: ampforwp-amp-on-off: "default" cos_headline_score: 0 cos_seo_score: 0 cos_headline_text: "How To Implement ERP? 4 Insanely Simple Steps!" wpar_republish_meta_query: "2026-05-02 22:02:38" --- # How To Implement ERP? 4 Insanely Simple Steps! Implementing [ERP](https://spsingh.me/what-is-erp/) for your business can be a challenging initiative. You often wonder where to start, whom to talk to? Questions such as how to implement ERP, implementation time, investment, forming a project team may often overwhelm you. ![how to implement erp](https://spsingh.me/wp-content/uploads/2021/04/daniel-mingook-kim-Pd-bOA-MZQs-unsplash-681x1024.jpg) As a sponsor of the project, you have more questions than answers. If you are not careful, you may make rash decisions or give up. This post covers how to implement ERP within your organisation. The target audience for this post is the Business Executives and Project Sponsors. The post reveals step by step process as to how to implement ERP. Let us get started! ## STEP 1: The GOAL – Zoom out Before considering ERP implementation, you must know [why you need ERP? ](https://spsingh.me/why-we-need-erp/)How it fits within your overall business vision and goals? How ERP will fit within your business and technology landscape? ### 1. Look at the Big picture – _before thinking How to implement ERP_ The first step is to look at the Big picture for your entire enterprise. Understand business vision, goals, drivers, problems, risks, challenges, threats, and constraints. View the whole enterprise as one functioning unit. Get your team to document Big picture and share them with the executive group. This work will answer the following vital question: What do you need to meet your business vision and goals? For instance: We need a one centralised business system to manage all our operations. The business system should automate Finance, Procurement, Supply Chain and Sales processes. ### 2. Develop a Roadmap ERP projects can take from 6 to 18 months. Do not try to do everything at once. Instead, work with your executive team to develop a [roadmap](https://www.productplan.com/learn/roadmap-basics/) from a business perspective. The roadmap may have many initiatives. The group of these initiatives helps you manifest your vision to reality. Note that you should not consider the roadmap as a final plan. As you learn more in the later steps, you should update the roadmap. The roadmap helps you understand the sequence of planned projects. For example: - Project 1: Implement Finance operations with ERP - Project 2: Implement Procurement, Supply Chain and Sales _You have now good understanding of the Big picture and Roadmap. It is time to understand your needs for ERP implementation.___ ## STEP 2: What do you need? Getting the crew ready With the solid business context in mind, action all the prerequisites to start the ERP implementation. ### 1. Identify enterprise-wide business requirements Form a team to work with each department and document their business requirements. Here, you want to identify what you wish the new ERP to do for you. Note that we are not concerned with how ERP will do it. Our focus is on a list of processes that ERP will execute for each department. For example: - Ability to manage pre-sales processes (quote, proposal) - Ability to manage jobs (manage labour time, consumables) This information will help you assess the ERP products that meet your requirements. ### 2. Find an ERP product that meets your needs Assess ERP products considering the Big picture, roadmap, and business requirements. This is an overly critical step. If you choose a wrong product, project cost can increase, and can affect returns of investment. So, seek expert advice, plan for a structured product selection process. The outcome of the step is a selected ERP product that you will implement within your business. ### 3. Find the trusted partners For ERP implementation, you need a range of specialist skillsets. So, consider vendors that offer services in: - ERP implementation partner (Integrator) - Independent consultants/contractors to fill specialist skillset like Project Management/Change Management - Technical resources to manage IT infrastructure - Recruitment agencies to provide resources to backfill internal roles in the short term ### 4. Plan to form a solid internal Project team ERP Project team includes internal and external resources. The internal resources are your employees who will form part of the Project team. For example, Subject Matter Experts (SMEs), Infrastructure support, Technical teams. The success of your project largely depends on your team. So, choose the best individuals possible. You need the best resources that understand your business. They must have a clear understanding of the company’s current processes and future vision. The SMEs have a critical role in the project. SMEs must be open and flexible to new innovative solutions. The project needs them from start to finish. So, choose the committed team players that are decisive and open to novel solutions. _You have now a clear understanding of the project objectives. You have selected software, implementation partners and the internal Project team—the next stage of planning your ERP journey._ ## STEP3: Plan the journey In this stage, educate your team about the project’s objectives. You must communicate how the project helps to achieve an overall business goal. Depending upon the size of the initiative and other factors, you plan a roadmap. Finally, get the right people to sit in the correct positions to drive the ERP implementation. Let us look in detail! ### 1. Document and communicate your vision Communicate the project objective to the team. The team should know the purpose of the initiative, its importance in assisting business to meet its overall vision. It helps to develop alignment within the team. The decision-makers can make the right decisions that support your company’s vision. Similarly, it helps the Project/Product Managers can prioritise work effectively. ### 2. Document and communicate your first project Do not bite more than you can chew! If the ERP initiative is significant, then consider breaking it into multiple projects. For example, you may want to implement few ERP modules within the first project. In the second project, you may wish to ERP integration with other systems. Communicate the objective and scope of your first project. Define the scope of the subsequent project(s) at a high level. Focus on having crystal-clear clarity on the immediate project your team is about to embark on. ### 3. Get the right people on the bus and get them in the right positions Ok, you now have a clear understanding of the end goal. You know what the outcome of the project will look like. For example, you will execute core Finance and Supply chain operations on the new ERP. Now, identify the core team who will form the part of the Project team. For instance, you need Finance and Supply Chain Managers to own business requirements and data migration. Similarly, you may need IT Administrator to help in data extraction from the existing system. So, work with your executive team members and vendors to design the Project team capable of delivering the quality outcome for you. _Congratulations the prerequisites to kick start ERP implementation are now complete. You are about to start the implementation._ ## STEP4: Start the journey During this stage, you prepare for a solid Project launch and put robust project governance procedures in place. ### 1. Project kickstart This is the exciting part. You sit with the entire project team and formally launch the project. During the launch, you must communicate: - The Objective of the project - What is expected from each Project Team member? - The known risk, constraints, issues - The high-level project plans - Detailed breakdown of immediate next steps on the project Project Launch is a joint responsibility of the entire executive team. So, work with Project Managers, Business Executives, Architectures, and other senior members to prepare for a solid launch. ### 2. Monitor and control the moving parts Throughout the project execution, you must oversee the project. Please focus on the end goal and redirect your team to it. There will be uncertainties, new information, risks, issues, and surprises. It is part of every project. Ensure the alignment and focus of your Project team towards the end goal. Your leadership and attention to detail to oversee the project is one of the leading factors of the project success. To conclude, ERP implementations are complex. It is too easy to be distracted by what is possible—for instance, the fancy dashboard, automated workflows, mobile apps. Keep your focus on what do your business needs in the short, medium, and long term. Break the big piece of work into smaller manageable projects. Get the right people and empower them to do the necessary work and make decisions. Rigorously oversee the project execution. Sound project governance is a key to project success. So, make sure you are on the ball! Before you jump onto something else, take some time and reflect on your past experiences of ERP implementation. What do you do differently this time? If you are sponsoring ERP project for the first time, prepare a checklist of things to do. Seek guidance from the people who have been on this journey before. Do not reinvent, reuse instead. I wish you all the best in your journey! --- --- title: "Doing ERP In-House" url: "https://spsingh.me/doing-erp-in-house/" lang: "en-AU" type: "post" description: "The Hidden Cost of “Doing ERP In-House”: When Saving Fees Increases Total Spend 1. The Decision That Feels Prudent It is common to see organisations choose to run ERP programs largely in-house. The logic is straightforward: “We understand our business" last_modified: "2026-05-02T13:52:41+00:00" categories: [The Sovereign Architect Series, Project Assurance] custom_fields: cos_headline_text: "Doing ERP In-House" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Doing ERP In-House ## **The Hidden Cost of “Doing ERP In-House”: When Saving Fees Increases Total Spend** ### **1. The Decision That Feels Prudent** It is common to see organisations choose to run ERP programs largely in-house. The logic is straightforward: - “We understand our business best” - “We have capable people internally” - “Why pay external fees when we can do it ourselves?” On paper, this appears disciplined. Cost-conscious. Even empowering. But in practice, this is where many ERP programs begin to accumulate invisible risk. Because what is saved externally is often paid internally — at a much higher cost. And by the time this becomes visible, the program is already under strain. Which leads to a more important question. ### **2. What We Believe — “Internal Capability Is Enough”** There is a strong belief at the executive level: - Internal teams know the processes - Business SMEs can drive requirements and decisions - Project management can be absorbed into existing roles - Governance can be handled through existing forums It feels efficient. Why introduce external layers when the organisation already has people? But this assumption ignores a critical distinction: **Knowing the business is not the same as delivering a transformation.** And ERP is not a routine activity. It is a once-in-a-decade capability shift. Which requires a different level of structure, experience, and discipline. ### **3. What Actually Happens — Capacity Becomes the First Constraint** Once the program begins, the pressure shifts to internal teams. What initially looked manageable starts to stretch: - SMEs balancing “day job” and project responsibilities - Key staff pulled into workshops, decisions, testing, and issue resolution - Project leadership diluted across multiple priorities - Governance forums reacting instead of directing Over time: - Decisions slow down - Quality of inputs declines - Fatigue increases - Critical thinking reduces And the program begins to drift — not because people are incapable, but because they are overextended. At this point, the cost has already started to move. ### **4. Why It Happens — Capability vs Capacity Gap** The failure is rarely about competence. It is about two gaps that are often underestimated: **1. Capacity Gap** - Internal teams do not have the bandwidth - ERP work competes with operational priorities - Focus becomes fragmented **2. Capability Gap** - ERP requires specialised experience in: Process design - System architecture - Change management - Governance discipline These are not everyday skills within most organisations. So what happens? The organisation compensates: - By learning on the job - By revisiting decisions - By correcting avoidable mistakes Which introduces delay, rework, and inconsistency. And this is where the real cost begins to surface. ### **5. The Consequence — You Pay Through the Organisation** The financial saving on external fees is quickly offset by internal impact: - Extended timelines due to slower decisions - Increased dependency on a few key individuals - Burnout and disengagement within teams - Operational performance decline during implementation - Reduced quality of outcomes More importantly: The organisation absorbs risk that it is not designed to carry. Because ERP is not just about implementation. It is about: - Making the right decisions at the right time - Maintaining clarity across complexity - Driving disciplined change across the business Without this, the program may still go live — but with compromised outcomes. And that is the most expensive form of success. ### **6. This Is Not a Cost-Saving Strategy** Running ERP in-house is often positioned as a cost-saving decision. In reality, it is a **cost-shifting decision**. From: External spend To: Internal time, effort, risk, and disruption The question is not: - “Can we do this internally?” The real questions are: - “Should we carry this level of risk internally?” - “Do we have the capacity to sustain this without impacting operations?” - “Do we have the experience to avoid predictable mistakes?” This is where executive clarity becomes critical. ### **7. The Direction — A More Disciplined Approach** A more effective model is not “fully external” or “fully internal”. It is **structured augmentation**. Where: **Internal teams focus on:** - Business knowledge - Decision ownership - Adoption and embedding change **External capability focuses on:** - Structuring the program - Driving governance discipline - Bringing pattern recognition from prior implementations - Challenging assumptions early This creates: - Faster decisions - Higher quality outcomes - Lower overall risk - Reduced total cost over time Because the objective is not to minimise external spend. It is to optimise total investment. ### **Final Thought — The Illusion of Control** Running ERP entirely in-house often creates a sense of control. But control without structure leads to drift. And drift is where cost accumulates. The organisations that succeed are not the ones that do everything themselves. They are the ones that: - Know where to rely on internal strength - Know where to bring external discipline - And design the program accordingly ### **The Real Question to Take Forward** Before deciding to run ERP in-house, ask: **“Are we truly saving cost… or are we transferring it into parts of the organisation where it is harder to see, measure, and control?”** Because that answer will determine whether your ERP becomes: A controlled transformation — or an internally funded overrun. --- --- title: "ERP Project Looks Fine- That’s the Risk." url: "https://spsingh.me/erp-project-looks-fine/" lang: "en-AU" type: "post" description: "Your ERP Project Looks Fine. That’s the Risk. 1. The uncomfortable truth most executives don’t see Across local government and enterprise programs, ERP projects rarely fail suddenly. They drift into failure quietly. Status reports stay green.Steering Committees stay calm.Vendors stay confident." last_modified: "2026-05-01T13:14:00+00:00" categories: [The Sovereign Architect Series, Project Assurance] custom_fields: cos_headline_text: "ERP Project Looks Fine- That’s the Risk." cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Project Looks Fine- That’s the Risk. ## **Your ERP Project Looks Fine. That’s the Risk.** ### **1. The uncomfortable truth most executives don’t see** Across local government and enterprise programs, ERP projects rarely fail suddenly. They drift into failure quietly. Status reports stay green. Steering Committees stay calm. Vendors stay confident. And yet, six to twelve months later, executives find themselves asking: - _Why are we over budget?_ - _Why aren’t we seeing value?_ - _Why is the business frustrated?_ The issue is not that the failure was invisible. It is that the signals were misinterpreted—or ignored. ### **2. What most executives believe is happening** At a surface level, the program appears controlled: - The Project Manager provides regular updates - Risks are “being managed” - Testing is “progressing” - Vendors are “working through issues” - Teams are “busy” This creates a reasonable assumption: > “The project is under control. There are challenges, but nothing unusual.” This assumption is where risk begins. ### **3. What is actually happening beneath the surface** When ERP programs begin to deviate, the signals are subtle but consistent. Executives often experience them without recognising their significance. #### **Signal 1 — Everything is green, but nothing feels right** You are receiving steady “green” reports. Yet in meetings, you notice: - Answers are vague - Risks are softened - Progress is described, not demonstrated **Example:** A monthly SteerCo update shows “on track,” but when asked what has actually been completed, the response shifts to activities rather than outcomes. **What this really means:** The reporting is protecting the narrative—not revealing the reality. #### **Signal 2 — Budget is being consumed faster than value is being created** Spend continues as planned. But when you ask: - “What capability do we now have that we didn’t before?” The answer is unclear. **Example:** Half the implementation budget is spent, yet finance, payroll, or asset workflows are still not operationally usable. **What this really means:** The program is progressing financially, not functionally. #### **Signal 3 — “We’ll fix it in testing” becomes the default response** Issues are acknowledged but deferred. You may hear: - “This will be addressed in UAT” - “We’ll stabilise post go-live” **Example:** Design gaps are knowingly carried forward with the expectation they will be resolved later. **What this really means:** Problems are being **shifted forward**, not solved. #### **Signal 4 — Change requests start appearing without clear justification** The vendor begins raising variations. Often framed as: - Additional configuration - Complexity discovered - “Clarifications” to original scope **Example:** You approved a fixed scope, yet costs increase without any visible expansion in outcomes. **What this really means:** Either: - The solution was underestimated - The organisation is losing control of scope - Or both #### **Signal 5 — Your business SMEs are disengaging** You begin to hear: - “We’re too busy to attend workshops” - “We don’t understand what’s being built” - “This system won’t work for us” **Example:** Key staff miss testing cycles or provide minimal input. **What this really means:** Ownership of the solution is weakening—and adoption risk is rising. #### **Signal 6 — Data becomes a late-stage problem** Data migration appears “on track.” But closer inspection reveals: - Cleansing not complete - Ownership unclear - Quality issues unresolved **Example:** The organisation assumes data will be ready because it “exists somewhere.” **What this really means:** Go-live risk is increasing significantly—but not yet visible in reporting. #### **Signal 7 — Complaints are acknowledged but not resolved** You hear concerns from the business. But the pattern is: - Acknowledged - Logged - Deferred **Example:** Teams raise usability or process concerns, but nothing materially changes. **What this really means:** The program is managing perception, not outcomes. #### **Signal 8 — Vendor attention starts to shift** Subtle changes occur: - Key vendor resources become unavailable - Response times slow - Continuity drops **Example:** Different consultants appear in meetings, with limited context. **What this really means:** Your project may no longer be a priority. #### **Signal 9 — The system is blamed on “change resistance”** When SMEs express concerns, the explanation becomes: - “They’re resisting change” **Example:** Instead of investigating whether the system design is fit-for-purpose, the issue is reframed as a people problem. **What this really means:** The organisation is avoiding confronting design flaws. ### **4. Why these patterns emerge** These are not isolated delivery issues. They are structural. They emerge when: - Executive expectations are not clearly defined - Ownership of outcomes is unclear - Governance focuses on reporting rather than control - Vendors operate without sufficient challenge - Problems are tolerated instead of resolved In simple terms: > The system is being implemented. The organisation is not being transformed. ### **5. The consequence if left unchecked** If these signals continue: - Costs increase without corresponding value - Timelines extend - Workarounds become permanent - Confidence erodes across the organisation Eventually, the project may still go live. But it will deliver: - Limited capability - Low adoption - Ongoing dependency on fixes This is how ERP programs become **“successful failures.”** ### **6. Reframing how to read your program** Instead of asking: - “Is the project on track?” Executives need to ask: - “What capability has improved this month?” - “What problems have been permanently resolved?” - “Where are we tolerating issues instead of fixing them?” - “Who owns the outcome—not the task?” This shifts governance from passive oversight to active control. ### **7. What to do next** **1. Demand evidence, not narratives** Require demonstrations of working outcomes—not activity updates. **2. Pull issues forward** Do not allow deferral into testing or post go-live phases. **3. Reassert scope control** Challenge every variation against original intent and business value. **4. Re-engage business ownership** Ensure SMEs are accountable—not optional participants. **5. Make data a business priority** Assign ownership and treat it as a core deliverable, not a technical task. **6. Test vendor commitment** Validate resource continuity and delivery focus. **7. Create space for real feedback** Encourage the organisation to surface issues without consequence. ### **Final Position** Most ERP failures are not caused by technology. They are caused by **early signals that were visible—but not acted upon**. Executives do not need more reporting. They need **clearer visibility, stronger challenge, and tighter control over outcomes**. Because by the time problems are obvious, the cost of correction is already high. --- --- title: "ERP Blind Spots – Why do we experience them?" url: "https://spsingh.me/erp-blind-spots/" lang: "en-AU" type: "post" description: "ERP Blind Spots: When Every Stakeholder Plays a Different Game 1. The underlying pattern ERP programs rarely fail because people are careless. They underperform because: Each stakeholder is doing their job well Each is optimising for their own success But no one" last_modified: "2026-04-30T13:05:49+00:00" categories: [Project Sponsorship, Project Assurance] custom_fields: cos_headline_text: "ERP Blind Spots - Why do we experience them?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Blind Spots – Why do we experience them? ## ERP Blind Spots: When Every Stakeholder Plays a Different Game ### 1. The underlying pattern ERP programs rarely fail because people are careless. They underperform because: - Each stakeholder is doing their job well - Each is optimising for their own success - But no one is optimising for the whole system outcome This is a multi-player game: > Different players, different goals, different information. The result is predictable: > Blind spots emerge—not from incompetence, but from **misaligned games**. ## 2. The Stakeholder Games and Their Blind Spots ### A. Project Manager — _The Delivery Game_ **Goal (Payoff):** Deliver on time, within scope, within budget **Focus:** Milestones, tasks, status reporting, risk logs **How they play:** - Track progress against plan - Manage dependencies - Escalate visible risks **Blind spots created:** - “On track” status despite weak business readiness - Hidden quality issues behind milestone completion - Over-reliance on plan vs actual usability **Outcome:** > The project looks successful on paper, while real-world readiness is low. ### B. Change Manager — _The Adoption Game_ **Goal (Payoff):** User adoption, training completion, engagement **Focus:** Communication, training sessions, stakeholder buy-in **How they play:** - Deliver training programs - Track attendance and feedback - Promote change messaging **Blind spots created:** - Adoption measured as attendance, not behaviour change - Training delivered on unstable or incomplete processes - Misalignment between system capability and user needs **Outcome:** > People are trained—but not equipped to operate effectively. ### C. Project Sponsor — _The Assurance Game_ **Goal (Payoff):** Confidence that investment is delivering value **Focus:** High-level status, risk summaries, executive reporting **How they play:** - Rely on reports from PM and vendor - Intervene when escalations occur - Maintain executive confidence **Blind spots created:** - Over-trust in summarised reporting - Limited visibility into operational realities - Late awareness of structural issues **Outcome:** > Issues become visible only when they are expensive to fix. ### D. Steering Committee (SteerCo) — _The Governance Theatre Game_ **Goal (Payoff):** Oversight, compliance, decision endorsement **Focus:** Status packs, approvals, high-level decisions **How they play:** - Review progress updates - Approve key decisions - Monitor risks at a distance **Blind spots created:** - Decisions made on incomplete or filtered information - Focus on reporting, not interrogation - False sense of control through structure **Outcome:** > Governance exists—but does not influence real outcomes. ### E. ERP Vendor — _The Delivery & Margin Game_ **Goal (Payoff):** Deliver contracted scope profitably **Focus:** Configuration, milestones, scope adherence **How they play:** - Implement based on agreed requirements - Protect scope boundaries - Deliver to contractual obligations **Blind spots created:** - Minimal challenge to poor business design - “Configured correctly” but not “fit for purpose” - Long-term usability sacrificed for short-term delivery **Outcome:** > System is delivered—but does not improve the business. ### F. Subject Matter Experts (SMEs) — _The Survival Game_ **Goal (Payoff):** Keep operations running while contributing to project **Focus:** Day-to-day work, workshops, testing inputs **How they play:** - Provide input during workshops - Participate in testing - Balance project and operational workload **Blind spots created:** - Limited engagement depth due to time constraints - Acceptance of suboptimal designs to move forward - Knowledge not fully translated into system logic **Outcome:** > System reflects partial reality—not how work truly happens. ## 3. What this creates at a system level Individually: - Each stakeholder is rational - Each is contributing - Each is meeting their objectives Collectively: - No one owns **end-to-end outcomes** - No one integrates **all perspectives** - No one is accountable for **business performance post go-live** This leads to: | System Effect | Result | | --- | --- | | Fragmented visibility | No single version of truth | | Local optimisation | Global inefficiency | | Delayed issue detection | Late, expensive fixes | | False confidence | “Successful” project, poor outcomes | ## 4. The real blind spot The biggest blind spot is not within any single role. It is this: > The assumption that if everyone does their job well, the system will work. Game theory tells us: > That assumption is false. Because: - Players optimise locally - Systems require global optimisation And without a mechanism to align them: > The system will always underperform. ## 5. The shift that changes outcomes The question should not be: - “Is the project on track?” - “Are users trained?” - “Is the vendor delivering?” The real question is: > “Who is responsible for integrating all of this into a working system?” Until that is answered: - Project success ≠ Business success - Delivery ≠ Capability - Implementation ≠ Transformation ## 6. To Conclude > ERP blind spots are not caused by failure of individuals. They are created when multiple stakeholders play different games—each successfully—without a system designed to align outcomes. The problem is not execution. The problem is the game itself. --- --- title: "Why We Need ERP? These 11 Reasons Will Reveal Hidden Value!" url: "https://spsingh.me/why-we-need-erp/" lang: "en-AU" type: "post" description: "Clarity on purpose is vital for any investment. Investing in ERP is a crucial decision for a business. So before investing in ERP we must understand why we need ERP? This post reveals 11 solid reasons why you need ERP." last_modified: "2026-05-01T06:06:03+00:00" categories: [Home] tags: [ERP Purpose, Why we need ERP] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-04-29 22:11:56" --- # Why We Need ERP? These 11 Reasons Will Reveal Hidden Value! Clarity on purpose is vital for any investment. Investing in ERP is a crucial decision for a business. So before investing in ERP we must understand why we need ERP? This post reveals 11 solid reasons why you need ERP. Before going any further, do you know [what is ERP](https://spsingh.me/what-is-erp/)? I have covered this topic [here](https://spsingh.me/what-is-erp/). To know more about ERP, you must read this [blog post](https://spsingh.me/what-is-erp/). Ok, you know what ERP is? Let us answer the vital question, why we need ERP? ## **11 reasons why we need ERP**? ![Why we need ERP](https://spsingh.me/wp-content/uploads/2021/03/blake-wisz-GFrBMipOd_E-unsplash-1024x683.jpg) ### 1. **Automation of all boring operations of your business** Believe it or not, your business has the similar operations as many other businesses. For example, you pay your employees, buy material, send quotes, follow-up prospects. ERPs has inbuild capability to automate these boring operations. ERP takes care of all your standard processes across Finance and Operations areas. ### 2. **Improves your Customer Experience** ERPs have specialist modules to take care of your customer experience aspect. For example, [CRM (Customer Relationship Management) or CE (Customer Experience)](https://crm.org/crmland/what-is-a-crm). These products/modules help you to automate leads management, marketing campaigns, customer communication, omnichannel experience, customer complaints, feedback and much more. ### 3. **Centralise enterprise data** With ERP, your operational data in a centralised in the one system. ERP takes care of your Master data (Customer, Vendors) and Transactional data (GL). It fulfils end-to-end data management requirements, e.g. data integrity, security, and normalisation. ### 4. **Reporting and Business Intelligence (BI)** ERPs offer pre-built reports and [dashboards](https://spsingh.me/what-is-the-purpose-of-erp-dashboards/). All ready to use with minimal personalisation. They also supply many tools and resources to develop your reports and dashboards. You can also use specialist Business Intelligence software and connect to your ERP. Modern ERPs offer open API and connectors to BI software. ### 5. **Standardise business processes** ERPs force your business to adopt standardised business processes. Consider you have employed two Sales Managers. Without a centralised system (ERP), it is difficult to get them to follow company processes. But, by using ERP, both Sales Managers have no choice. They will have to use same workflows, templates, and documents. For example, they both will develop quotes/proposals with a consistent template. The approval on quotes/proposals will be set. Thus, both Sales Managers will follow the same process. ### 6. **Measure and continuous improvement** ERP helps you to measure the effectiveness of your processes with ease. It helps you to see bottlenecks and limitations in the processes. With the right plan, you make necessary changes for continuous improvement. For example, the Customer Contact centre log reveals that most calls are due to a new product offering. So, to improve your customer experience, you start proactively informing and educating prospects and customers. ### 7. O**ne Ecosystem serving as a digital backbone** ERP helps you to develop one central ecosystem to manage operations. Modern ERPs offer easy to integrate tools. So, you have an ecosystem – ERP integrated with other business applications. There are many benefits, for instance, it becomes efficient to source data for reports and BI. For example, consider your ERP manages manufacturing, Sales, Supply Chain and Finance operations. The Customer and Employee self-service portal integrates with ERP. It offers one ecosystem for all your business operational systems. ### 8. **Easy Audits for all** Due to ERP’s inbuilt security and audit logs recording, you can easily report who has done what? For example, you can check who has removed a document, approved a Work order, etc. You can also supply reports and information to external auditors. ### 9. **Security is inbuilt** ERPs offer robust security mechanisms. You can control access at an individual field level. For example, if required, you can secure the _Data of Birth_ field to be not visible to certain users/user group. Modern ERP offers multi-factor authentication, password policies to ensure your data protection. ### 10. **ERP offer a real agility** ERP offers heaps of agility to your business. You may want to improve processes, add a new capability, develop a new product/service. ERP is there to support these initiatives. For example, you can change existing workflows in ERP to support changes in business processes. If you want to add a new capability, say digital campaigns, then add on a CRM module or integrate CRM to ERP. So, ERP is the core of your digital business capabilities. ### 11. **Gives you freedom, so you can focus on big stuff** ERP gives you freedom by offering one solution for all your day-to- day operational needs. For example, with ERP, you have a set automated processes for Procure to Pay, Order to cash. So, your basic operational stuff is under control. You can now focus on strategic initiatives, like Customer portal for self-service. ERP is the heart of the digital capability of your business. It takes care of end-to-end process automation for your business. ERP has a lot of value to offer – provided you choose the right ERP product and committed implementation team. Good luck with your ERP journey! --- --- title: "What is ERP? Insanely Simple Stuff You Must Know!" url: "https://spsingh.me/what-is-erp/" lang: "en-AU" type: "post" description: "ERP stands for Enterprise Resource Planning. The name suggests that the software help organisations for resource planning. It is misleading as ERP have grown much more profound and prominent over the years. ERPs do much more than resource planning. So," last_modified: "2026-04-30T19:06:03+00:00" categories: [Home] tags: [Enterprise Software, ERP, ERP definition, ERP Software, Need of ERP, Purpose of ERP, software, What is ERP, Why we need ERP] custom_fields: ampforwp-amp-on-off: "default" wpar_republish_meta_query: "2026-04-29 22:02:56" --- # What is ERP? Insanely Simple Stuff You Must Know! ERP stands for [Enterprise Resource Planning](https://spsingh.me/what-is-erp/). The name suggests that the software help organisations for resource planning. It is misleading as ERP have grown much more profound and prominent over the years. ERPs do much more than resource planning. ## **So, what is ERP?** > It is a business software that manages end-to-end operational functions within an organisation. Let us unwrap the purpose of ERP! Organisations have many departments, e.g. Sales, Procurements, HR. These departments perform specific predefined functions. For example, HR undertaking hiring, Procurement deals with suppliers and fulfils resource demands. There is an interrelation among these functions. But, we often look at them in department silos. You see, _Sales drives procurement, and procurement triggers Account payable functions. _It is one ecosystem broken into virtual boundaries of departments. ERP provides a unified platform to support the entire ecosystem within the organisation. The whole organisation use one system to enter data, process information, and receive outputs. The ERP acts as a central source for workflows, automation within every department. For example, the Sales department use ERP to send sales quotes, proposals to the prospect. After proposal acceptance, the Operation Manager books_ resources and material within ERP. The allocated resources complete the work and report time and material in ERP. The Operations Manager finalise the invoice and send to the customer. The finance department uses ERP to ensures the customer pays the invoice on time._ You can see that how these departments work seamlessly using one ERP platform. In summary, ERP meets the end-to-end functional needs of the entire organisation. Let us now look at the structure and packaging of ERP software! ## ERP Packaging > ERP is a collection of integrated modules that share a common data model. You can choose to use only one module or multiple modules together at once. For instance,_ an enterprise may want to use the Financial module only. Later may decide to use Sales Management and Supply Chain modules._ Each of these modules works seamlessly. Typically examples of the modules are: ![What is ERP?](https://spsingh.me/wp-content/uploads/2021/02/ERP-Modules.jpg)ERP Packaging – What is ERP? ERPs are designed with common industry practices in mind. So, ERP already has standard ways to process information. We call them [out of box functions](https://www.definitions.net/definition/out+of+the+box+feature). For example, ERP has a set way to convert a prospect to a customer. ERP handles complex calculations such as Material requirements, scheduling, routing with a click of a button. > So, consider ERP as building blocks of integrated modules. Each module has a prepackaged solution to meet your business needs. I hope this gives you a basic understanding of ERP. If your organisation turnover is over $10M, seriously think about implementing ERP. It is a vital resource for the sustainability and growth of your business. Do not stop here! Research ERPs that your competitors are using. Search for ERPs that are market leaders within your industry. Take the next step and discover what ERP has to offer, how much it will cost and how quickly you can recover the cost! Good luck with your ERP journey! Trust me; it is worth it! --- --- title: "Why Do We Experience Blind spots?" url: "https://spsingh.me/why-do-we-experience-blind-spots/" lang: "en-AU" type: "post" description: "So, why do we experience blind spots? 1. The assumption most people make We tend to believe blind spots happen because people miss things. We assume: If we had more information If people paid more attention If the team communicated" last_modified: "2026-05-02T13:54:28+00:00" categories: [The Sovereign Architect Series, Project Assurance] custom_fields: cos_headline_text: "Why Do We Experience Blind spots?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Why Do We Experience Blind spots? ## So, why do we experience blind spots? ### 1. The assumption most people make We tend to believe blind spots happen because people miss things. We assume: - If we had more information - If people paid more attention - If the team communicated better …then the problem would disappear. It sounds reasonable. But it is wrong. Because in most situations, **the information already exists**. People are not blind in isolation. They are operating within a system. Which raises a more useful question: > If people are informed and capable, why do obvious issues still go unnoticed? ### 2. What is actually happening beneath the surface To understand this, we need to shift perspective. Every situation—whether in organisations, families, or society—is a **multi-player game**. In this “game”: - Each person has their own goal - Each person sees part of reality - Each person makes decisions to succeed in their own context This is not dysfunction. This is normal behaviour. But here is the issue: > Everyone is playing rationally. Just not the same game. ### 3. The role of “different games” (Game Theory in simple terms) Think of a workplace scenario. A finance leader is focused on cost control. An operations manager is focused on speed. A technology lead is focused on stability. Each is making good decisions: - Finance pushes for budget discipline - Operations pushes for faster execution - Technology pushes for risk reduction Individually, all of this makes sense. But collectively: - Costs get reduced at the expense of capability - Speed increases without control - Stability slows down progress No one is wrong. Yet the outcome is suboptimal. > This is the core idea from game theory: When multiple players optimise their own outcomes, the system does not automatically optimise as a whole. And this is where blind spots begin to form. ### 4. Why blind spots are inevitable in this setup Once people are playing different games, three things naturally happen. #### A. Partial visibility Each person sees only what is relevant to their role. For example: - A project manager sees timelines - A user sees usability issues - A vendor sees delivery milestones No one sees the entire system. #### B. Information does not fully travel Even when information exists, it does not move freely. Why? - It may not seem relevant to others - It may create friction if raised - It may not align with someone’s priorities So information remains fragmented. #### C. Rational behaviour creates unintended gaps People act logically based on: - What they are measured on - What they are responsible for For instance: - A team may avoid raising a risk because it delays progress - A manager may approve something quickly to meet deadlines These are rational decisions. But collectively: > They create gaps that no one owns. ### 5. What a blind spot really is At this point, the definition becomes clearer. A blind spot is not a failure of intelligence or effort. It is: > A gap created when individually correct decisions fail to produce a complete picture of reality. The truth exists. But it is scattered across people, roles, and priorities. And no one is responsible for assembling it. ### 6. A simple everyday example Consider planning a family holiday. One person focuses on budget. Another on comfort. Another on timing. Another on experience. Each contributes something valuable. But without someone integrating all inputs: - The cheapest option may be exhausting - The most comfortable option may be too expensive - The fastest option may miss the purpose of the trip Everyone did their part. Yet the best outcome was missed. That missed outcome is the blind spot. ### 7. Why this matters more than it seems Blind spots do not just create small inefficiencies. They lead to: - Poor decisions that look correct at the time - Missed risks that appear obvious later - Frustration between people who believe they are doing the right thing Over time, this creates: - Rework - Misalignment - Loss of trust And the common reaction is to blame individuals. But the issue is not the people. > It is the structure of the game they are playing. ### 8. The critical shift in thinking Most attempts to fix blind spots focus on: - More meetings - More reports - More communication These help, but they do not solve the root problem. Because the real issue is: > There is no mechanism to bring different perspectives into a single, shared understanding. Without that: - People continue to optimise locally - The system continues to underperform globally ### 9. What actually reduces blind spots To reduce blind spots, the approach must change. Instead of asking: - “Who missed this?” We should ask: - “How is the system designed to bring all perspectives together?” This means: - Clarifying shared goals - Making information visible across roles - Creating decision processes that consider the full picture In simple terms: > Someone—or something—must be responsible for seeing the whole. ### 10. Final thought Blind spots are not accidental. They are a natural outcome of: - Different goals - Different information - Rational decisions All happening at the same time. > The problem is not that people cannot see. The problem is that no one is responsible for seeing everything together. Once that is understood, blind spots stop being surprising. They become predictable—and therefore, preventable. --- --- title: "What Good ERP Governance Actually Looks Like?" url: "https://spsingh.me/what-good-erp-governance-actually-looks-like/" lang: "en-AU" type: "post" description: "ERP Governance Looks Fine on Paper. So Why Does It Still Fail? Steering Committees are in place.Reports are being produced.Decisions are being recorded. From the outside, governance appears structured and controlled. Yet inside the program: Issues surface late Decisions feel" last_modified: "2026-04-28T13:55:20+00:00" categories: [Project Assurance] custom_fields: cos_headline_text: "What Good ERP Governance Actually Looks Like?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # What Good ERP Governance Actually Looks Like? ## **ERP Governance Looks Fine on Paper. So Why Does It Still Fail?** Steering Committees are in place. Reports are being produced. Decisions are being recorded. From the outside, governance appears structured and controlled. Yet inside the program: - Issues surface late - Decisions feel reactive - Value remains unclear This disconnect is not caused by missing governance. It is caused by something far more subtle: > **No one has clearly defined what “good governance” actually means at an executive level.** ## **The Assumption That Quietly Breaks Programs** Most organisations operate on a simple belief: > “If we have a Steering Committee, governance is working.” So the focus becomes: - Who attends - What gets reported - How often meetings occur But one question is rarely asked: > **What standard is this governance expected to operate to?** Without that standard, structure becomes a formality—not a control mechanism. ## **Where It Starts to Drift** When expectations are not clearly set from the top: - Each member defines governance in their own way - Questions become inconsistent - Accountability becomes unclear - Decisions default to what is easiest, not what is right Over time: - Governance becomes passive - Conversations become safe - Signals become diluted Nothing appears broken. But performance begins to erode. ## **The Missing Anchor: A Clear Executive Mandate** In high-performing ERP programs, governance does not evolve by chance. It is **defined upfront by the Project Sponsor or CEO**. They set: - What governance is meant to achieve - How decisions must be made - What behaviours are expected - What culture must exist in the room This is not implied. It is made explicit. Because once the expectation is clear: - Behaviour aligns - Standards become consistent - Decisions improve Without this anchor, governance becomes dependent on personalities. With it, governance becomes a **system**. ## **So What Good ERP Governance Actually Looks Like**? It is not about better reports. It is not about more meetings. > **It is about behaviour—driven by a clearly defined executive expectation.** Across high-performing programs, the same patterns consistently emerge. ## **They Don’t Look for Comfort. They Look for Truth.** Because the expectation is clear, members do not seek reassurance. They ask: - What are we missing? - Where could this fail? - What assumptions are we relying on? Challenge is not seen as disruption. It is seen as responsibility. ## **They Don’t Observe. They Own.** The mandate is clear: > Governance owns outcomes. So members: - Think beyond their function - Take responsibility for cross-functional impacts - Do not defer accountability back to the project team Ownership becomes visible. ## **They Remove Ambiguity Early** Clarity is not left to the project team. It is driven at the governance level: - What does success look like? - What matters most right now? - What trade-offs are we making? This reduces confusion before it becomes risk. ## **They Don’t Decide Blindly** There is an implicit understanding: > You cannot govern what you do not understand. So members: - Invest time in understanding the system and risks - Ask deeper questions - Build their own capability Decision quality improves as a result. ## **They Show Up to Decide, Not Just Attend** Attendance is not the standard. Contribution is. Members are expected to: - Engage actively - Come prepared - Make decisions This creates pace and direction. ## **They Think Like Owners of the Whole Organisation** The expectation is clear: > Decisions must serve the organisation, not individual functions. This changes behaviour: - Less protection of silos - More focus on end-to-end outcomes Local optimisation reduces. System-wide thinking improves. ## **They Make It Safe to Surface Reality** Culture is not left to chance. It is set. Members create an environment where: - Issues are raised early - Bad news is not suppressed - Conversations are honest This is where governance starts to work as intended. ## **They Care About Outcomes, Not Activity** Progress is not measured by: - Tasks completed - Milestones achieved It is measured by: - Business impact - Value realised - Capability improved The focus shifts from motion to results. ## **They Go Beyond the Surface** They do not accept updates at face value. They ask: - Why is this happening? - What is driving this risk? - What assumptions are we relying on? Understanding becomes the goal—not just answers. ## **They Listen, Challenge, and Then Decide** The room operates differently: - People listen with intent - Questions are deliberate - Decisions are made with clarity Discussion leads to outcomes—not more discussion. ## **What Changes When This Standard Exists** When the executive mandate is clear: - Behaviour becomes consistent - Decisions improve - Risks surface earlier - Alignment strengthens - Execution stabilises When it is not: - Governance depends on individuals - Standards drift - Performance becomes unpredictable ## **The Shift Most Organisations Need to Make** ERP governance is often treated as: - A structure - A cadence - A reporting mechanism It needs to be understood as: > **A system of behaviours—defined and enforced by executive expectation.** ## **Where to Start** - **Define the Mandate Clearly** What is governance expected to achieve? - What behaviours are required? - **Make It Explicit** Do not assume alignment - State expectations clearly - **Reset the Steering Committee** Move from attendance → accountability - Move from reporting → decision-making - **Reinforce the Standard** Observe behaviours - Challenge deviations - Maintain consistency ## **Final Thought** Most ERP programs do not struggle because governance is missing. They struggle because: > **The standard for governance has never been clearly defined.** Once that standard is set, everything else— questions, decisions, behaviour, outcomes— begins to change. --- --- title: "What Are The Roles In ERP Project Team? 14 Unique Roles For Solid Delivery!" url: "https://spsingh.me/erp-project-team/" lang: "en-AU" type: "post" description: "ERP Projects are complex. The composition of the ERP Project Team is not always clear. It is one of the most asked questions. In the post, I will cover the various roles within ERP Project Team. Refer to the following" last_modified: "2026-04-29T08:36:04+00:00" categories: [Visioning and Selection] tags: [ERP, ERP Project team, ERP project team composition, ERP project team structure, ERP team, job titles in ERP project, project team, roles within ERP project, team structure] custom_fields: ampforwp-amp-on-off: "default" cos_headline_score: 0 cos_seo_score: 0 cos_headline_text: "What Are The Roles In ERP Project Team? 14 Unique Roles For Solid Delivery!" wpar_republish_meta_query: "2026-04-27 22:17:05" --- # What Are The Roles In ERP Project Team? 14 Unique Roles For Solid Delivery! - ![1 3 SP Singh Blog](https://spsingh.me/wp-content/uploads/2020/11/1-3-576x1024.png) - ![2 2 SP Singh Blog](https://spsingh.me/wp-content/uploads/2020/11/2-2-576x1024.png) - ![3 2 SP Singh Blog](https://spsingh.me/wp-content/uploads/2020/11/3-2-576x1024.png) - ![4 2 SP Singh Blog](https://spsingh.me/wp-content/uploads/2020/11/4-2-576x1024.png) - ![5 3 SP Singh Blog](https://spsingh.me/wp-content/uploads/2020/11/5-3-576x1024.png) - ![6 3 SP Singh Blog](https://spsingh.me/wp-content/uploads/2020/11/6-3-576x1024.png) - ![7 2 SP Singh Blog](https://spsingh.me/wp-content/uploads/2020/11/7-2-576x1024.png) ERP Projects are complex. The composition of the ERP Project Team is not always clear. It is one of the most asked questions. ![ERP Project Team](https://spsingh.me/wp-content/uploads/2020/11/magnet-me-LDcC7aCWVlo-unsplash-1024x683.jpg) In the post, I will cover the various roles within [ERP](https://spsingh.me/what-is-erp/) Project Team. Refer to the following list of roles you may need for your ERP Project. ## Roles within ERP Project Team ### **Project Sponsor** The Project Sponsor is accountable for the project. The Sponsor ensures that the investment is worthwhile and owns the Business Case. The Project Sponsor oversees the project and drive the change initiatives. He is the escalation point and take all crucial decisions and resolve conflicts. ### **Subject Matter Experts (SMEs)** The SMEs are responsible for validating business requirements. They take critical decisions on the solution design. Each Business area must have dedicated SMEs (Finance, Operations, Asset Management). The SMEs own their area of expertise and collaborate to define the needs of the system. Key Members of SMEs, and Project sponsors, form the Project Steering Committee. ### **Project Working Group** This group handles groundwork for SMEs. They assist in tasks like data cleansing, test scripts and training documentation. For more significant projects (over $2M), the Project Working group is incredibly important. In smaller and mid-level projects, SMEs undertake the groundwork. So, we may not need this group. ### **Project Management** The Project Manager handles the day-to-day management of the project. He works with all team members throughout the project. He monitors all tasks (e.g. planning, data migration) to ensure that project remains on track. The Project Manager reports project progress to Project Board or Steering Committee. ### **Business Architect** For more significant projects, we need one big picture thinker. The [Business Architect](https://www.capstera.com/business-architect-role-definition/) takes ownership of overall project requirements. Business Architect advises on the data, business capability, processes, and organisational structure. ### **Solution Architect** The Solution Architect takes ownership of the overall solution. There can be many customisations, integrations, custom development/code. He ensures that the end product is technically sound. And, is scalable to support current and future business needs. ### **Functional Consultanting Team** ERP Functional Consultants specialise in a given stream (Finance, Sales, Production). They work with SME and Project Working groups to configure ERP systems based on the Business needs. They also identify gaps within ERP, where we need customisations. They document gaps, requirements, solution options for SMEs approval. ### **Technical Consulting Team** The Technical Consultants are responsible for undertaking all technical work. They develop reports, design outputs, data migration, custom development and much more. ### **Security Architect** Some industries (like Defence, Aviation, Health) have specific security compliance requirements. You need Security Architect to meet the security needs and compliance approval. ### **User Experience (UX) Consultant** For specific user experience needs, you need a UX consultant. He works with stakeholders to design user experiences for end-user needs. For example, there are particular business needs for mobile apps, field mobility systems. ### **Testing Team** Responsible to plan, prepare and execute the testing of the system. The member of the Working group may also assist this team. ### **Training and Support Team** They plan and deliver end-user training. Support the roll-out of the system and BAU support. The member of the Working group may also assist this team. ### **Change Management** This is a crucial role within any system implementation. The success is in the adoption of standard system capabilities by the business. ### **System Admin** The Project team handover the product to the System Admin team. They are responsible for ongoing support and maintenance of the system. ![ERP Project Team](https://spsingh.me/wp-content/uploads/2020/11/you-x-ventures-Oalh2MojUuk-unsplash-1024x683.jpg) Note that depending on the project requirements, the above roles could vary. Consider the above list as a starting point to assess your project team requirements. Not all positions may be relevant to your project. Please consider this as a general guide. Do not hesitate to get in touch if you like to discuss resource requirements for your project. --- --- title: "What Is The Top Reason For ERP Project Failure?" url: "https://spsingh.me/erp-project-failure/" lang: "en-AU" type: "post" description: "ERP Project Failure Many Enterprise software (ERP/CRM) projects are failing due to this single problem! During Analysis, Customers often prescribe ‘Solution design’ rather than ‘Requirements’ to ERP Consultants. You cannot afford to ignore this problem! Otherwise, it can cost you" last_modified: "2026-04-28T20:06:18+00:00" categories: [Project Execution] tags: [Business Analysis, ERP Analysis, ERP Discovery, ERP Scoping, Project risk, Requirements Elicitation, Solution design] custom_fields: ampforwp-amp-on-off: "default" cos_headline_score: 0 cos_seo_score: 0 cos_headline_text: "What Is The Top Reason For ERP Project Failure?" wpar_republish_meta_query: "2026-04-27 22:08:05" --- # What Is The Top Reason For ERP Project Failure? ## ERP Project Failure Many [Enterprise software (ERP/CRM)](https://spsingh.me/what-is-erp/) projects are failing due to this single problem! During Analysis, Customers often prescribe **‘Solution design’ **rather than **‘Requirements’** to ERP Consultants. You cannot afford to ignore this problem! Otherwise, it can cost you a fortune to complete the project. And, you may get negligible value from your investment. ## The Problem – ERP Project Failure When you build a house, do you specify every detail to the Builder? > _Oh, can I have taps with ‘ON’ and ‘OFF’ button? How about ‘Hot’ & ‘Cold’ buttons?_ Instead, you choose options from the given [Home and Land package](https://www.dalealcock.com.au/what-is-a-house-and-land-package/#:~:text=A%20house%20and%20land%20package%20is%20when%20you%20buy%20a,then%20build%20the%20new%20home.). Therefore, the package is your starting point. Yet, in many Enterprise software implementations, Customers specify the solution to the Consultants. > _Oh, can you add a button, so when I click, I get two options?_ ![erp project failure](https://spsingh.me/wp-content/uploads/2020/11/sebastian-herrmann-oMpknr7yi7g-unsplash-1-1024x683.jpg) Poor consultants, trying to please Customers, start customising the standard software. All unnecessary customisations add to the cost, time, and reduce ROI. If you do not control this, you end up with the over-customised system. It may cost you double the original price and time. You get the little beast that is difficult to support and upgrade. ## The Solution – ERP Project Failure ![erp project failure](https://spsingh.me/wp-content/uploads/2020/11/dimitri-houtteman-l-8rhhUpuyM-unsplash-1024x683.jpg) The Enterprise applications are like Home & Land package. So, get your team (Key Users) to illustrate Business problems, processes, and requirements. Never suggest how the software should meet your needs. Refer to the following practical tips: ### Set a clear expectation on the role of Customer (Key Users) and Consultant: Key Users should explain existing processes, pain points, and requirements. The Consultant should propose solution options and design. Simple! ### Empower consultants to say the right thing and challenge the Key Users: Many Consultants often believe that – the Customer is always right. Consultants often do not like to confront Key Users. So, they choose the easy path of giving whatever Customer wants. This mentality works against you. It leads to massive customisations, over-budget projects and unpleasant outcomes. Thus, empower Consultants to say and do the right thing. ### Familiarise and learn Enterprise software earlier in the project: Organise standard software navigation, terms, concepts training during project initiation. Encourage your team to learn the software terms and concepts. So, the Key Users and Consultants speak the same language. ### Look at the configured software in action: Encourage Key Users to play with the demo system. If possible, get Consultants to add a subset of your data (Customer, vendors, inventory). It helps Key Users to understand standard operating processes within software. The requirements elicitation phase moves swiftly! Again, do not underestimate this problem. Take necessary steps to ensure the success of your ERP software implementation. Good Luck! --- --- title: "ERP Is Not Failing. The Executive Standard Is." url: "https://spsingh.me/erp-is-not-failing/" lang: "en-AU" type: "post" description: "It is common to see this pattern—across councils, organisations, and programs It is common to see executives invest heavily in ERP initiatives with the expectation that clarity, control, and performance will follow. The program is approved.The system is implemented.The reporting" last_modified: "2026-04-27T13:58:08+00:00" categories: [The Sovereign Architect Series, Project Assurance] custom_fields: cos_headline_text: "ERP Is Not Failing. The Executive Standard Is." cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Is Not Failing. The Executive Standard Is. ## It is common to see this pattern—across councils, organisations, and programs It is common to see executives invest heavily in [ERP initiatives](https://spsingh.me/why-erp-initiatives-underperform/) with the [expectation that clarity](https://spsingh.me/why-erp-initiatives-underperform/), control, and performance will follow. The program is approved. The system is implemented. The reporting improves. Yet, when observing how the organisation actually operates post go-live, a consistent pattern emerges: - Numbers are still being validated before meetings - Different leaders interpret the same data differently - Risks surface late - [Decisions are delayed](https://spsingh.me/why-erp-programs-become-messy/) pending confirmation Nothing appears broken. But control is not where it should be. This is not a system failure. It is a standards failure. ## 1. What [executives typically believe](https://spsingh.me/why-erp-initiatives-underperform/): ERP is not failing Most ERP initiatives are framed as disciplined delivery exercises: - Scope is defined - Budget is controlled - Timeline is tracked - Vendors are managed The underlying assumption: > If the system is implemented correctly, the organisation will perform better. This assumption is reasonable. It is also incomplete. Because systems do not create clarity. They reveal whether clarity has been designed. ## 2. What actually happens [after go-live](https://spsingh.me/who-owns-erp-after-go-live/) Once the system is live: - Data is integrated - Reports are standardised - Dashboards are available However, in practice: - Finance is still asked to confirm figures - Reports still require interpretation - Issues still emerge reactively - Decision-making speed does not materially improve The result is consistent: > More information, but not more control. This is where expectations and reality diverge. ## 3. The gap that was never defined Across most ERP programs, one critical element is missing. Executives are rarely asked to define: - What must be visible at any point in time - What decisions must be made without dependency - What risks must be detected before escalation Instead, the focus remains on: - [System capability](https://spsingh.me/why-erp-initiatives-underperform/) - Functional modules - Reporting outputs This creates a structural disconnect between: - What is delivered and - What is required at the executive level This is the Executive Standard Gap ## 4. Making this visible in a real scenario ### Before a Council or Board briefing What effective [executive control](https://spsingh.me/why-erp-initiatives-underperform/) looks like: A single view provides: - Current financial position - Forward forecast variance - Capital program performance - Workforce cost exposure - Enterprise risk signals No follow-up required. No interpretation needed. ### What is typically observed instead Executives ask: - “Are these numbers current?” - “Has this been reconciled?” - “Is there anything we should be aware of?” Information is then provided through: - Spreadsheets - Static reports - Verbal explanations At that point, the role shifts: - From decision-making → validation - From steering → confirming The system exists. But institutional control does not. ## 5. Why this pattern persists ERP programs are optimised for delivery: - Vendors optimise for functionality - Project teams optimise for go-live - IT optimises for system stability No one is explicitly accountable for defining: > What capability must exist at the executive level once the system is live? As a result: - Outputs are delivered - Outcomes are diluted ## 6. What an executive standard actually looks like A clear executive standard defines what must be visible and actionable without friction. This includes: - Real-time financial position - Forward-looking financial risk - Capital program performance across directorates - Workforce cost and vacancy exposure - Procurement commitments before spend is realised - Asset risk and infrastructure backlog - Service demand and escalation patterns - Compliance exposure and audit signals Not across multiple reports. Not through interpretation. In one coherent, reliable view. ## 7. What changes when the standard is clear ### At the executive level The shift is immediate: - From validating numbers → to setting priorities - From delayed decisions → to early intervention - From relying on individuals → to relying on systems The key question changes from: > “Is this accurate?” to: > “What action should be taken?” ### Across the organisation - A single version of truth emerges - Finance moves from reconciliation to forecasting - Risks surface earlier - Decision-making accelerates The organisation transitions: From managing uncertainty to managing trade-offs. ## 8. The cost of not setting the standard If the standard is not defined: - Systems will still be implemented - Reporting will still improve But: - Decisions remain slow - Risk visibility remains delayed - Dependency on individuals continues The outcome is consistent: A modern system operating with legacy behaviour. ## 9. Reframing the decision — with concrete examples The decision is not: - Which ERP platform to select - Whether delivery will meet time and budget Those are necessary, but insufficient. The real decision is: > What decisions will become faster, earlier, and more reliable as a result of this investment? ### Example 1 — Financial control **Typical approach:** “Provide monthly financial reports for review.” **Reframed standard:** “Executives can see real-time financial position and a 3-month forward forecast at any time.” **What this changes:** - Forecasting becomes embedded, not manual - Finance shifts from reporting → advising - Decisions on cost control happen earlier ### Example 2 — Capital program oversight **Typical approach:** “Track project status through periodic updates.” **Reframed standard:** “Executives can identify which capital projects will miss milestones before delays become visible externally.” **What this changes:** - Project data is linked to financial impact - Early warning indicators are built into the system - Intervention occurs before escalation ### Example 3 — Procurement control **Typical approach:** “Monitor expenditure against budget.” **Reframed standard:** “Executives can see committed spend before it is incurred.” **What this changes:** - Purchase orders become visible at commitment stage - Budget control becomes proactive - Financial surprises reduce significantly ### Example 4 — Risk and compliance **Typical approach:** “Report risks through periodic governance forums.” **Reframed standard:** “Executives can see emerging risks 30–90 days before impact.” **What this changes:** - Risk signals are embedded in operational data - Compliance issues are surfaced early - Governance becomes predictive, not reactive ## 10. What needs to happen next — practical actions ### 1. Define the [executive visibility standard](https://spsingh.me/why-no-one-owns-organisational-improvement/) This must be explicit and documented. **Examples:** - “CEO can view real-time financial position and forward variance at any time” - “Top enterprise risks are automatically surfaced weekly” - “Capital delays are visible at least 4 weeks before milestone breach” If this is not written, it will not be delivered. ### 2. Anchor system design to decisions Every design choice must answer: - What visibility does this create? - What decision does this enable? **Examples:** - A dashboard that shows past spend only → low value - A dashboard that shows forecast variance → decision-critical - Procurement configuration that records invoices → reactive - Procurement configuration that tracks commitments → proactive ### 3. Align ownership to outcomes Clarity of ownership is essential. **Examples:** - Infrastructure team owns asset data accuracy - People & Culture owns workforce data - Finance owns financial structure and integrity IT supports the system. It does not own business truth. ### 4. Design ERP as a control system ERP must actively enable control, not just reporting. **Example:** - Rising overtime cost appears in executive view - Drill-down identifies department and vacancy gap - Action is taken before budget impact escalates This is system-enabled control. ### 5. Establish a capability function ERP does not sustain itself post go-live. A capability function must own: - Process optimisation - System utilisation - Adoption - Continuous improvement - Value realisation **Example:** - Monitoring procurement cycle time post-implementation - Tracking whether decision speed has improved - Identifying underutilised system features Without this, ERP value declines over time. ## Final position Across organisations, the pattern is consistent: ERP systems are delivered. Executive control is not. The difference is not technology. It is whether a clear executive standard was defined at the start. When that standard is explicit: - Design becomes aligned - Delivery becomes purposeful - Outcomes become measurable ERP then becomes what it was intended to be: Not a system implementation, but the foundation of institutional clarity and control. --- --- title: "ERP Value Leakage: Cost of Capability Development" url: "https://spsingh.me/erp-value-leakage/" lang: "en-AU" type: "post" description: "ERP Value Leakage: The Cost You’re Not Measuring You have invested in core business systems—ERP, HRIS, finance platforms, integrations. These systems are not just tools. They define how your organisation: processes transactions manages financial control runs operations produces reporting makes" last_modified: "2026-04-26T14:23:41+00:00" categories: [The Sovereign Architect Series, Capability Development] custom_fields: cos_headline_text: "ERP Value Leakage: Cost of Capability Development" cos_seo_score: 0 cos_headline_score: 0 cos_headline_has_been_analyzed: 1 ig_es_is_post_notified: 1 --- # ERP Value Leakage: Cost of Capability Development ## ERP [Value Leakage](https://spsingh.me/why-no-one-owns-organisational-improvement/): The Cost You’re Not Measuring You have invested in core business systems—ERP, HRIS, finance platforms, integrations. These systems are not just tools. They define how your organisation: - processes transactions - manages financial control - runs operations - produces reporting - makes decisions In effect, **they are your operating model embedded in technology**. After implementation, most organisations assume the job is largely done: - system is live - users are trained - IT is supporting At that point, attention shifts elsewhere. This is where the misunderstanding begins. Because there is a second phase—less visible, but far more important: **How the organisation continuously uses, improves, and extracts value from that system over time.** That is what [capability development](https://spsingh.me/the-roles-within-capability-development/) is. It is not training. It is not IT support. It is the structured ability of your organisation to: - own and improve business processes - use the system as intended - adapt it as the business evolves - extract increasing value year after year If that capability does not exist, the system does not fail. **It simply delivers less and less value over time.** ## You’re Not Deciding on Cost. You’re Deciding How Much Value You’re Willing to Lose. ### 1. You are asking the wrong question You are likely asking: _“How much will [capability development](https://spsingh.me/capability-development/) cost us?”_ That question assumes you still have a choice. You don’t. You have already invested—millions in ERP, systems, transformation programs. The decision in front of you is not whether to spend more. **It is whether you are prepared to continue losing value from what you have already paid for.** If your systems are live, the exposure has already started. _So the real question is: how much value are you losing every month without knowing it?_ ### 2. What you believe (and why it feels reasonable) You have been told: - The system is implemented - Users have been trained - IT is supporting it - The project is “successful” On paper, everything looks controlled. So [capability development](https://spsingh.me/the-hidden-cost-of-erp/) feels optional—something to optimise later. That belief is logical. It is also where most organisations quietly start underperforming. Because a working system is not the same as a working business. _If success is go-live, why do benefits stall immediately after?_ ### 3. What is actually happening inside your organisation The system is running. But underneath, a different reality is forming: - People stop using the system as designed - Workarounds appear within months - Spreadsheets return - Data becomes inconsistent - Reports get questioned - Decisions move outside the system Nothing breaks visibly. But value starts leaking—silently, continuously. You paid for an integrated platform. You are getting fragmented execution. _If your ERP is not driving decisions, what exactly is it doing?_ ### 4. Why this is happening (and where the gap really sits) Because ERP is being treated as a system. It is not. **ERP is your operating model embedded in technology.** And operating models require: - clear [ownership](https://spsingh.me/why-no-one-owns-organisational-improvement/) - ongoing optimisation - performance accountability - continuous improvement Look at your current structure: | Area | What Exists | What’s Missing | | --- | --- | --- | | IT | Uptime, security, support | Business value ownership | | Business | Basic usage | Accountability for improvement | | Leadership | Investment approval | Value realisation ownership | No one owns how the system gets better. No one is accountable for extracting more value. This is not an operational gap. **This is a governance gap.** _If no one owns value, why would value improve?_ ### 5. [The cost you are already paying](https://spsingh.me/the-hidden-cost-of-erp/) (but not measuring) You are not avoiding cost by delaying capability development. You are absorbing it—every day. It shows up as: - ERP modules you paid for but don’t use - Parallel spreadsheets - Manual work where automation should exist - Slow, inconsistent processes - Poor data driving weak decisions - Benefits that never fully materialise You invested in a high-performance system. You are operating it below capacity. Not because it cannot deliver. Because no one is responsible for making it deliver. **This is not a future risk. This is happening now.** _If you audited your ERP today, how much of its capability are you actually using?_ ### 6. The difference you are missing: Buying vs Running There is a fundamental distinction: | Buying the System | Running the System | | --- | --- | | One-time decision | Ongoing discipline | | Vendor-led | Business-owned | | Project-focused | Performance-focused | | Ends at go-live | Starts at go-live | Most organisations are structured for buying. Very few are structured for running. That is where value is lost. _If your system is not improving every quarter, is it already declining?_ ### 7. Reframe the Decision—From Cost Control to [Value Recovery](https://spsingh.me/the-hidden-cost-of-erp/) Up to this point, the pattern is clear: - The system is live - Usage is inconsistent - Workarounds are emerging - Value is leaking This is not a technology issue. It is not even a people issue. **It is a decision framing issue at the executive level.** When you ask, _“What will this cost?”_, you are treating capability development as a new investment competing for budget. But everything described earlier—the drift, the workarounds, the underutilisation—already has a cost. It is just not formally recognised. So the decision is being made on incomplete information. To correct this, you need to shift the frame: - From **cost control** → to **value recovery** - From **new spend** → to **existing value leakage** - From **optional initiative** → to **necessary correction** Ask instead: - **What return are we currently not realising from our ERP and systems?** (This connects directly to underutilised modules, poor adoption, and missed efficiencies.) - **What value is being left on the table due to inconsistent usage and weak ownership?** (This reflects the operational reality already visible across teams.) - **What is the cost of continuing like this for the next 12–24 months?** (This forces a forward view of accumulated inefficiency, rework, and decision risk.) Once you answer these questions, the position changes. Capability development is no longer a discretionary line item. **It becomes the mechanism to recover, protect, and compound the value of investments already made.** If the organisation is already leaking value, doing nothing is not neutral. **It is an active decision to continue the loss.** ### 8. What You Need to Do Next—Translate Insight into Structure If the problem is unclear ownership and unmanaged value, the solution is not more activity. It is **structure, accountability, and measurable outcomes**. The following moves are sequential and interdependent. #### 1. Assign Real Ownership (This is where recovery starts) The earlier issue was not system failure—it was absence of ownership. So the first correction is precise and non-negotiable: - **Who owns each end-to-end business process?** (e.g. Procure-to-Pay, Order-to-Cash, Hire-to-Retire) - **Who is accountable for improving that process over time—not just operating it?** This is not a nominal role. Ownership must include: - authority to change the process - responsibility for performance - accountability for outcomes Without this, optimisation will not occur. You will continue to have: - IT managing the system - business using the system - no one improving the system **Ownership is the control point where value recovery begins.** #### 2. Establish a Capability Function (Not Support) Once ownership exists, it needs a structure to operate within. This is where most organisations default incorrectly to IT support or training teams. That is insufficient. You need a **dedicated capability function**—small, focused, and outcome-driven. Its mandate is not to “help users.” Its mandate is to **improve how the organisation operates through the system.** Core responsibilities must include: - **Process optimisation** Identify inefficiencies, remove workarounds, align to intended design - **System utilisation** Ensure existing functionality is fully used before new investment - **Adoption** Drive consistent, correct usage across teams - **Continuous improvement** Regularly refine processes as business needs evolve - **Value realisation** Track and increase measurable benefits from the system This function sits between business and IT. - IT ensures the system runs - Business executes work - **Capability function ensures the system improves** Without this layer, drift will return—regardless of how good the initial implementation was. #### 3. Link Capability to Measurable Outcomes (This is what sustains it) Ownership and structure are necessary—but insufficient without measurement. If capability is not tied to outcomes, it becomes: - activity - workshops - training cycles But not impact. You need to define and track a small set of operational metrics that directly reflect value: - **Efficiency** Are processes requiring less effort and fewer steps? - **Accuracy** Is data reliable and consistent across the system? - **Speed** Are cycle times improving (approvals, processing, reporting)? - **Decision quality** Are leaders using system-generated insights with confidence? These metrics must be: - owned by process owners - supported by the capability function - visible at leadership level This closes the loop: - Ownership drives accountability - Capability function drives improvement - Metrics validate value At this point, capability development is no longer an initiative. **It becomes part of how the organisation operates.** ## Closing Integration The earlier problem was silent value leakage. The reframed decision exposes it. The actions above correct it structurally. - Reframing changes how you see the problem - Ownership establishes control - Capability function enables improvement - Measurement ensures it continues Without these, the system will remain stable—but value will continue to decline. With them, the same system begins to produce increasing returns over time. **That is the difference between having a system—and running it as an asset.** ## Final Reality You are not deciding whether to invest in capability development. You are deciding whether to: - **recover and multiply the value of your investment** or - **continue losing it quietly over time** Once that is clear— **this stops being a cost discussion. It becomes a business decision.** --- --- title: "How To Estimate ERP Project? Download A Free Estimator!" url: "https://spsingh.me/estimate-erp-project/" lang: "en-AU" type: "post" description: "ERP implementations are complex. There are many moving parts. As a Sponsor, you must look at the big picture and need a 360-degree view of project costs. However, you often find it difficult to get a firm project estimate. As" last_modified: "2026-04-27T09:06:03+00:00" categories: [Home] tags: [CRM estimate, ERP, ERP estimate, estimation, software, software estimatation, software estimate] custom_fields: ampforwp-amp-on-off: "default" cos_headline_score: 0 cos_seo_score: 0 cos_headline_text: "How To Estimate ERP Project? Download A Free Estimator!" wpar_republish_meta_query: "2026-04-25 22:15:40" --- # How To Estimate ERP Project? Download A Free Estimator! ERP implementations are complex. There are many moving parts. As a [Sponsor](https://www.projectmanager.com/blog/what-is-a-project-sponsor#:~:text=The%20project%20sponsor%20is%20a,the%20reason%20for%20the%20project.), you must look at the big picture and need a 360-degree view of project costs. However, you often find it difficult to get a firm project estimate. As there are many factors that influence project cost ( e.g. Vendors, Internal cost, Hardware cost). You often have doubts like: - Has vendor covered implementation services and license cost in the estimate? - What are the unstated assumptions? - What are the other project costs? - Have we missed anything major – risk of unpleasant surprises during the project? I know that feeling and got a solution for this nagging problem! ## How to [Estimate ERP Project](https://spsingh.me/check-project-estimates/)? I have developed a Master ERP Estimate Template. Download it and add known estimates. Clearly see estimates that are missed by vendors, hardware and internal project costs. You can see the cost for the overall project within minutes. Use this template as a Master Estimate sheet or as a checklist. **Subscribe and Download now:** [![estimate erp project](https://spsingh.me/wp-content/uploads/2020/11/ERP-template-1-1024x332.jpg)](https://spsingh.me/wp-content/uploads/2020/11/ERP-Estimate-Master-Template.xlsx) ![Subscribe & Download Now](https://spsingh.me/wp-content/plugins/bloom/images/premade-image-02.png) ## Subscribe & Download Now Join our mailing list to receive the latest news and updates SUBSCRIBE! ## You have Successfully Subscribed! --- --- title: "Key Software Terms You Must Know – Welcome To The Tribe!" url: "https://spsingh.me/key-software-terms/" lang: "en-AU" type: "post" description: "No one likes jargon! But every industry has it. My heart pumps 10X when I hear Accounting teams in quick succession. Oh, we need to look at our Cashflow, EBIT and rethink Chart Of Account structure. For this, my brain" last_modified: "2026-04-26T16:45:16+00:00" categories: [Home, Visioning and Selection] tags: [bespoke, business, business software, cots, ERP, onprem, saas, software, software jargon, software terminology, software terms, software types, system software] custom_fields: ampforwp-amp-on-off: "default" cos_headline_score: 0 cos_seo_score: 0 cos_headline_text: "Key Software Terms You Must Know - Welcome To The Tribe!" wpar_republish_meta_query: "2026-04-25 22:14:40" --- # Key Software Terms You Must Know – Welcome To The Tribe! No one likes jargon! But every industry has it. My heart pumps 10X when I hear Accounting teams in quick succession. > _Oh, we need to look at our Cashflow, EBIT and rethink Chart Of Account structure._ For this, my brain may register – There is some Accounting work. That is all! ![key software terms](https://spsingh.me/wp-content/uploads/2020/10/nick-fewings-pIY6sz-texg-unsplash-1024x768.jpg) How about a software jargon? Consider this, for example: > _Our ERP is the next-gen SaaS Solution!_ If you are a non-technical Businessperson, your brain may register – _Hmm, the software may be good!_ ![key software terms](https://spsingh.me/wp-content/uploads/2020/10/afif-kusuma-ryNmjBolkh0-unsplash-1024x713.jpg) However, if you are sponsoring a software project, then you must take time to learn the key terms asap. Take time to understand them and lead the team from front! In this post, I have covered key software terms that you must know. Terms such as – ERP, SaaS, COTS will never overwhelm you. I will rip apart this jargon forever. It is time to register facts and take notes, so pay full attention! ## Getting back to basics – What is a software? Software is a set of instructions for a computer system to cater for specific business needs. For example, consider a Calculator app on your computer. Developers have written instructions to perform Addition, Subtraction and so on. These set of instructions are collectively known as software. Every interaction you are having on your computer, mobile or a tablet is via a software. Ok! We covered some primary ground. But what about the jargon that IT people confuse us all? Let us get right into it! For simplification, I categorise software into the following groups: - Purpose - Development - Hosting ## 1. Purpose We group software based on its purpose. Based on the primary purpose of the software, we set them into the following groups. Note that there can be more groups. ## Key Software Terms – Purpose The following are the key software terms for illustration purposes only: - Enterprise software - System software - Specialised software Let us now understand each type in detail. ### 1. Enterprise software The Enterprise software caters for your end-to-end business needs. Let us consider a Manufacturing business with the following processes – Inventory/Warehouse, Production, Distribution, Marketing/Sales, HR/Payroll, Procurement and Finance The above functions have a high interdependency. For example, Production planning needs information from inventory and sales orders. The Enterprise software automates all the operations within the Manufacturing organisation. You can manage your Inventory, Production, Dispatch, and other functions within one software. [ERP (Enterprise Resource Planning) ](https://spsingh.me/what-is-erp/)is one of the most common Enterprise software. ERP has its roots in the Manufacturing industry. But, modern ERP supports various industry verticals (e.g. Professional Services, Retail). ERP is a collection of integrated modules (e.g. Production, Finance, Supply Chain). Based on your business and industry, the ERP vendor implements relevant modules. We use Customer Relationship Management (CRM) software to manage enterprise-wide end-to-end sales operations. We use Human Capital Management (HCM) to manage all Human Resource management processes. In summary, this software has an enterprise-wide reach. They are built to meet end-to-end business needs. ### 2. System Software The purpose of System software is to run your computer systems. We also call them an Operating system. You need an Operating system to run all computer devices—for example: - Microsoft Windows 365 for PC - macOS for Macintosh - Android OS for Android phones - iOS for Apple phones You need a specific [Operating system](https://www.britannica.com/technology/operating-system) for Servers, Smartwatches, Mobile phones, Tablets and Computers. It is the first software that you need before you can use any other application on your device. It manages the resources of your device to give you the most from the hardware. ### 3. Specialised software It is a collection of software types based on industry specialist needs. Consider the following examples: - Business software: You use these applications for specific business purpose – for example, Microsoft Word for word processing. Excel for mathematical calculation and modelling. The other examples are Expense management, electronic Document approval, Customer Surveys and so on. - Mobile Apps: The apps use Mobile ecosystem (System software and hardware) for specific operation. e.g. Google Maps app use your GPS location to guide directions. - Middleware: It helps software to interoperate. It is a translation service between Operating system and Application software. So, you need a Middleware to get a given Application software to run on Operating system - Security software: It helps your computer device to protect from virus attacks. It protects your privacy and data. - Virus: It is a specialist software that attacks/cripples other software and execute a pre-determined plan (e.g. steal data) ## 2. Development Under this category, we group software based on ownership of its development. Let us consider the following groups under the Development category: ## Key Software Terms – Development ### 1. Readymade There is a vast market of readymade software that is available to buy and ready to use. You can adjust specific software settings based on your business needs. You can integrate the software with other software as well. We refer to this type as Commercial Off The Shelf (COTS) software. ### 2. Custom software You develop Custom software based on your specific needs. It makes sense to pay for custom development if COTS software can not meet your business needs. You may build custom software for a new unique product or service. It can be an original, ground-breaking start-up app. Custom software is also known as Bespoke software. ### 3. Hybrid It is a mix of COTS and custom software. Many COTS software provides a framework for custom development. So, you undertake custom software development to cover any gaps in the COTS software. For example – Excel Macros. We get MS Excel (COTS software) for our day to day tasks and write MS Excel macros to automate manual processes. Similarly, we write custom software on ERP to meet the business-specific needs ## 3. Hosting All software needs storage space. There are many options available now. In this group, we segregate software based on its hosting. ## Key Software Terms – Hosting ### 1. On-Prem It is a traditional way of storing software in your infrastructure (Servers). You handle procuring and maintaining infrastructure. You are responsible for maintaining and keeping software up to date. ### 2. SaaS The software vendors handle providing storage space for the software and your data. You pay a subscription fee. The vendor takes care of all the software hosting requirements. The vendor also manages all software and infrastructure maintenance and upgrade activities. ### To Conclude Note that it is not a complete list as you are not going to sit in a university exam – hopefully! The post intends to familiarise with the standard terms. Software is everywhere, from the smartwatch to the car you drive. If you ever are involved in a software implementation, then you must learn software terms. Remember, to be in the game; you must know its rules. Thus, take some time to educate yourself. You will be able to drive the team with confidence and have a positive contribution. These terms are quite simple, but if you do not involve in software projects on regular basis, then you may forget it. So, save this page, subscribe to the blog, email it to yourself before you move on! --- --- title: "Why No One Owns Organisational Improvement?" url: "https://spsingh.me/why-no-one-owns-organisational-improvement/" lang: "en-AU" type: "post" description: "The Hidden Gap Costing You Millions: Why No One Owns Organisational Improvement 1. You Think Improvement Is Happening. That’s the Problem. Most executive teams believe their organisation is improving. There are transformation programs.ERP systems have been implemented.Teams are “continuously improving.”" last_modified: "2026-04-25T14:09:42+00:00" categories: [The Sovereign Architect Series, Capability Development] custom_fields: cos_headline_text: "Why No One Owns Organisational Improvement?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Why No One Owns Organisational Improvement? ## The Hidden Gap Costing You Millions: Why No One Owns Organisational Improvement ### 1. You Think Improvement Is Happening. That’s the Problem. Most executive teams believe their organisation is improving. There are transformation programs. [ERP systems have been implemented](https://spsingh.me/understanding-erp-systems/). Teams are “continuously improving.” On paper, everything looks active. But here is the uncomfortable question: **If improvement is truly happening, why do the same problems keep returning?** - Finance still relies on spreadsheets - [Processes break under pressure](https://spsingh.me/why-erp-initiatives-underperform/) - Systems are underutilised - [Decisions take longer than they should](https://spsingh.me/what-is-the-cost-of-incompetence/) That contradiction is not coincidence. **It is structural.** ### 2. The Assumption That Creates the Gap Executives distribute improvement across the organisation: - Operations owns processes - IT owns systems - Finance owns efficiency - HR owns capability It sounds logical. It feels aligned. But in reality, this creates a silent failure condition: **When improvement is everyone’s responsibility, it becomes no one’s accountability.** And without accountability, there is no system. Only activity. ### 3. What Organisations Actually Do Instead In practice, improvement shows up in fragments: - ERP implementations promise transformation - Lean or Six Sigma initiatives drive short-term gains - Consultants deliver roadmaps - [Strong managers fix local issues](https://spsingh.me/why-erp-initiatives-underperform/) Each effort works—in isolation. But step back and observe the pattern: - Improvements don’t connect - Gains don’t compound - Problems reappear in new forms The organisation becomes a **patchwork of fixes**, not a system of performance. **Improvement is happening everywhere. That’s exactly why it’s not working.** ### 4. The Real Cost (That No One Measures) This is not a theoretical issue. It has direct financial and operational impact: - **ERP underutilisation:** 30–50% of capability never realised - **Rework and inefficiency:** [hidden cost embedded in operations](https://spsingh.me/what-is-the-cost-of-incompetence/) - **Decision delays:** caused by poor data integrity - **[Shadow systems](https://spsingh.me/it-is-not-my-problem/):** spreadsheets replacing system-of-record - **Repeated transformation spend:** solving the same problems again Most organisations are not under-investing in improvement. **They are paying for it repeatedly—without ever building it.** ### 5. Why This Keeps Happening There are four structural drivers: #### 1. [Improvement Was Never Designed as a Function](https://spsingh.me/why-erp-initiatives-underperform/) Historically, improvement relied on individuals, not systems. Good people drove change. When they left, progress reset. #### 2. Pressure Creates Short-Term Behaviour Under delivery pressure, organisations optimise for: - Speed - Cost - Immediate outcomes This produces activity, not capability. #### 3. Technology Creates a False Promise ERP and digital systems are treated as the solution. But systems do not fix: - Broken processes - Poor data discipline - Weak governance They scale them. #### 4. Growth Increases Complexity Faster Than Control As organisations grow: - Processes fragment - Data becomes inconsistent - Systems disconnect Without a unifying structure, complexity wins. ### 6. What This Really Is: [The Ownership Gap](https://spsingh.me/why-erp-initiatives-underperform/) This is not a process issue. It is not a system issue. It is not a people issue. It is a structural gap: > **The Organisational Improvement Ownership Gap** No function is accountable for: - Making the organisation better every month - Connecting process, systems, and data - Ensuring improvements compound over time Until that gap is closed, every initiative operates in isolation. ### 7. Why Current Approaches Fail Organisations typically rely on: | Approach | Why It Fails | | --- | --- | | ERP Implementation | Focuses on system, not behaviour or process ownership | | Continuous Improvement Programs | Temporary, not embedded | | Consultants | Deliver insight, not ongoing capability | | Internal Teams | Optimise locally, not system-wide | Each solves a piece. None own the system. ### 8. The Reframe: Improvement Is a Capability Function Improvement is not an initiative. It is not a project. It is not a methodology. It is a **core organisational capability**. A structured function responsible for: - End-to-end process optimisation - System adoption and effective usage - [Data quality and integrity](https://spsingh.me/understanding-erp-systems/) - Cross-functional alignment - Continuous value realisation This function acts as the **operating engine of performance**. Not a support role. Not an add-on. A core discipline. ### 9. What High-Performing Organisations Do Differently They make one critical shift: They **institutionalise improvement**. That means: - Clear ownership at an executive level - Defined accountability for outcomes - Integrated view of process, systems, and data - Continuous measurement of value Improvement stops being episodic. It becomes structural. ### 10. What You Should Do Next If this pattern feels familiar, the next step is not another initiative. It is structural clarity. Start here: #### 1. Define Ownership Assign a single point of accountability for organisational improvement. #### 2. Establish the Function Create a capability that integrates: - Process - Systems - Data #### 3. Change the Metrics Stop measuring: - Project delivery - Go-live success Start measuring: - Adoption - Efficiency - Data integrity - Value realisation ### Final Line You do not have an improvement problem. You have an ownership problem. **And until someone owns making the organisation better—continuously— you will keep paying for transformation without ever achieving it.** --- --- title: "Where do we start with AI?" url: "https://spsingh.me/where-do-we-start-with-ai/" lang: "en-AU" type: "post" description: "Most organisations don’t fail at AI—they start in the wrong place 1. You Don’t Start with AI. You Start with What AI Will Amplify Executives are being asked to “start their AI journey.” It sounds logical—define a roadmap, select tools," last_modified: "2026-04-24T13:18:55+00:00" categories: [The Sovereign Architect Series, AI] custom_fields: cos_headline_text: "Where do we start with AI?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Where do we start with AI? **Most organisations don’t fail at AI—they start in the wrong place** ## 1. You Don’t Start with AI. You Start with What AI Will Amplify Executives are being asked to “start their [AI journey](https://spsingh.me/need-an-erp-system-for-my-business/).” It sounds logical—define a roadmap, select tools, launch initiatives. But pause for a moment. AI does not operate in isolation. It sits on top of your data, your systems, your processes, and your decisions. It observes how your organisation behaves—and then accelerates it. So the real question is not _“Where do we start with AI?”_ It is: > **“If [AI magnifies how we operate today](https://spsingh.me/what-is-the-cost-of-incompetence/), what exactly will it magnify?”** If the answer is unclear, the starting point is already wrong. ## 2. AI Is Not One Thing—And That’s Where Confusion Begins Part of the confusion comes from how AI is understood. Some see AI as tools—ChatGPT, Copilot, automation assistants. Others see it as something more advanced—systems that run processes, make decisions, and operate independently. Both views are correct. But they describe different layers. - **Assistive AI** supports people (drafting, analysing, summarising) - **Analytical AI** identifies patterns and predicts outcomes - **Agentic AI** acts—executing workflows and decisions within defined rules The mistake is subtle but significant: > Organisations try to jump to the layer where AI _acts_, before stabilising the layers where AI _learns_. Which leads to a more important question: **[What happens when AI is asked to act](https://spsingh.me/authority-trap/) inside an environment that is not clearly defined?** ## 3. [AI Does Not Create Problems](https://spsingh.me/erp-is-not-an-it-project/). It Exposes What Already Exists _Reality_ When AI is introduced, it quickly reveals something most organisations have been managing around rather than fixing. Not technical gaps—but **artificial dependencies**. These are conditions that make the organisation function, but not cleanly: ### In Systems - Multiple applications holding conflicting data - No clear system of record - Workarounds outside core platforms ### In Governance - Decisions made informally - Ownership unclear - Accountability diluted across teams ### In Business Logic - Different teams performing the same process differently - Rules interpreted, not defined - Variation accepted as “how we work” These dependencies are rarely documented. They are absorbed into daily operations. AI does not remove them. It **makes them visible—immediately and objectively**. And once visible, a new tension emerges: **Do we fix them—or automate them?** ## 4. Why Organisations Get This Wrong To understand this tension, it helps to look at how AI actually works. AI relies on three things: - What has happened (**data**) - What usually happens (**patterns**) - What should happen (**objectives and rules**) Most organisations have the first two. Very few have the third clearly defined. - No single definition of the “correct” process - No enforced system of record - No clear decision authority So when AI is introduced, it does what it is designed to do: It learns from existing behaviour. Which leads to a predictable outcome: > **If your organisation is inconsistent, AI learns inconsistency. If your data is fragmented, AI reinforces fragmentation.** This is not a failure of AI. It is a reflection of the environment it is placed in. ## 5. The Risk Is Subtle—but Significant At this point, many organisations make a well-intentioned but critical move: They introduce more advanced AI—automation, workflows, even agentic capabilities—to “fix” the situation. But consider what is actually happening. - Decisions are automated without agreed rules - Data conflicts are acted upon instead of resolved - Process variations are embedded into workflows The organisation appears more efficient. In reality, it has become **more complex, less visible, and harder to control**. And because [AI operates at speed and scale](https://spsingh.me/driving-change/), these issues compound quickly. This raises a practical question: > **Would you automate a process you cannot clearly explain today?** If the answer is no, then the approach needs to change. ## 6. The Reframe: Use AI Before You Let It Act The solution is not to delay AI. It is to **use AI differently at the start**. Instead of asking AI to automate, use it to **understand and stabilise**. This creates a natural progression: ### First, AI as a Resolution Tool [AI helps you](https://spsingh.me/automation-is-not-always-good/): - Analyse data across systems - Identify inconsistencies and duplication - Map how processes actually run - Surface decision bottlenecks It brings clarity—quickly, and with evidence. ### Then, Human Decision Leaders define: - What the system of record is - What the standard process should be - Who owns decisions and data This is where structure is created. ### Finally, [AI as an Execution Layer](https://spsingh.me/erp-journey-actually-begins-after-go-live/) Only then does AI: - Automate workflows - Execute decisions - Optimise operations Now, AI is not guessing. It is operating within **clear boundaries**. This sequencing matters. > **[AI should first create clarity](https://spsingh.me/cost-of-delay/)—before it is trusted to act.** ## 7. What This Means for Your Organisation If you are deciding where to begin, the path is more straightforward than it appears. ### Start by exposing reality Use AI to analyse your current state: - Where does data conflict? - How many versions of the same process exist? - Where do decisions actually happen? ### Move to defining control Establish: - A clear system of record - Ownership of key data and processes - Standard business rules ### Stabilise the environment - Align systems with decisions - Remove workarounds - Enforce consistency ### Then introduce advanced AI Once three conditions are met: - **Clarity** — one version of truth - **Control** — defined ownership - **Consistency** — standard processes Now AI can safely: - Automate - Predict - Act # Final Perspective Most organisations think AI is something they need to _implement_. In practice, AI is something that **reveals how ready they are**. > **Use AI early—but use it to understand your organisation, not to bypass it. Only when your organisation is clear should AI be allowed to act.** That is the difference between: - Accelerating confusion - And enabling transformation --- --- title: "Who Owns ERP After Go-Live?" url: "https://spsingh.me/who-owns-erp-after-go-live/" lang: "en-AU" type: "post" description: "You think ERP success is decided at go-live. It is actually decided the day after. Most executive teams are told to focus on delivery—timeline, budget, go-live readiness.That creates a false finish line. Because the moment the system goes live, a" last_modified: "2026-04-23T13:40:25+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Who Owns ERP After Go-Live?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Who Owns ERP After Go-Live? ### You think ERP success is decided at go-live. It is actually decided the day after. Most executive teams are told to focus on delivery—timeline, budget, go-live readiness. That creates a false finish line. Because the moment the system goes live, a quieter, more important question emerges: Who will make this system better every month from now on? If that question is not answered clearly, the investment starts to decay immediately. If go-live is success, why do most ERP benefits never fully materialise? ### It feels logical to hand ERP to IT. That is where the trap begins. The reasoning is simple and widely accepted: - ERP is a system - IT owns systems - Therefore, IT owns ERP From an operational standpoint, this makes sense. IT ensures: - System uptime - Security and access - Technical support - Upgrades Everything appears controlled. But this is surface-level thinking. It assumes ERP is primarily a technology asset. It is not. ERP is how your organisation operates, makes decisions, and controls performance.  If ERP defines how your business runs, why would ownership sit outside the business? ### The system works. The business quietly stops using it properly. What unfolds post go-live is predictable: - Reports exist, but teams export data into Excel - Processes are defined, but workarounds emerge - Data is captured, but not trusted - Features are available, but not used Example: A payroll and HR system is implemented to streamline employee lifecycle management. Six months later: - Managers still track approvals via email - HR builds shadow trackers outside the system - Payroll corrections increase due to poor upstream data Nothing is “broken.” But the system is no longer shaping behaviour. Another example: Finance implements automated procurement workflows. Without ongoing optimisation: - Approval chains become bottlenecks - Users bypass controls - Spend visibility reduces The ERP becomes a passive tool, not an active control mechanism. If the system is live but decisions are still made outside it, what exactly did you implement? ### The real issue is not capability of the system. It is absence of ownership- Who Owns ERP After Go-Live? This happens because of a structural gap: IT teams are designed to: - Maintain stability - Manage access - Apply patches and upgrades They are not designed to: - Redesign business processes - Improve workflows across departments - Drive behavioural adoption - Ensure the system is used optimally So what happens? The ERP is maintained, but not evolved. No one is accountable for: - Improving how work flows through the system - Ensuring users adopt best practice - Rolling out new capabilities - Extracting increasing value over time This is where value is lost—quietly, structurally, and predictably. If no one owns improvement, why would the system ever get better? ### The cost is not visible in budgets. It shows up in missed potential. This is not an implementation failure. It is a value erosion problem. - 30–60% of ERP capability remains unused - Manual work persists under a digital façade - Decision-making remains fragmented - ROI plateaus early From an executive perspective: You funded transformation. You received system stabilisation. The organisation adapts just enough to function—but not enough to improve. Over time, this creates a false narrative: “The system is not delivering what we expected.” In reality: The organisation never structured itself to extract value from it. If you are not actively increasing value from ERP, are you slowly losing it? ### The shift: from system ownership to capability ownership. ERP should not be treated as a system to support. It must be treated as a capability to continuously develop. This requires a different construct: **A Capability Development Function** Not a project team. Not IT support. But a business-aligned function responsible for making ERP better over time. This function sits between: - Business operations - Technology platform Its purpose is simple but critical: Ensure the organisation operates optimally through the ERP. Think of it this way: - IT keeps the system running - The Capability Function ensures the business runs better because of the system Without this, ERP becomes infrastructure. With this, ERP becomes a performance engine. If ERP is meant to improve your organisation, who is actively improving the ERP? ### What this Capability Development Function actually does (in practical terms) This is not theoretical. It is operational and measurable. #### 1. Process Optimisation - Continuously review and refine end-to-end workflows (e.g. procure-to-pay, hire-to-retire) - Remove inefficiencies, bottlenecks, and workarounds - Align system usage with best-practice processes Example: Reducing a 7-step approval process to 3 without losing control—improving speed and compliance. #### 2. Adoption and Training - Develop structured training materials aligned to real roles - Monitor system usage and identify gaps - Reinforce correct behaviours through targeted interventions Example: Instead of one-off training at go-live, introducing quarterly refreshers based on actual usage patterns. #### 3. Continuous Improvement - Maintain a backlog of enhancements - Prioritise improvements based on business impact - Roll out new features in controlled cycles Example: Activating unused ERP modules (e.g. budgeting, asset tracking) in phases to unlock additional value. #### 4. Value Realisation - Define measurable outcomes (e.g. reduced cycle times, improved data accuracy) - Track benefits over time - Report value back to executives Example: Demonstrating that invoice processing time reduced by 40% due to system-driven workflow improvements. #### 5. Governance and Proper Use - Define and enforce standards for system usage - Ensure data integrity and compliance - Prevent regression into manual or inconsistent practices #### 6. Data Quality and Reporting - Ensure data is accurate, complete, and trusted - Build meaningful dashboards that drive decisions - Eliminate shadow reporting outside the ERP #### 7. Enhancement and Feature Rollout - Introduce new system capabilities to the business - Align releases with operational priorities - Ensure adoption of new functionality This function is the difference between: - A system that exists - A system that improves the organisation every quarter If no one is driving these activities, how will your ERP ever move beyond where it is today? ### The practical move executives need to make 1. Separate responsibilities clearly - IT → Maintain and secure the system - Capability Function → Improve how the business uses it 2. Assign executive ownership of value Someone at the executive level must own ERP outcomes—not just system health. 3. Fund post–go-live capability Budget for continuous improvement, not just implementation. 4. Create a structured improvement roadmap Treat ERP like a product: - Quarterly releases - Measurable improvements - Ongoing evolution 5. Hold the organisation accountable to use the system properly No tolerance for shadow processes and uncontrolled workarounds. ### Final perspective ERP does not fail because of poor implementation. It underperforms because of weak ownership after go-live. The organisations that extract value are not those who implemented best. They are the ones who designed how the system would be continuously improved. You have already paid for the system—are you willing to invest in making it actually deliver? --- --- title: "What Is The Purpose Of ERP Dashboards? Beware, Executives!" url: "https://spsingh.me/purpose-of-erp-dashboards/" lang: "en-AU" type: "post" description: "https://youtu.be/UD_4D--uBdA Would you consider buying a Tesla fitted with a vintage car dashboard? Weird question! Isn't it? Any modern car dashboard must make driving easy. The information should be right in front of you and when you need it. Now," last_modified: "2026-04-24T11:33:18+00:00" categories: [Home] tags: [analytics, big data, business insight, dashboard, data, data management, executive dashboard, insight, management, report, reporting] custom_fields: ampforwp-amp-on-off: "default" cos_headline_text: "What Is The Purpose Of ERP Dashboards? Beware, Executives!" cos_seo_score: 0 cos_headline_score: 0 wpar_republish_meta_query: "2026-04-22 21:35:48" --- # What Is The Purpose Of ERP Dashboards? Beware, Executives! https://youtu.be/UD_4D–uBdA ## Would you consider buying a Tesla fitted with a vintage car dashboard? ![auto 2377164 1920 SP Singh Blog](https://spsingh.me/wp-content/uploads/2020/09/auto-2377164_1920-1024x683.jpg) **_Weird question! Isn’t it?_** Any modern car dashboard must make driving easy. The information should be right in front of you and when you need it. **_Now, let me share a bizarre observation!_** Senior Managers of many Small and Medium-size Enterprises operate without Executive [ERP](https://spsingh.me/what-is-erp/) Dashboards. The Executive Dashboard provides real-time visualisation of all business activities. But many Executives still rely on old-fashioned reports. Such reports often supply lagging indicators and historical information. It is equivalent to running a Tesla with a vintage car Dashboard. It is painful to see organisations spend thousands of dollars on Enterprise software. Still, Senior Managers do not have any decent Executive Dashboard. If you are operating without a Dashboard, you must continue reading. ![erp dashboards](https://spsingh.me/wp-content/uploads/2020/09/analysis-3782319_1920-1024x594.jpg) ## Are you underestimating [ERP Dashboards](https://www.inetsoft.com/info/best_erp_dashboard/)? Think again! Executive [ERP](https://spsingh.me/what-is-erp/) Dashboards help you to focus on the things that matter and when they matter the most. You take control with a holistic view of the Business. **The ERP Dashboards helps in:** - **Operational Excellence:** You gain insights on your team’s performance, throughput, and quality. You access your reminder and To-do list. So, there is no need for emails and posted notes. - **Risk Management:** The Dashboard supplies a helicopter view of the Business for executive governance. You can review insights on Operational, Regulatory and Compliance risks. The Dashboard helps to check and control day-to-day activities. It allows you to mitigate risk and manage issues. - **Decision Making:** Dashboard provides data insights. You can visualise trends and forecast. They help you to make informed decisions. - **Continuous improvement: **You improve process and procedures through continuous improvement. The Dashboard is the guiding and evaluation tool. Based on the real-time insights, you can view what works and what does not. You learn, adjust, and continue to improve. **_Enough theory!_** Consider you are the Operations Manager. You manage risks by tracking leading indicators. You are also responsible for the day-to-day administration work. To help you win in your job, the Executive Dashboard is your best friend. The Dashboard will help you to track the live status of all business operations. For example, you check the pending work by reviewing Aging AP Invoices, Customer Complaints and Expense Claims. The drill-down feature helps to review detail for any summary level items. The Reminders and To-Do lists helps you to keep on top of the game. Thus, Dashboard is a powerful tool to consume real-time information with precision. **So, the vital question is why many Executives do not have the much-needed Dashboard?** ## 5 insane reasons Executives do not have a ERP Dashboard - **Lack of digital maturity:** Your organisation may have many standalone systems. The Systems may not (integrate) talk to each other. The data quality is low. Data extraction and presenting information on Dashboard is in the ‘too hard basket’. - **Ignorance:** You may not be aware of the value the Executive Dashboard can offer. You like the old way of receiving reports from your staff. - **Habits are difficult to change:** It is easy to ask staff to supply reports rather than learning the new system. It may be due to learning anxiety, laziness, or ignorance. Anyway, the results of this are not favourable for you and your organisation. - **Your expectations were not loud enough**: During Enterprise software implementation, the focus is always on the technical work. The Project team, work on Reports, Dashboards, Security towards the end of the project. Integration partner (Vendor) train customer staff on the Dashboards, Security, and reporting. Often due to lack of ownership and BAU work Executive Dashboards never gets priority. Executives devise their ways outside the system to fetch the required information. The fact is that if you have not set a clear focus, you may never get a Dashboard. As we say – ‘You get what you ask for’. - **Go-Live rush:** Often project teams do not consider Dashboards as Go-Live critical. After the Go-Live, the team deal with Production issues. Dashboards never get a priority they deserve, as per the above point. There can be many other reasons that are specific to you and your business. So, what can you do about this? ## How to ensure you have an ERP Dashboard that works? - **Educate and convince yourself: **The first step is to understand the purpose of Dashboards. Why you need them and what they can do for you? Find the current issues due to second-hand information you are receiving. Visualise how Dashboard will change the way you operate and increase your effectiveness. - **Decide what you need: **The Dashboard must be custom to your needs. As you only want to see the information that is important to you. The layout and structure must meet your personal preferences. The following points will help you to find your needs: Identify your daily tasks, KPI, trends, and data you track for decision making. - Analyse the dimensions of your role, for example, which team report to you, their deliverables, customer expectations and so on. Based on this, determine which information you like to be on your Dashboard. Name a list of leading and lagging indicators that you want to track - If you responsible for approving invoices, Purchase Orders, Expenses, then, get an actionable dashboard for authorisation. These dashboards can help you review and authorise multiple approval requests at once. - Ensure that you can drill down summary information to view details. - Ensure you have a section for To-Do list, Reminders, and past Notifications. - **Ask for it**: Demand from the responsible team to develop a custom Dashboard for you. Work with the team to provide requirements, Dashboard design and test the solution. Where necessary, seek help from your peers, staff, and IT. If your organisation is implementing Enterprise software, then ensure that the team delivers your Dashboards. Often, the Vendors offer standard Dashboard/reports pack. Check out with the vendor if that is a practical option for you. You can save a lot of time and effort. ## The Bottom line: Dashboards have an immense value to offer. Do not underestimate their importance. Educate yourself, how Dashboards can help you and your organisation. Take necessary steps to get a custom Executive dashboard for yourself. It is vital to take the next step! So, what is the next step for you? It may be talking to your peers; IT Support, Project team or a vendor. Make sure that you do not settle for what you have! You deserve better! All the best! --- --- title: "ERP Project Updates Are Lying to You: A Guide for Sponsors and SteerCo" url: "https://spsingh.me/erp-project-updates/" lang: "en-AU" type: "post" last_modified: "2026-04-24T01:46:43+00:00" categories: [The Sovereign Architect Series, Project Sponsorship] custom_fields: cos_headline_text: "ERP Project Updates Are Lying to You: A Guide for Sponsors and SteerCo" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Project Updates Are Lying to You: A Guide for Sponsors and SteerCo ## ERP Project Updates Look Good. The Program Isn’t. Most ERP Steering Committees leave meetings feeling reassured. Status is “Green”. Risks are “managed”. Milestones are “on track”. That sense of control is often the first signal something is wrong. Because by the time an ERP program visibly fails, the narrative has been stable—and positive—for months. ## What Sponsors Expect Project Sponsors and SteerCo members assume: - Updates reflect reality - Risks are surfaced early - Issues are clearly owned - Vendors are transparent - Project Managers are objective The implicit belief: _“If something was going wrong, we would know.”_ That belief is structurally flawed. ERP programs rarely fail through visible collapse. They drift—quietly—under a layer of professional-looking updates. ## What Actually Happens in the Room Instead of clarity, updates are often shaped to maintain momentum, avoid scrutiny, and protect positions. The result is not lying. It is **managed perception**. Below are the most common patterns. ## 1. The Deflection Loop **What you hear:** - “That’s a good question—we’re still validating with the business.” - “We’ll take that offline.” - “It depends on how Finance wants to handle it.” **What is happening:** The question is not answered. Ownership is diffused. **Live example:** You ask: > “Is payroll configuration aligned to our award interpretation?” Response: > “We’ve had strong engagement with HR and the vendor is confident.” No answer. No ownership. No evidence. **Signal:** If answers move sideways instead of forward, you are not getting truth—you are getting motion. ## 2. The Green Status Illusion **What you hear:** - “Overall status remains Green” - “Minor risks, all under control” - “No major blockers” **What is happening:** Status is being managed as a stakeholder comfort tool—not a delivery signal. **Live example:** - Data migration accuracy: 72% - UAT defect backlog: growing - SMEs unavailable Status: **Green** **Signal:** If “Green” coexists with unresolved fundamentals, the reporting model is broken. ## 3. The Complexity Shield **What you hear:** - “The integration architecture requires further refinement” - “There are some dependencies in the middleware layer” - “It’s a complex configuration scenario” **What is happening:** Complexity is used to discourage challenge. **Live example:** A simple issue: > Supplier invoices are not matching POs correctly Becomes: > “There are multi-layer validation dependencies between procurement and finance modules.” **Signal:** When simple business problems are explained in technical language, clarity is being avoided. ## 4. The Detail Flood **What you see:** - 40-slide decks - Task-level updates - Percent complete everywhere **What is missing:** - Decision clarity - Risk exposure - Outcome alignment **Live example:** You receive: - “Configuration 85% complete” - “Testing 60% complete” But no answer to: > “Will we be ready to pay staff accurately on Day 1?” **Signal:** High detail with low meaning is a deliberate masking pattern. ## 5. The “Happy Story” **What you hear:** - “Strong collaboration across teams” - “Great engagement from stakeholders” - “Positive momentum” **What is happening:** Narrative replaces evidence. **Live example:** Despite: - Rework increasing - SMEs disengaged - Decisions delayed Update focuses on: > “Workshops were well attended and feedback was positive.” **Signal:** If sentiment is high but delivery signals are weak, you are being reassured—not informed. ## 6. The Slippery Answer **What you hear:** - “Yes, that’s being worked on” - “We’re comfortable with where things are” - “It’s progressing as expected” **What is happening:** Answers sound acceptable but contain no commitment. **Live example:** You ask: > “Is the asset register fully reconciled?” Response: > “We’ve made significant progress and are working through remaining items.” Translation: _No, but we are not saying that directly._ **Signal:** If you cannot extract a clear “Yes / No / By When,” you do not have control. ## 7. The Blame Drift **What you hear:** - “The business hasn’t finalised requirements” - “The vendor needs more input” - “Dependencies are causing delays” **What is happening:** Accountability is diluted across parties. **Live example:** Procurement design is incomplete. - Vendor says: “Waiting on business” - Business says: “Waiting on vendor guidance” No owner. No progress. **Signal:** When everyone is involved, no one is accountable. ## Why This Happens This is not incompetence alone. It is structural. - Vendors protect commercial position - Project Managers protect delivery optics - Internal teams avoid escalation - Executives signal preference for “good news” Over time, a system forms where: **Clarity becomes risky. Ambiguity becomes safe.** ## The Real Cost By the time reality surfaces: - Data is not ready - Processes are not aligned - Users are not prepared - Controls are weak And then: - Go-live is delayed, or worse—forced - Confidence collapses - Cost escalates - Blame intensifies Most critically: **The organisation loses trust in the system before it even stabilises.** ## Reframing the Role of SteerCo SteerCo is not there to receive updates. It exists to: - **Interrogate reality** - **Force clarity** - **Anchor accountability** - **Make decisions under uncertainty** The shift required: From: > “Are we on track?” To: > “What is not working—and who owns fixing it?” ## What to Do Next (Practical Control Moves) Most governance frameworks focus on what the project team should do. Start with what **you**, as Sponsor or SteerCo, must change. Because one uncomfortable truth sits underneath all of this: **If you consistently receive polished updates instead of reality, it is often because the environment rewards polish.** ### 1. Create Permission for Bad News Make it explicit: - “We expect to hear what is not working.” - “Early risk is valued more than late surprises.” Then reinforce it in behaviour: - Do not react defensively - Do not penalise escalation - Do not rush to solutions before understanding If people sense that bad news creates discomfort at the top, they will filter it before it reaches you. ### 2. Start with Facts, Not Narratives Reset the structure of updates: Ask for: - What is **proven** (evidence-based) - What is **assumed** - What is **failing or at risk** Before any commentary, sentiment, or storyline. **Example shift:** Instead of: > “Testing is progressing well” Require: > “412 test cases executed, 96 failed, payroll scenarios not yet validated” Facts anchor reality. Narratives can distort it. ### 3. Listen with Intent, Not Comfort In most SteerCo rooms, listening is passive. Updates are heard, not interrogated. Change the posture: - Listen for **gaps**, not just statements - Listen for **what is avoided**, not just what is said - Listen for **ownership clarity**, not activity If something feels unclear, it usually is. ### 4. Challenge Your Own Preference for “Good News” A critical self-check: - Do you move faster when updates are positive? - Do you slow down or disengage when issues are raised? - Do you unconsciously reward confidence over accuracy? If yes, the system adapts to you. **Teams optimise for executive preference.** If you prefer reassurance, you will receive it—at the cost of visibility. ### 5. Demand Direct Answers Every critical question must result in: - Clear answer (Yes / No / Not ready) - Named owner - Defined date Reject: - “In progress” - “Being worked on” - “We are comfortable” Clarity is a discipline, not a by-product. ### 6. Translate Everything to Business Impact Do not accept technical framing in isolation. Force translation: - What does this mean for payroll accuracy? - What does this mean for revenue collection? - What does this mean for service delivery on Day 1? If impact is unclear, the issue is not understood. ### 7. Track Decision Latency Monitor: - Which decisions are pending - How long they have been pending - Why they are not being made Delays signal hidden complexity, avoidance, or misalignment. ### 8. Enforce Single-Point Accountability For every risk, issue, or deliverable: - One accountable owner - Not a group - Not “the team” Diffuse ownership is a primary source of slippage. ### 9. Replace Status Colours with Evidence Remove reliance on: - Green / Amber / Red Ask instead: - What has been validated end-to-end? - What has not been tested in real conditions? - What could fail at go-live? Colour is perception. Evidence is control. ### 10. Introduce the “Clarity Test” At the end of each update, ask: - Can this be explained clearly in 2 minutes? - Do we know what will break next? - Are we hearing reality—or a managed version of it? If clarity is missing, governance has not occurred. ## Bottom Line You do not eliminate “B.S.” by asking better questions alone. You eliminate it by **removing the incentive to provide it**. That starts with: - Openness to uncomfortable truths - Discipline in demanding facts - Willingness to hear what you may not want to hear Because in ERP programs: **The quality of information you receive is a direct reflection of the environment you create.** --- --- title: "ERP as a Layered Operating Architecture" url: "https://spsingh.me/erp-as-a-layered-operating-architecture/" lang: "en-AU" type: "post" description: "ERP as a Layered Operating Architecture: A Technical Interpretation for Executives and Sponsors 1. The Starting Assumption That Creates Structural Risk ERP is commonly initiated as a software implementation—a bounded project to deploy a suite of applications (finance, procurement, HR). That" last_modified: "2026-04-21T13:51:30+00:00" categories: [The Sovereign Architect Series, Architecture] custom_fields: cos_headline_text: "ERP as a Layered Operating Architecture" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP as a Layered Operating Architecture ## ERP as a Layered Operating Architecture: A Technical Interpretation for Executives and Sponsors ### 1. The Starting Assumption That Creates Structural Risk ERP is commonly initiated as a software implementation—a bounded project to deploy a suite of applications (finance, procurement, HR). That framing is incomplete. An ERP program actually establishes a multi-layered operating architecture that determines: - how enterprise data is structured and governed - how transactions are validated and controlled - how end-to-end processes execute across functions - how systems interoperate - how authority, access, and accountability are enforced - how information is surfaced for decision-making Once configured, this architecture becomes the organisation’s system of record and system of control for the next decade or more. ### 2. Why ERP Is Misunderstood ERP is presented through modules and user interfaces: - general ledger, accounts payable/receivable - purchasing, inventory, asset management - payroll and workforce management Executives therefore see: - screens, forms, dashboards - transactions and reports This creates a surface-level understanding of ERP as application functionality. In reality, those applications sit on top of a stack of interdependent layers. The behaviour of the organisation is determined by how those layers are defined and aligned. ## 3. The ERP Layered Model (From Foundation to Experience) The architecture can be expressed as a dependency chain: > **Data → Master Data / Entities → Business Rules → Process Orchestration → Integration → Access Control → Interaction Layer → Experience Layer** Each layer is described below with its technical role and implications. ### 3.1 Data Layer — Transactional and Analytical Foundations **Definition:** The raw datasets captured and persisted by the system, including: - financial transactions (journals, invoices, payments) - asset records and condition data - workforce and payroll data - customer, service, and operational data **Technical characteristics:** - stored in relational or distributed data stores - governed by schemas, constraints, and data models - feeds both operational processing (OLTP) and reporting/analytics (OLAP/BI) **Implication:** Data quality (accuracy, completeness, timeliness) directly determines: - report reliability - audit defensibility - decision integrity Poor data at this layer propagates errors through every higher layer. ### 3.2 Master Data / Entity Definition Layer **Definition:** The canonical definitions of core business objects (“entities”), such as: - customers, ratepayers, vendors - assets, locations, cost centres - items, services, contracts - organisational structures (departments, roles) **Technical characteristics:** - master data models with unique identifiers (keys) - reference data and hierarchies (e.g. chart of accounts, asset classes) - governed via master data management (MDM) processes **Entity Relationships & Constraints:** - foreign keys and referential integrity - business constraints (e.g. one vendor per invoice, asset-to-location mapping) **Implication:** Inconsistent master data leads to: - multiple versions of truth - reconciliation effort across functions - integration mismatches This layer establishes a shared semantic model of the organisation. ### 3.3 Business Rules and Control Logic Layer **Definition:** The embedded logic that governs how transactions are executed and validated. Includes: - validation rules (e.g. mandatory fields, tolerance limits) - approval workflows (delegations of authority) - financial controls (posting rules, period locks) - compliance constraints (tax, audit, regulatory) **Technical characteristics:** - rule engines embedded in ERP transactions - workflow engines for approvals and escalations - configuration-driven logic (not code, in modern systems) **Implication:** This layer operationalises governance by: - enforcing policy at the point of transaction - preventing invalid or non-compliant actions - creating an auditable trail of decisions Weak rule definition results in control leakage and audit risk. ### 3.4 Process Orchestration Layer (Business Processes & Workflows) **Definition:** End-to-end orchestration of activities across organisational units, for example: - procure-to-pay (requisition → approval → purchase order → receipt → invoice → payment) - order-to-cash - hire-to-retire - asset lifecycle management **Technical characteristics:** - workflow orchestration across multiple modules - state transitions and event-driven processing - dependency management across steps and actors **Implication:** This layer determines: - process consistency across departments - cycle times and operational efficiency - visibility of bottlenecks and handoffs If processes are not standardised, ERP becomes a **digital replication of fragmented operations**. ### 3.5 Integration Layer — Enterprise Interoperability **Definition:** Mechanisms by which ERP exchanges data with external systems: - CRM, HRIS, asset systems - GIS, document management, specialist applications **Technical characteristics:** - APIs (REST/SOAP), message queues, ETL pipelines - middleware / integration platforms (iPaaS, ESB) - data synchronisation and event streaming **Implication:** This layer determines whether the enterprise operates: - as a cohesive system of record or - as **loosely coupled silos with duplicated data** Poor integration leads to: - latency and inconsistency - manual reconciliation - brittle system dependencies ### 3.6 Control Layer — Identity, Access, and Accountability **Definition:** The security architecture controlling system access and action authority. Includes: - role-based access control (RBAC) - permissions and segregation of duties (SoD) - authentication and audit logging **Technical characteristics:** - identity management integrated with directory services - access policies mapped to organisational roles - audit trails for all transactions and approvals **Implication:** This layer enforces: - accountability (who did what, when) - risk mitigation (fraud, unauthorised access) - compliance (audit, regulatory requirements) Misconfiguration results in **governance failure despite system capability**. ### 3.7 Interaction Layer — User Interface and Access Channels **Definition:** The presentation and interaction mechanisms through which users engage with ERP: - UI components (forms, dashboards, worklists) - reporting and analytics interfaces - access channels: web/desktop - mobile applications - conversational interfaces (AI/chatbots) - voice-enabled systems **Technical characteristics:** - front-end frameworks, UX design - real-time vs batch data presentation - responsive and role-based interfaces **Implication:** If this layer is poorly designed: - users circumvent the system - adoption declines - data integrity degrades This layer directly influences **behavioural compliance**. ### 3.8 Experience Layer — Role-Based Information Delivery **Definition:** The contextualisation and personalisation of information for different roles: - executive dashboards (aggregated KPIs, risk indicators) - operational views (task lists, transaction queues) - analytical views (trend analysis, forecasting) **Technical characteristics:** - BI/analytics platforms layered on ERP data - role-based access to curated datasets - data visualisation and drill-down capabilities **Implication:** This layer determines whether ERP: - enables **insight and decision-making** or - overwhelms users with unstructured data It is the final step in converting data into **actionable intelligence**. ## 4. System Behaviour as a Function of Layer Alignment These layers form a dependency chain: - Data integrity underpins master data - Master data enables consistent rule application - Rules govern process execution - Processes generate operational outcomes - Integration synchronises the enterprise - Access control enforces accountability - Interaction enables execution - Experience drives decision-making A failure in any layer propagates upward. For example: - weak master data → inconsistent transactions → unreliable reports - poor process design → workarounds → data inconsistency - weak access control → governance breaches ## 5. Why ERP Programs Fail Despite “Successful Implementation” In most organisations: - IT architects the integration layer - Finance configures transactional rules - departments define processes locally - vendors configure system components Each layer is optimised in isolation. There is no **unified executive definition of the target operating model** across layers. The outcome: - system is functionally complete - architecture is internally inconsistent ERP becomes **operationally fragmented despite technical completeness**. ## 6. Executive Implication — ERP as Control Architecture From an executive perspective, ERP must be understood as: - **System of record** → authoritative data source - **System of control** → enforcement of governance - **System of execution** → orchestration of processes - **System of insight** → visibility into performance and risk This aligns directly with executive responsibilities: - Steward resources - Govern their use - Convert them into outcomes ERP is the mechanism that makes this: - visible - controllable - auditable ## 7. Determinant of ERP Success ERP success is not primarily a function of: - vendor capability - feature set - project delivery milestones It is a function of: > **Architectural coherence across all layers** Specifically: - clear master data definitions - aligned business rules and controls - standardised processes - robust integration architecture - enforced access and accountability - usable interfaces - decision-oriented experience design ## 8. Final Principle ERP is a **layered enterprise architecture**, not an application. It embeds: - how data is structured - how decisions are governed - how processes are executed - how the organisation operates If these layers are deliberately designed and aligned, ERP enables: - clarity - control - consistency - confident decision-making If they are not, ERP institutionalises: - inconsistency - ambiguity - operational inefficiency - governance risk ## ERP as a Layered Operating Architecture > ERP is a layered enterprise architecture that transforms data into governed processes and controlled outcomes, enabling an organisation to see, manage, and direct its operations with precision. --- --- title: "Understanding ERP Systems: The Executive Guide to Getting It Right" url: "https://spsingh.me/understanding-erp-systems/" lang: "en-AU" type: "post" description: "This Is Where Most ERP Programs Start Going Wrong Most executives begin an ERP journey thinking they are implementing a system. A platform to modernise.A vendor to manage.A project to deliver. It feels structured. Contained. Logical. But that assumption quietly" last_modified: "2026-04-20T13:29:38+00:00" categories: [The Sovereign Architect Series, Architecture] custom_fields: cos_headline_text: "Understanding ERP Systems: The Executive Guide to Getting It Right" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Understanding ERP Systems: The Executive Guide to Getting It Right ## This Is Where Most ERP Programs Start Going Wrong Most executives begin an ERP journey thinking they are implementing a system. A platform to modernise. A vendor to manage. A project to deliver. It feels structured. Contained. Logical. But that assumption quietly sets the wrong direction from day one. Because ERP is not something you install. It is something that reshapes how your organisation operates. ## It Looks Like Software — So It Gets Treated Like Software Naturally, ERP is framed as: - a finance upgrade - a technology refresh - a reporting improvement - a project with a clear finish line Success, then, becomes simple: - go-live achieved - modules deployed - users trained On paper, that sounds like progress. But this view only captures what is visible—not what actually drives outcomes. And that’s where the gap begins. ## Beneath the System Is an Operating Structure: Understanding ERP Systems What ERP really introduces is a layered structure that defines how your organisation functions: - **Data** — what the organisation knows - **Core definitions** — customers, assets, workforce, services - **Rules** — how transactions are controlled and validated - **Processes** — how work flows across departments - **Integrations** — how systems connect - **Security** — who can act, approve, or access - **User access** — how people interact (desktop, mobile, AI, voice) - **Personalisation** — how information is presented to each role These are not separate components. They form a single system that determines: - how work gets done - how decisions are made - how performance is measured Which means when ERP changes, the organisation changes with it. ## So Why Do Organisations Still Get It Wrong? Because each layer is handled in isolation. - IT focuses on systems - Finance focuses on transactions - Departments focus on their processes - Vendors focus on configuration Everyone is working. But no one is connecting the whole. And without a clear executive definition of “what good looks like,” each part is optimised separately. The result? A system that works technically—but not organisationally. ## The Problem Doesn’t Show Up Immediately At first, everything looks fine: - the project progresses - milestones are met - the system goes live From the outside, it appears successful. But underneath: - data doesn’t align across teams - processes vary by department - controls are inconsistent - users rely on workarounds - reports need validation The organisation starts adjusting itself to the system. Instead of the system supporting the organisation. This is where value begins to erode—quietly. ## The Realisation That Changes Everything ERP is not just a system. It becomes the structure through which your organisation: - sees its operations - governs its resources - connects its departments - and makes decisions In effect, it becomes the **infrastructure of organisational clarity**. When this structure is sound: - decisions are faster - risks are visible earlier - reporting is trusted - operations are consistent When it is not: - confusion is embedded - governance weakens - visibility is lost And once embedded, it is difficult to unwind. ## So Where Should Executives Focus? Not on whether the system is being delivered. But on whether the organisation is being structured correctly through it. This means asking: - Do we know what “good” looks like across the organisation? - Are business leaders owning outcomes—not just IT and vendors? - Are data, processes, and rules aligned across departments? - Will this system allow us to operate consistently? - Can we see and act on reality without interpretation? Because ERP will not fix ambiguity. It will scale it. ## The Decision That Defines the Outcome Every ERP program eventually leads to one of two outcomes: Either: - the organisation gains clarity, control, and confidence Or: - complexity becomes embedded into daily operations The system itself is rarely the deciding factor. The difference lies in how clearly the organisation defines and governs the structure behind it. And that decision is made at the executive level—long before go-live. --- --- title: "AI in Business: The Hidden Risk of Uncontrolled Adoption" url: "https://spsingh.me/ai-in-business/" lang: "en-AU" type: "post" description: "AI Is Not Arriving as a Program—It Is Entering Your Organisation Quietly Most executives expect AI to arrive as a formal initiative—structured, governed, and led from the top. A program will be defined, a roadmap approved, and IT will manage" last_modified: "2026-04-19T13:34:50+00:00" categories: [AI, The Sovereign Architect Series] custom_fields: cos_headline_text: "AI in Business: The Hidden Risk of Uncontrolled Adoption" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # AI in Business: The Hidden Risk of Uncontrolled Adoption ## AI Is Not Arriving as a Program—It Is Entering Your Organisation Quietly Most executives expect AI to arrive as a formal initiative—structured, governed, and led from the top. A program will be defined, a roadmap approved, and IT will manage the rollout. But even before that happens, there is already confusion. Some people see AI as tools like ChatGPT or Copilot—helpful assistants that improve productivity with minimal risk. Others are waiting for something much bigger—superintelligence that will fundamentally reshape the organisation. These two views sit far apart, and there is no shared understanding in between. That is where the risk starts. Because AI is not waiting for a program. It is not arriving as a single, controlled event. It is already entering your organisation—through small, everyday decisions across teams, tools, and vendors. Quietly. Without coordination. You have seen this before. When smartphones first appeared in the workplace, there was no formal strategy. People simply started using apps because they were useful—email, maps, banking. By the time organisations responded, behaviour had already changed. AI is following the same path—only faster, and with far greater impact. **The question is not when AI will arrive. The question is: how much has already entered without you noticing?** ## The Comfortable Assumption That Feels Right—but Isn’t At the surface level, the belief is simple: “We need an AI strategy.” “IT will manage it.” “We will adopt AI when we are ready.” This creates a sense of control. It suggests AI is optional, centralised, and will be introduced deliberately. But this thinking assumes something critical—that adoption will wait for permission. It won’t. AI does not require a capital project. It does not wait for governance structures. It is already embedded in tools your teams are using daily. **If adoption does not wait for your strategy, what exactly is your strategy controlling?** ## AI in Business: What Is Actually Happening Inside Your Organisation Right Now While strategy discussions are forming, reality is moving ahead: A finance analyst uses AI to interpret reports faster. HR drafts policies using AI assistance. Procurement evaluates suppliers using AI tools. Vendors begin embedding AI into ERP, CRM, and business platforms. Staff experiment with tools outside formal approval. Each action is small. Logical. Efficient. But collectively, they create something very different—a fragmented layer of intelligence operating across your organisation without coordination. You have seen this before. Excel became the shadow system of record. Email became the default workflow engine. Shared drives became inconsistent across departments. AI will not repeat this pattern—it will amplify it. **If every team is improving performance independently, who is responsible for the performance of the whole?** ## Why This Is Happening Faster Than You Expect Because AI changes the economics of capability. Previously, capability required effort—projects, funding, approvals, implementation timelines. Now, capability is immediate. Accessible. Often free. This creates three structural shifts: - Adoption becomes decentralised - Usage becomes invisible - Experimentation outpaces governance The organisation moves faster than its own ability to understand what is happening. Not because people are careless—but because the tools are too easy to use. **When capability becomes effortless, what replaces control?** ## The Risk You Will Not See Until It Is Too Late This is not a future risk. It is an emerging one. Over time, you begin to see: - Multiple AI tools solving the same problem differently - Inconsistent outputs influencing decisions - Data exposure risks you did not formally approve - Growing reliance on tools outside your governance - Erosion of trust in systems and reporting The critical shift is subtle. Decisions are no longer made solely by people or systems you control. They are influenced by tools you did not design, approve, or fully understand. And this does not happen overnight. It happens gradually—until control is no longer clear. **If decisions are being shaped by something you cannot see, who is actually in control?** ## The Shift Required: From Technology Thinking to Control Thinking The instinct is to treat AI as a technology question: Which tools should we use? Which platform should we invest in? This is the wrong starting point. AI is not primarily a technology layer. It is a decision-influence layer. The comparison is not IT strategy. It is financial governance. You would never allow: - Different definitions of revenue across departments - Uncontrolled financial rules - Spending without oversight Yet AI is beginning to influence decisions at the same level—without equivalent governance. This requires a shift: From “What tools do we adopt?” To “How is decision-making being influenced—and who governs it?” **If AI is shaping decisions, shouldn’t it be governed like finance—not like software?** ## What You Need to Do—Before Structure Is Replaced by Complexity You do not need a heavy strategy to begin. You need early control signals—simple, deliberate, and visible. Start here: - Assign executive ownership for AI as an organisational capability - Create visibility of where AI is already being used - Define clear boundaries for acceptable use - Anchor AI to your core systems (ERP, CRM) as the source of truth - Establish a small governance group to coordinate—not slow down—adoption This is not about restricting innovation. It is about preventing fragmentation. Because once fragmentation sets in, alignment becomes expensive. **The organisations that win will not be the fastest adopters—they will be the earliest to establish control. Where do you stand today?** --- --- title: "The Hidden Cost of ERP: Why Underutilisation Is Draining Your ROI" url: "https://spsingh.me/the-hidden-cost-of-erp/" lang: "en-AU" type: "post" description: "You didn’t overspend on ERP. You’re just not using what you bought. Most ERP discussions start with cost. Budget. Variance. ROI.That framing is convenient—but it is incomplete. Because the largest cost in ERP is rarely what you spend.It is what" last_modified: "2026-04-18T13:45:39+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Hidden Cost of ERP: Why Underutilisation Is Draining Your ROI" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Hidden Cost of ERP: Why Underutilisation Is Draining Your ROI ## You didn’t overspend on ERP. You’re just not using what you bought. Most ERP discussions start with cost. Budget. Variance. ROI. That framing is convenient—but it is incomplete. Because the largest cost in ERP is rarely what you spend. It is what you fail to use. If the system is live but the organisation is not operating through it, the cost continues every day—quietly, invisibly, compounding. The question is not “Did we deliver ERP?” but “Are we extracting its capability?” ## The common belief: implementation equals value In most organisations, success is defined at go-live: - System delivered - Modules deployed - Users trained - Vendor signed off From the outside, it looks complete. From governance reports, it appears successful. From a budget perspective, it is “done.” So attention shifts elsewhere. The program closes. The business moves on. But this assumption hides a critical gap—because capability is not created at go-live. It is only made available. ## The reality: capability exists, but the organisation operates outside it After go-live, a different pattern emerges: - Staff revert to spreadsheets for control - Decisions are made outside the system - Workflows are partially followed, then bypassed - Data is entered, but not trusted - Automation exists, but manual work continues The ERP becomes a recording tool—not an operating system. What you have is not failure. It is something more subtle: **a partially utilised capability that never compounds.** And this is where the real cost begins. ## Why this happens: ERP is treated as a system, not a capability The root cause is not technical. It is structural. Most executives are never asked to define: - What capability ERP is meant to create - What “good” looks like in operations post go-live - Who owns utilisation of each capability So the organisation defaults to: - System ownership → IT - Process ownership → fragmented - Value ownership → undefined Without clear ownership, utilisation becomes optional. Without utilisation, capability remains dormant. The system works. The organisation does not shift. ## The consequence: The hidden cost of ERP Underutilisation does not show up as a single issue. It spreads. **Financial** - ROI never fully realised - Duplicate effort increases cost base - Benefits remain theoretical **Operational** - Processes remain inconsistent - Data quality deteriorates - Reporting lacks credibility **Strategic** - Forecasting is weak - AI and analytics are not viable - Decision-making remains reactive **Risk** - Compliance gaps increase - Workarounds introduce control failures - Staff frustration drives disengagement Individually, these seem manageable. Collectively, they represent a sustained erosion of organisational performance. And it rarely gets attributed back to ERP. ## The reframe: ERP cost is a utilisation problem, not an investment problem Instead of asking: - “Did we implement ERP successfully?” The more precise question is: - “Are we operating at the level of capability ERP enables?” ERP is not a project outcome. It is an operating capability. The cost you should be concerned about is: **The gap between what ERP can enable and what your organisation actually uses.** That gap is where value is lost. And it grows over time if left unaddressed. ## What to do next: introduce a utilisation governance lens This is not a technology fix. It is an executive discipline. Start with three simple questions: - **Capability** What did we expect ERP to enable across finance, operations, workforce, and assets? - **Utilisation** Where is the organisation still operating outside the system? - **Gap Cost** What is the financial, operational, and risk impact of that gap? Then act structurally: - Assign **business ownership** for each core ERP capability - Establish **post–go-live governance** focused on utilisation - Track **value realisation**, not system performance - Intervene where workflows, data, or adoption are breaking down ERP value is not recovered through upgrades. It is recovered through disciplined use. ## Final point Most organisations believe ERP value is lost during implementation. In reality, it is lost afterwards—quietly, through underutilisation. Which means the opportunity is still in your control. The system is already in place. The capability is already paid for. The only question left is: **are you prepared to operate at the level it enables?** --- --- title: "ERP Journey Actually Begins After Go-Live" url: "https://spsingh.me/erp-journey-actually-begins-after-go-live/" lang: "en-AU" type: "post" description: "Go-Live Is Where Your ERP Journey Actually Begins Let’s pause on a common assumption You are about to go live—or you already have.Naturally, you expect that once the system is live, the heavy lifting is behind you. That expectation is" last_modified: "2026-04-17T13:46:44+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "ERP Journey Actually Begins After Go-Live" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Journey Actually Begins After Go-Live ## Go-Live Is Where Your ERP Journey Actually Begins ### Let’s pause on a common assumption You are about to go live—or you already have. Naturally, you expect that once the system is live, the heavy lifting is behind you. That expectation is reasonable. But it is also where most ERP programs start to lose their value. ### What you are likely expecting At this point, you are probably thinking: - The system has been implemented - The vendor has delivered what was agreed - Your teams will start using it - IT or support will keep things running From your perspective, the organisation should now begin to benefit. This is how most leaders view it. ### What you will start to notice instead In the weeks and months after go-live, small signals begin to appear: - Staff are unsure how to use parts of the system - Processes do not quite work as expected - Reports don’t fully reflect reality - Data starts to look inconsistent - Workarounds quietly return Nothing looks like failure. But nothing feels fully under control either. This is the phase where many organisations begin to drift without realising it. ### Why this happens (and why it is not your fault) What you have been through so far is a **delivery effort**—getting the system in place. But what comes next is different. It is not about delivery. It is about **capability**. Most ERP programs are not designed with this distinction in mind. So once go-live happens: - The project team steps back - The vendor moves on - IT takes over system support But no one is clearly accountable for: - Improving how the business actually uses the system - Fixing process gaps - Strengthening data quality - Driving adoption across departments - Improving integrations between ERP and other systems That gap is subtle—but it is critical. ### What happens if this is left unattended If no one owns this phase, the system will continue to operate—but the organisation will not improve. Over time, you will see: - Inconsistent processes across teams - Declining trust in reports and data - Increased manual effort outside the system - Missed opportunities for efficiency - Questions in leadership meetings that the system cannot confidently answer This is how organisations end up with a working ERP system… but without the clarity and control they expected from it. ### The shift you need to make now At this point, the most important question for you is not about the system. It is about ownership. You need to establish: **Who is responsible for making this system better after go-live?** Not maintaining it. Not supporting it. But improving it—continuously. Because from here, your ERP enters three critical stages: - **Stabilisation** – making sure the system works reliably in real operations - **Standardisation** – aligning how teams use it across the organisation - **Optimisation** – improving processes, data, and insights over time These stages do not happen automatically. They require active leadership, structure, and accountability. ### The simple way to think about it: ERP Journey Actually Begins After Go-Live You have just installed the engine. Now someone needs to: - Tune it - Maintain performance - Improve how it runs - And ensure it delivers what you expected when you approved the investment If that ownership is clear, your ERP becomes a control system for the organisation. If it is not, it becomes another system people work around. ### What you should do next Before anything else, take a step back and ask: - Who owns ERP capability after go-live? - Do they have authority across the business—not just IT? - Are they accountable for improvement, not just stability? If the answer is unclear, that is your first risk—and your first opportunity to correct course. --- --- title: "What Your Steering Committee Is Missing?" url: "https://spsingh.me/what-your-steering-committee-is-missing/" lang: "en-AU" type: "post" description: "Your Steering Committee may be giving you a false sense of control Most CEOs believe that once a Steering Committee is in place, the ERP program is under control.There is structure. Senior leaders are present. Reports are reviewed. From the" last_modified: "2026-04-16T13:50:09+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "What Your Steering Committee Is Missing?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # What Your Steering Committee Is Missing? ### Your Steering Committee may be giving you a false sense of control Most CEOs believe that once a Steering Committee is in place, the ERP program is under control. There is structure. Senior leaders are present. Reports are reviewed. From the outside, it looks disciplined. But this is where many organisations make a critical mistake: **they confuse structure with control.** ### Why this belief holds The logic is sound at a surface level. You bring together your executive team—the people who run the organisation—and expect that collective oversight will guide the program effectively. The assumption is simple: “If the right people are in the room, the right outcomes will follow.” In most business situations, that assumption works. In ERP programs, it often does not. ### What actually happens behind the structure Over time, the Steering Committee begins to drift away from its intended purpose. - Meetings are well-run, but lack real control (**theatre vs reality**) - Information is presented and accepted, not interrogated (**compliance vs challenge**) - Discussions focus on status updates, not decisions (**updates vs decisions**) - Reports remain “green” until issues emerge suddenly (**false confidence**) - Ownership shifts toward IT, while business leaders disengage (**IT-owned, not business-owned**) Consider a common pattern: For months, the program reports steady progress. Minimal concerns. Positive momentum. Then, late in the timeline, costs increase, timelines slip, and confidence drops quickly. To the CEO, it feels sudden. In reality, the signals were always there—just never surfaced or challenged. ### What Your Steering Committee Is Missing? The issue is not commitment or intent. It is a mismatch between **what is expected** and **what capability exists**. Steering Committees are typically made up of experienced executives. But they are **not trained to govern ERP programs**. They are expected to: - Challenge vendors and delivery teams - Interrogate assumptions - Identify early warning signals - Steer organisational change at a systems level In practice, most have never been equipped to do this. As a result: - The right questions are not asked - Critical assumptions go untested - Risks remain buried beneath structured reporting This creates a fundamental gap: **governance exists in form, but not in standard.** ### What this leads to over time This gap does not immediately fail the program. It creates **false confidence first**. - Decisions are delayed or made without depth - Risks accumulate without visibility - Accountability becomes unclear - The business assumes someone else is in control By the time problems become visible, they are no longer manageable—they are structural. The system may still be delivered. But the organisation does not gain the control, visibility, or performance it expected. ### A more accurate way to view ERP governance The issue is not that Steering Committees exist. It is that they are **not operating at the level ERP requires**. ERP governance is not progress tracking. It is **organisational control design in motion**. The role of the Steering Committee is not to observe delivery. It is to actively shape: - how decisions are made - how processes operate - how accountability is enforced across the organisation This requires a different standard of thinking and engagement. ### What a functioning Steering Committee actually does A high-functioning SteerCo shifts from passive oversight to active control: - **Risk is surfaced early and acted on**, not reported late - **Stakeholder alignment is enforced**, not assumed - **Processes and operating models are clarified**, not deferred - **Data ownership is explicit**, not implied - **Roles across project, change, and business are defined**, not blurred - **Customisation is tightly controlled**, protecting long-term simplicity - **Post go-live improvement is planned**, not left to chance In this model, governance is not a meeting. It is a mechanism for shaping organisational behaviour. ### What you should do next If you want your ERP program to deliver real value, three shifts are critical: **1. Define the executive standard clearly** Be explicit about what “good governance” looks like—what must be true, not just what is reported. **2. Reset the Steering Committee mandate** Move from reporting to challenge and decision-making. Every session should resolve a meaningful issue or risk. **3. Close the capability gap at the top** Equip your executives to: - Ask the right questions - Challenge with confidence - Recognise early signals of failure Without this, the structure will remain, but control will not. ### The bottom line ERP programs do not underperform because the Steering Committee is missing. They underperform because: **the standard required to make that committee effective is never clearly defined or applied.** Until that changes, governance will continue to look strong—while outcomes remain inconsistent. --- --- title: "Adapt & Adopt: The assumption that needs to be challenged" url: "https://spsingh.me/adapt-adopt/" lang: "en-AU" type: "post" description: "Adapt & Adopt The assumption that needs to be challenged Most executives believe that once an ERP system goes live, the organisation has done the hard work. The system is in place. People are using it. The project is complete.From" last_modified: "2026-04-15T13:43:48+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Adapt & Adopt: The assumption that needs to be challenged" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Adapt & Adopt: The assumption that needs to be challenged **Adapt & Adopt** ## **The assumption that needs to be challenged** Most executives believe that once an ERP system goes live, the organisation has done the hard work. The system is in place. People are using it. The project is complete. From a distance, it appears that value should now follow. This assumption is where the problem begins. ## **What most organisations believe** The common belief is straightforward: - Implement the ERP using standard functionality - Ask the business to adapt to it - Make a few adjustments where required - Reach go-live - Stabilise briefly and move on The underlying thinking is that **“adopt and adapt” is the objective**. Get the organisation to accept the system, make it workable, and the job is done. On paper, this feels efficient. It minimises disruption and keeps the program controlled. ## **What actually happens in reality** In practice, “adopt and adapt” becomes a **finish line, not a starting point**. The organisation reaches go-live and: - Declares success - Closes the project - Hands ownership to IT - Moves executive attention elsewhere At that moment, something critical is left behind. The system is operational, but the organisation has **not yet transformed**. Processes are only partially aligned. Data is inconsistent. Integrations are functional but not optimised. Users are compliant, not effective. The ERP is live—but its potential is largely untouched. ## **Why this happens** This is not a technology problem. It is a leadership and framing problem. Three forces drive this behaviour: **1. Go-live becomes the proxy for success** It is visible, measurable, and easy to communicate. Executives need closure, and go-live provides it. **2. Fatigue across the organisation** After months of effort, there is a natural desire to stop pushing. “Good enough” feels acceptable. **3. Ownership shifts too early** Once handed to IT, the ERP is treated as a system to maintain, not a capability to evolve. The result is what can be called **“Adopt & Adapt Syndrome”** — The organisation does just enough change to implement the system, but not enough to realise its value. ## **The consequence most leaders underestimate** This is where the real cost sits. By stopping at “adopt and adapt,” organisations: - Lock in inefficient processes inside a new system - Miss visibility into true financial and operational performance - Carry forward data issues that undermine decision-making - Fail to leverage automation and integration opportunities - Erode the business case that justified the investment In simple terms: **You fund transformation but settle for digitisation.** The system works—but the organisation does not materially improve. ## **The reframe that changes everything** “Adopt and adapt” is not the objective. It is simply the **entry point**. A more accurate way to think about ERP is this: - **Go-live is a technical milestone** - **Value is created after go-live** The real journey begins once the system is stable. That journey moves through three stages: - **Stabilisation** – making the system reliable - **Standardisation** – aligning processes across the organisation - **Optimisation** – unlocking efficiency, insight, and strategic advantage Without these stages, ERP remains underutilised infrastructure. With them, it becomes an organisational control system. ## **What you should expect from your IT Manager (and organisation)** If ERP is to deliver its intended value, the conversation needs to shift immediately after go-live. Ask for clarity on the following: **1. Post Go-Live Roadmap** - What is the plan beyond stabilisation? - How are we progressing towards standardisation and optimisation? **2. Process Improvement Mechanism** - How are bottlenecks being identified and removed? - Who owns process redesign? **3. Data and Integration Uplift** - How are we improving data quality over time? - Are integrations enabling insight or just transactions? **4. Targeted Enhancements (Not Preferences)** - What changes are being made for strategic advantage? - What is being deliberately avoided? **5. Governance and Capability** - What structures ensure continuous improvement? - How are users being supported to move from compliance to competence? ## **Final Position** Do not ask whether the organisation has adopted the system. Ask whether the organisation is **evolving because of it**. Because the difference between the two is where the ROI sits. --- --- title: "Why most Steering Committees add no value?" url: "https://spsingh.me/why-most-steering-committees-add-no-value/" lang: "en-AU" type: "post" description: "The Assumption That Quietly Fails Most executives believe that once a Steering Committee (SteerCo) is in place, governance is handled. It feels structured. Meetings are scheduled. Reports are circulated. Senior leaders are present. From the outside, it looks like control." last_modified: "2026-04-14T14:17:58+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Why most Steering Committees add no value?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Why most Steering Committees add no value? ### The Assumption That Quietly Fails Most executives believe that once a Steering Committee (SteerCo) is in place, governance is handled. It feels structured. Meetings are scheduled. Reports are circulated. Senior leaders are present. From the outside, it looks like control. But that assumption is where the problem begins. ### What Most Organisations Believe In many organisations, SteerCo is treated as a checkpoint. A place where the project team presents updates, risks are noted, and progress is acknowledged. Executives attend, listen, and move on. It appears efficient. Minimal disruption. No friction. And that is exactly why it fails. ### What Actually Happens in Reality – Why most Steering Committees add no value The real decisions are not made in the SteerCo. They happen elsewhere—within project teams, vendor discussions, or informal conversations. By the time something reaches the SteerCo, it is already shaped, sometimes even locked in. The meeting becomes theatre. Slides are presented. Language is softened. Issues are carefully framed. No one wants to appear unprepared or responsible for a problem. At the same time, the people in the room are not fully engaged. They rely on summaries. They assume things are under control. Questions are limited. Challenges are rare. Preparation is minimal. So the forum that is meant to steer… observes. ### Why This Happens There is no real accountability tied to the room. If a director is not accountable for outcomes in their area, engagement drops. If decisions do not carry consequences, they become optional. If preparation is not expected, it does not happen. Over time, the role of the SteerCo quietly shifts. From decision-making to advisory. From ownership to observation. From driving outcomes to reviewing progress. And once that shift happens, the value disappears. ### The Hidden Cost Executives Don’t See The impact is not immediate, which makes it dangerous. The project continues. Milestones are reported. Progress appears steady. But underneath, misalignment grows. Decisions are made without full business context. Risks are not confronted early. Trade-offs are not understood properly. The organisation starts adapting to the system instead of shaping it. By the time issues reach the executive level, they are expensive to fix. This is where most ERP programs lose their return on investment—not because of technology, but because governance never truly functioned. ### The Shift That Changes Everything A SteerCo is not a reporting forum. It is a decision forum. Its purpose is not to hear updates. It is to make calls that shape the organisation—priorities, trade-offs, risks, and direction. This requires a different posture from executives. Not attendance, but ownership. Not listening, but questioning. Not reviewing, but deciding. It also requires transparency. If the meeting feels uncomfortable, it is likely working. If issues are exposed early, the organisation has a chance to respond. If leaders are challenged, decisions improve. Control does not come from smooth meetings. It comes from honest ones. ### What Executives Should Do Next Redefine the purpose of the SteerCo. Make it clear that the forum exists to make decisions, not receive updates. Ensure every member has clear accountability tied to their business area. Without ownership, engagement will remain weak. Require preparation. Papers should focus on decisions needed, not just status. If there is nothing to decide, the meeting should not exist. Shift the agenda. Replace long updates with focused decision points—risks, trade-offs, and priorities. Observe where decisions are actually being made today. If they are happening outside the SteerCo, bring them back into the room. A well-functioning SteerCo changes the trajectory of an ERP program. It connects strategy to execution. It surfaces reality early. It forces clarity. Without it, governance becomes a ritual. With it, leadership becomes real. --- --- title: "The Hidden Cost of ERP “Success”" url: "https://spsingh.me/the-hidden-cost-of-erp-success/" lang: "en-AU" type: "post" description: "The Hidden Cost of ERP “Success” Success is not what you think it is Most ERP programs are called successful. They go live.They meet timelines.They stay close to budget. From a governance perspective, everything looks right. But this is the" last_modified: "2026-04-13T14:18:02+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Hidden Cost of ERP “Success”" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Hidden Cost of ERP “Success” ## The Hidden Cost of ERP “Success” ### Success is not what you think it is Most ERP programs are called successful. They go live. They meet timelines. They stay close to budget. From a governance perspective, everything looks right. But this is the assumption worth challenging: **If the project is successful, the business must be better.** That sounds logical. It is also where many organisations misjudge reality. ### The belief: deliver the system, value will follow At the start, the expectation is straightforward. Implement the system, and the organisation improves. - Better visibility - Better control - Better decisions - Less manual effort The thinking is simple: **Install the system → Train users → Close the project → Realise value** So when the system goes live, the organisation expects results to follow naturally. ### The reality: the business adapts, not transforms What actually happens after go-live is very different. There is no dramatic failure. Instead, there is quiet adjustment. - Teams create workarounds to keep things moving - Spreadsheets return to “support” the system - Processes are bypassed when they slow operations - Data is corrected outside the system The system is in place. But the way the organisation operates does not fundamentally change. Instead of the system improving the business, **the business bends to accommodate the system.** And this shift is subtle enough that it is rarely escalated. ### Why this happens: the focus is misplaced This pattern is not accidental. It is driven by how ERP programs are run. **1. Delivery is prioritised over capability** Success is measured at go-live. Once delivered, attention moves on. **2. The business protects continuity** When friction appears, teams prioritise getting work done—even if it means bypassing the system. **3. The system is underutilised** What was implemented as a powerful platform is used in a limited way. A simple analogy: You buy a high-performance system… but operate it at basic capacity. Not because it cannot do more. But because the organisation never fully shifts to using it properly. ### The consequence: silent underperformance This is where the real cost sits. Not in visible failure, but in what quietly accumulates over time. - Increased operational effort - Fragmented processes returning - Delayed or unreliable decision-making - Benefits that never fully materialise From an executive perspective: You funded transformation. But what you receive is **incremental improvement at best.** And because the project is labelled “successful,” this gap often remains unchallenged. ### The reframe: ERP is an operating model shift To close this gap, the definition of success must change. ERP is not a system implementation. It is a shift in how the organisation operates. Success is not: - System live - Users trained - Project closed [Success is – Non Binary](https://spsingh.me/erp-success-is-not-binary/): - Work executed differently - Data trusted without manual intervention - Decisions made earlier and with confidence - Processes standardised and consistently followed In simple terms: **ERP is not about installing a system. It is about changing how the organisation runs.** ### The direction: where executives must focus If value is the objective, the focus must extend beyond go-live. As a sponsor or executive, the next steps are clear. **1. Redefine success** Shift from “project delivered” to “outcomes realised.” **2. Look for hidden signals** - Where are workarounds happening? - Where is manual effort increasing? - Where is trust in the system still low? These indicate value leakage. **3. Drive utilisation, not just adoption** Logging into the system is not success. Using it to its full capability is. **4. Establish business ownership** The project team delivers the system. The business must own how it is used and improved. **5. Treat ERP as ongoing, not complete** Value is realised over time through continuous refinement, not at go-live. ### Final thought A failed ERP is visible. A “successful” ERP that underdelivers is far more dangerous. Because it hides behind completed milestones while the business quietly carries the cost. And unless that assumption is challenged, **the value you expected never fully arrives.** --- --- title: "Before You Invest in AI" url: "https://spsingh.me/before-you-invest-in-ai/" lang: "en-AU" type: "post" description: "Before You Invest in AI, Understand This First Every executive is being asked the same question: “How are we using AI to improve productivity?” It sounds like a technology decision.It is not. It is a decision about how well you understand" last_modified: "2026-04-12T14:00:29+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Before You Invest in AI" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Before You Invest in AI ## Before You Invest in AI, Understand This First Every executive is being asked the same question: **“How are we using AI to improve productivity?”** It sounds like a technology decision. It is not. It is a decision about **how well you understand your own organisation**. And this is where most AI initiatives quietly fail—before they even begin. ## The Promise You Are Being Sold AI agents are positioned as the answer to: - rising costs - workforce constraints - slow decision-making - operational inefficiency From your perspective, the outcome is clear: **Do more with less. Faster. With better control.** That is the expectation. But there is a condition that is rarely explained— **AI can only improve what it can see and interpret.** ## What Is Actually Happening Inside Your Organisation Now consider how work really happens across your business. Not how it is designed. Not how it is reported. But how it actually flows. In most organisations: - work moves across multiple systems and tools - decisions happen in conversations, not workflows - delays occur between teams, not within functions - rework exists but is rarely measured What your reports show is: - structured activity What your organisation does is: - dynamic, fragmented work This gap is where productivity is lost. And more importantly— **This is where AI either succeeds or fails.** ## Why This Matters to You If AI is introduced without understanding this reality: - it automates isolated tasks - it optimises parts, not the whole - it improves outputs without fixing underlying flow - it creates a perception of progress without structural change You may see: - faster task execution - improved reporting But still experience: - delays in delivery - ongoing bottlenecks - dependency on key individuals - inconsistent outcomes From your perspective: **You invest in AI, but the organisation does not fundamentally improve.** ## The Critical Shift This is the shift that changes outcomes: AI is not just an automation tool. It is both: - a **visibility engine** - and a **performance multiplier** It can: - analyse how work actually flows - identify bottlenecks and delays - highlight rework and inefficiencies - surface patterns that are not visible to leadership But only if it is applied with intent. So the real question is not: **“Where can we use AI?”** It is: **“How do we use AI to understand and improve how our organisation actually works?”** ## What High-Performing Organisations Do Differently They do not start with automation. They start with **visibility**. They use a combination of: - operational data - system activity - communication patterns - process signals Increasingly, they use AI itself to: - map workflows across systems and teams - identify where work slows down - detect where decisions depend on individuals - reveal hidden inefficiencies This creates a clear picture of reality. Once this is visible: **Leadership can act with precision, not assumption.** ## Where Systems Fit (Without Overcomplicating It) Enterprise systems such as ERP and CRM remain critical. They provide: - structure - consistency - traceability But they represent only part of the picture. Work also exists: - between systems - across teams - within decisions and interactions The objective is not to rely on systems alone. It is to create an **observable operating model**, where: - structured work is captured - unstructured work is understood - flow across the organisation is visible ## What This Means for You Before committing to AI at scale, you need clarity on: ### 1. Visibility Do you understand how work actually flows across the organisation? ### 2. Flow Where are delays, bottlenecks, and rework occurring? ### 3. Dependency Where does the organisation rely on individuals rather than systems or processes? If these are unclear: **AI will deliver partial value at best.** ## Where AI Actually Delivers Value Once visibility is established, AI becomes highly effective. It can: - remove repetitive effort - assist and augment decision-making - predict issues before they occur - automate stable, repeatable processes At this stage, outcomes change: - bottlenecks reduce - execution accelerates - decisions improve - operational risk decreases From your perspective: **You move from reacting to problems → to proactively managing performance.** ## The Risk of Skipping This Step Many organisations move directly to automation. It signals progress. It creates momentum. But in reality, they are: - automating inefficiencies - scaling inconsistencies - embedding suboptimal ways of working The cost is: - reduced ROI - transformation fatigue - erosion of trust in future initiatives ## Where to Begin: A Practical Approach The starting point is not automation. It is **clarity through visibility**. This requires a structured way to understand: - how work actually flows - where constraints exist - how systems and teams interact - where effort is being lost AI can play a role here— not just as an automation tool, but as a **discovery and insight engine**. ## Introducing the Bhani Blueprint The Bhani Blueprint is designed to provide this clarity. It combines: - structured analysis of processes and systems - executive-level understanding of operating models - and the use of AI-driven insights to reveal how work actually happens It is not a technology review. It is a **clarity and decision framework for executives**. It answers: - how work flows across the organisation - where bottlenecks and inefficiencies exist - how systems, teams, and decisions interact - where improvement will have the highest impact - where AI should be applied—and where it should not ## Why This Matters Before AI Without this: - AI initiatives are based on assumptions - automation targets the wrong areas - investments deliver fragmented outcomes With this: - you gain a clear view of operational reality - AI is applied with precision - investments are aligned to measurable outcomes In simple terms: **You move from experimenting with AI → to deploying AI with intent and confidence.** ## What You Gain as an Executive The outcome is not just insight. It is control. You gain: - visibility across how your organisation operates - understanding of constraints limiting performance - clarity on where effort is being lost - a structured roadmap for improvement - confidence in where AI will deliver value This enables: - faster and better decisions - alignment across leadership - focused and effective transformation ## How It Connects Back to AI Once clarity is established: - Workflows are understood and simplified - Systems are aligned to support reality - AI is introduced in targeted, high-impact areas At this point, AI becomes: - precise - measurable - scalable ## The Strategic Advantage Most organisations approach AI as a technology initiative. Few approach it as a **visibility and control strategy**. This is the difference. By starting with clarity, supported by AI-driven insight, you are not just adopting AI— **You are building an organisation that can continuously understand, improve, and scale itself.** ## The Bottom Line AI does not transform organisations on its own. **Clarity does.** AI enables that clarity—and accelerates what follows. So the real advantage is not in adopting AI first. It is in using AI, alongside structured frameworks like the Bhani Blueprint, to understand your organisation deeply— and then improving it with precision. Only then does AI deliver what has been promised. And only then does it deliver it at scale. --- --- title: "ERP Implementations — Why Sponsors Lose Value" url: "https://spsingh.me/erp-implementations-why-sponsors-lose-value/" lang: "en-AU" type: "post" description: "ERP Implementations — Why Sponsors Lose Value (And How to Stay in Control) If this is your first ERP implementation, think of it like building a house. At the beginning, everything is clear: You know what you want You agree" last_modified: "2026-04-11T13:17:45+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "ERP Implementations — Why Sponsors Lose Value" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Implementations — Why Sponsors Lose Value ## ERP Implementations — Why Sponsors Lose Value (And How to Stay in Control) If this is your first ERP implementation, think of it like building a house. At the beginning, everything is clear: - You know what you want - You agree on cost and timeline - You trust the builder But as the build progresses, something subtle happens. The builder is busy. Work is happening. Money is being spent. Yet the house slowly starts to look different from what you expected. At some point, a thought appears: > “We’ve come too far to change now… let’s just finish it.” That moment is where most ERP implementations begin to lose value. ## What Is Really Happening It does not feel like failure. In fact, everything looks active: - Meetings are happening - Work is progressing - Reports are being shared But underneath: > Effort continues, while value quietly reduces. And because the project is still moving, it is easy to miss. Which leads to the next question: ## Why Does This Happen? It is not one mistake. It is a gradual shift—from both sides. ### From Your Side (Sponsor Reality) You have already invested: - Time - Budget - Attention So naturally: - You don’t want that investment to feel wasted - Pushing harder feels exhausting - Other priorities take over So you start making small decisions: - “This is acceptable” - “We’ll deal with it later” Each decision feels minor. But together, they move the outcome away from what you originally approved. At the same time, something else is happening. ### From the Vendor Side (What You Don’t See Clearly) While you are easing pressure, the vendor may also be shifting: - Your project may no longer be their top priority - They may not be capable of solving your specific business problems - Their focus moves to **finishing the work**, not improving your business - They rely on you not pushing too hard - Difficult issues are delayed with “we’ll fix it later” Individually, none of this feels critical. But together, it creates a quiet alignment. ## What This Creates Without anyone explicitly deciding it: - You reduce pressure - They reduce effort on outcomes - Work continues - Value does not improve And because nothing has “failed,” it feels acceptable. Until one day, you realise: > You are about to go live with a system that works… but does not deliver what you expected. The question then becomes: ## Could You Have Seen This Earlier? Yes. The signals appear early—but are easy to ignore. ### Signs You Will See - Progress is reported, but benefits are unclear - Conversations move from outcomes → go-live - “We’ll fix it after go-live” becomes common - Your team feels busy, but not confident - The vendor explains limitations instead of solving problems Each signal on its own feels manageable. But together, they point to one thing: > The project is drifting away from value. Which brings you to the most important shift. ## What Is Your Role as a Sponsor? It is not to keep the project moving. It is to: > Protect the value of the investment. If you do not actively protect it, the project will naturally optimise for completion. So the question becomes: ## What Should You Do Differently? ### 1. Keep Coming Back to Value At every stage, ask: - What has improved in the business? - What are we actually getting? Because if you stop asking, value stops being delivered. ### 2. Do Not Accept Work Without Results If something does not meet your need: - Do not approve it - Do not defer it Because every “temporary compromise” becomes permanent later. ### 3. Fix Problems While They Are Small If something feels off: - Pause - Review - Reset Because problems are cheapest to fix early—and most expensive to ignore. ### 4. Stay in Control of Decisions The vendor builds the system. But: > You decide how your organisation should work. If you give that away, you lose control of the outcome. ### 5. Keep the Option to Change Direction You should always feel: - “We can adjust this if needed” If that option disappears, the risk has already materialised. ### 6. Watch the Right Signals Focus on: - Are processes improving? - Is work becoming easier? - Are errors reducing? Ignore: - % complete - Hours spent Because activity can hide lack of progress. ### 7. Act Early, Not Late If value is not coming through: - Reset the approach - Re-scope - Change vendor if required Because waiting does not fix drift—it locks it in. ## What Happens If You Do This Well You start to notice a different trajectory: - The system reflects how your business actually works - Your team gains confidence, not frustration - Decisions are clearer and faster - The benefits you approved start to appear Which leads to the real outcome: > You realise the ROI you expected. ## What Happens If You Don’t The opposite is gradual, but predictable: - You go live with compromises - Workarounds become normal - Benefits are delayed or never realised - The organisation carries the cost for years And the hardest part: > It all looks like success on paper. ## What You Need Around You Because this drift is hard to see from inside the project, you need independent control. That is where: - **Project Assurance** provides ongoing, objective checks on whether value is being delivered - **ERP Control Tower™** gives you visibility, early warning signals, and structured intervention Together, they ensure: > You see the problem early enough to fix it. ## Final Thought The project will keep moving, with or without value. > If you do not actively protect value, the project will settle for completion. And as a sponsor, your real advantage is this: > You control whether the project continues as-is — or changes direction before value is lost. --- --- title: "Feeling stuck is frustrating" url: "https://spsingh.me/feeling-stuck-is-frustrating/" lang: "en-AU" type: "post" description: "Feeling stuck is frustrating. You think harder, yet clarity does not come. Instead, you fall into rabbit holes—spending time, energy, and effort without progress. The frustration compounds. Given a little time, a second layer appears. You realise this is not" last_modified: "2026-04-10T14:06:30+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Feeling stuck is frustrating" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Feeling stuck is frustrating Feeling stuck is frustrating. You think harder, yet clarity does not come. Instead, you fall into rabbit holes—spending time, energy, and effort without progress. The frustration compounds. Given a little time, a second layer appears. You realise this is not new. You have been here before. That recognition creates agitation—_why do I keep getting stuck in the same situations?_ This is the real problem: when we are stuck, we often cannot see the problem clearly. When you reach that point, a few interventions consistently help: - **Speak to someone in a similar situation** Seeing others struggle in comparable ways reduces isolation. It does not solve the problem, but it stabilises your state. - **Speak to someone who can diagnose the problem** The right perspective can expose what you cannot see. Often, a simple story or pattern from their experience creates clarity and restores momentum. - **Speak to someone who solves this problem professionally** Specialists compress years of trial and error. If you are committed, they can help you move faster than you would alone. The underlying dynamic is structural. Feeling stuck is usually a signal that a **constraint** exists in your system. Until that constraint is identified and addressed, effort alone will not create progress. After the initial frustration, the shift is simple but difficult: look outward, engage with trusted people, and focus on resolving the constraint. Where most people fail is in avoidance. They numb the discomfort with distractions, create false narratives, or convince themselves the problem does not exist. That delays progress. A better approach is to tolerate the discomfort, confront the constraint directly, and resolve it. That is what allows the next step to emerge. --- --- title: "The Myth of Go-Live Success" url: "https://spsingh.me/the-myth-of-go-live-success/" lang: "en-AU" type: "post" description: "Go-Live Success Why most ERP programs fail after they go live Executives often believe that once an ERP system goes live, the hard part is over. It is not. Go-Live is not success. It is exposure. It exposes weak processes, unclear ownership," last_modified: "2026-04-24T05:29:39+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Myth of Go-Live Success" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Myth of Go-Live Success ### Go-Live Success **Why most ERP programs fail _after_ they go live** Executives often believe that once an ERP system goes live, the hard part is over. It is not. Go-Live is not success. It is exposure. It exposes weak processes, unclear ownership, poor data, and gaps in capability. This is where many organisations quietly start to lose value—despite having “delivered the project.” What actually determines success happens _after_ Go-Live. ## The Real Journey: Three Stages After Go-Live Most organisations do not fail because of technology. They fail because they do not understand what comes next. ![Steps for post-launch system optimization](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-20-133114.jpg) ### 1. Stabilise – “Does the system actually work?” Immediately after Go-Live, the organisation enters a fragile phase. - Issues surface across finance, payroll, procurement - Data inconsistencies start appearing - Users lose confidence quickly - Workarounds begin to creep back in At this stage: - The project team is still heavily involved - The focus is on fixing, validating, and building trust **Reality check:** If stabilisation is weak, everything that follows collapses. Many organisations rush this stage or declare success too early. That is where long-term damage begins. ### 2. Embed – “Is the business actually using it properly?” Once the system is stable, the real shift must happen. Ownership moves from the project team to the business. - Process owners must take accountability - Teams must stop reverting to old habits - Data discipline must become part of daily operations - Training must continue—not stop This is where most organisations fail silently. The system is “live,” but: - People use it inconsistently - Processes vary across departments - Reporting cannot be trusted **Reality check:** If the system is not embedded, it becomes an expensive reporting tool—not an operational backbone. ### 3. Optimise – “Are we actually getting value?” Only a small number of organisations reach this stage properly. Here, ERP becomes a strategic asset: - Automation replaces manual effort - Real-time insights drive decisions - Cross-department integration improves coordination - Continuous improvement becomes standard practice This is where ROI is realised. But optimisation is not automatic. It requires intent, governance, and leadership focus. **Reality check:** Without deliberate optimisation, ERP remains underutilised for years. ## The Core Myth (Broken) **Myth:** “If the system is live, the project is successful.” **Reality:** Success is determined by how well the organisation stabilises, embeds, and optimises the system. Go-Live is simply the starting line. ## Why Executives Must Pay Attention At each stage, accountability shifts: | Stage | Who Leads | What Matters Most | | --- | --- | --- | | Stabilise | Project Team | Fix issues, build trust | | Embed | Business Leaders | Ownership, consistency, adoption | | Optimise | Executive Leadership | Value, performance, evolution | If leadership does not step in at the right time, the system drifts. And drift is expensive. ## The Question Most Organisations Avoid After Go-Live, ask this: - Are we stabilised—or just coping? - Are we embedded—or just using parts of the system? - Are we optimising—or just maintaining? Most organisations cannot answer this clearly. ## The Opportunity The organisations that get this right do one thing differently: They treat ERP not as a project… but as an evolving organisational capability. If this resonates, the next step is not more reporting. It is clarity: - Where are you across these stages? - Where is value leaking? - What needs to shift now? Because the real ERP story begins after Go-Live—not before. --- --- title: "Open letter from the CEO to Directors" url: "https://spsingh.me/open-letter-from-the-ceo-to-directors/" lang: "en-AU" type: "post" description: "Here is an open letter from the CEO to Directors. If the content resonates, use it for your messaging to your Directors and Executives: Subject: ERP Program – Executive Expectations and Responsibilities Dear Directors, As we prepare to commence our" last_modified: "2026-04-08T14:08:44+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Open letter from the CEO to Directors" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Open letter from the CEO to Directors Here is an open letter from the CEO to Directors. If the content resonates, use it for your messaging to your Directors and Executives: **Subject: ERP Program – Executive Expectations and Responsibilities** Dear Directors, As we prepare to commence our ERP program, I want to be clear on one point: this is not a technology initiative. It is an organisational capability that will define how we operate going forward. The ERP system will become our system of record—providing visibility across finances, assets, workforce, and service performance. Decisions will increasingly rely on data from the system, not spreadsheets or manual reporting. The purpose is to improve accountability, transparency, and efficiency across the organisation. This program represents a transformation in how we work. It will change how departments operate, require redesign of business processes, and necessitate the discontinuation of some existing practices. This is not owned by IT alone. It is owned by the organisation, and leadership sits with the executive. Each of you is accountable for ensuring ERP works within your directorate. This includes defining how your processes should operate, ensuring data integrity, supporting staff adoption, and using the system to manage your operations. Success will depend on your active engagement, not delegation to project teams. You should expect increased process discipline, stronger financial and procurement controls, improved visibility of commitments and performance, greater transparency of operational data, and reduced reliance on manual workarounds. Our objective is consistent and reliable information across the organisation. The governance model will be clear: - I will act as Executive Sponsor - The Director Corporate Services will lead platform implementation - You will own business process and operational outcomes - A Steering Committee will oversee progress and key decisions Your participation is required. This includes nominating subject matter experts, attending design workshops, reviewing and approving future processes, supporting testing and implementation, and leading change within your teams. We will consider this program successful when financial and operational information is reliable, assets and capital programs are accurately tracked, performance is measurable, decisions are data-driven, and reporting is consistent and defensible. At that point, you should be able to run your departments using the system. This is a shared leadership responsibility. ERP will only succeed if the executive team leads it collectively and ensures adoption across the organisation. ERP is the infrastructure that will allow us to see reality clearly, govern resources properly, and deliver services effectively. Its success will depend on executive leadership, not technology delivery. Regards, CEO _Reference: ERP Control Tower_ --- --- title: "Why ERP Initiatives Underperform" url: "https://spsingh.me/why-erp-initiatives-underperform/" lang: "en-AU" type: "post" description: "Why ERP Initiatives Underperform — Starting at the Root Cause ERP initiatives do not fail because of technology.They underperform because of a more fundamental issue: A lack of understanding of what ERP actually is—and what it demands from the organisation." last_modified: "2026-04-20T06:11:48+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Why ERP Initiatives Underperform" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Why ERP Initiatives Underperform ## Why ERP Initiatives Underperform — Starting at the Root Cause ERP initiatives do not fail because of technology. They underperform because of a more fundamental issue: > **A lack of understanding of what ERP actually is—and what it demands from the organisation.** Everything that follows stems from this. ![Cycle of ERP Underperformance ](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-20-135838.jpg) ## 1. Lack of Understanding: ERP Is Misclassified from the Start Most organisations begin with an incomplete mental model. ERP is seen as: - A system replacement - A finance upgrade - An IT-led initiative Instead of what it truly is: - A design of how the organisation operates - A control system for financial, operational, and service performance - A foundation for decision-making across the enterprise Because this is not fully understood: - The scope is framed incorrectly - The effort is underestimated - The ownership is misplaced This initial misclassification shapes every downstream decision. ## 2. ERP Becomes an IT Priority, Not an Executive One Once ERP is misunderstood, it is naturally delegated. It moves from: - Executive ownership To: - IT and project teams This creates a structural shift: - Executives stay informed—but not deeply engaged - Strategic intent is not actively governed - Trade-offs are made without enterprise-wide visibility ERP continues to progress—but without executive gravity. Over time, this leads to: - Fragmented decision-making - Local optimisation over enterprise design - Reduced accountability at the top ## 3. The Strategic Link Is Missing Because ERP is not understood as a strategic system, it is not properly linked to: - Business strategy - Service delivery model - Business architecture - Systems architecture Instead, implementation focuses on: - Requirements gathering - Configuration - Module delivery What is missing is the question: > “How should this organisation fundamentally operate—and how will ERP enforce that?” Without this: - The system reflects existing inconsistencies - Inefficiencies are digitised instead of removed - Variability is preserved instead of standardised ## 4. The Effort Required Is Underestimated When ERP is treated as a system project, critical components are undervalued: - Change management - Data ownership and migration - Process standardisation - Training and behavioural adoption - Governance discipline These are not side activities. They are the core of ERP success. When underestimated: - The system is delivered - The organisation is not ready This results in: - Workarounds - Low adoption - Continued reliance on manual processes ## 5. The Decision Gap Emerges At the executive level: - Strategy is defined - Outcomes are agreed At the delivery level: - Daily configuration decisions are made - Trade-offs are accepted - Constraints are worked around Between these layers, a gap forms. Over time: - Decisions drift away from strategic intent - Small compromises accumulate - The system evolves differently than planned No single decision causes failure. But collectively: - The design integrity is lost This gap also creates: - Limited visibility for executives - Plausible deniability - Difficulty assigning accountability ## 6. ERP Is Measured as a Project, Not a Capability Because of the initial misunderstanding, success is measured using: - Time - Budget - Go-live status These metrics answer: > “Did we deliver the system?” But not: > “Did we improve how the organisation performs?” As a result: - ERP can be declared successful - While operational performance remains unchanged Success becomes a **narrative shaped by delivery constraints**, not outcomes. ## 7. Underperformance Becomes Normalised As challenges emerge: - Expectations are adjusted - Trade-offs are rationalised - Outcomes are reframed Not intentionally—but structurally. Because: - Too much has been invested - Reversing course is difficult - Accountability is diffused The organisation settles into: > _“This is acceptable given the circumstances.”_ At this point: - Underperformance is embedded - Improvement becomes incremental, not structural ## 8. What ERP Should Actually Deliver ![ERP Drives Organizational Success](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-20-141012-1024x563.jpg) When properly understood and governed, ERP enables: ### Organisational Clarity - Trusted, real-time data - Single source of truth ### Control - Visibility of commitments before spend - Early identification of risk ### Consistency - Standardised processes across functions - Reduced reliance on individuals ### Decision Capability - Faster, more confident executive decisions - Alignment between strategy and operations This is not a system outcome. It is a **governance and capability outcome**. ## 9. The Structural Truth ERP underperformance is not caused by: - The vendor - The software - The project team It is caused by: > **The organisation not being structured to understand, govern, and absorb ERP as a capability** At its core: - Executive standards are unclear - Ownership is fragmented - Decisions are not aligned to intent This aligns directly with the deeper pattern: > ERP underperformance is driven by **Executive Standard Ambiguity**, not execution failure ## 10. Direction for Executives ![Achieving ERP Success](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-20-140123.jpg) ### 1. Reframe ERP Immediately Treat ERP as: - An organisational control system - A capability platform Not: - A technology project ### 2. Establish Executive Ownership - ERP must sit at CEO and executive level - Not delegated as an IT responsibility ### 3. Define the Standard Explicitly Clarify: - What “good” looks like for data, processes, and reporting - What cannot be compromised Without this: - The organisation defaults to inconsistency ### 4. Close the Decision Gap - Elevate critical design decisions - Make trade-offs visible - Ensure alignment between strategy and execution ### 5. Invest in Capability, Not Just Delivery - Build internal ownership of processes and data - Strengthen governance structures - Treat post-go-live as the beginning, not the end ## Final Position ERP does not fail because organisations make poor decisions. It underperforms because: > **They do not fully understand the nature of the system they are implementing** Until that understanding shifts: - The same patterns will repeat - Across systems, vendors, and projects The leverage point is not technology. It is **how the organisation thinks, governs, and defines its standards**. --- --- title: "Creativity Is Not a Gift!" url: "https://spsingh.me/creativity-is-not-a-gift/" lang: "en-AU" type: "post" description: "Creativity Is Not a Gift. It Is a System Leaders Can Build. Most leaders treat creativity as something unpredictable.A spark. A moment. A rare talent that a few people possess. That belief is costly. Because creativity is not random.It is" last_modified: "2026-04-20T06:42:49+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Creativity Is Not a Gift!" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Creativity Is Not a Gift! ## Creativity Is Not a Gift. It Is a System Leaders Can Build. Most leaders treat creativity as something unpredictable. A spark. A moment. A rare talent that a few people possess. That belief is costly. Because creativity is not random. It is the outcome of a system. A simple way to understand it: **Creativity = ((Conventional Practice + Taking Chance + Learning) × Volume) × Luck** This is not a mathematical truth. It is a practical model that explains how creativity actually emerges inside organisations. ## Why Creativity Feels Rare In most organisations, creativity appears scarce because: - Work is optimised for efficiency, not exploration - People are rewarded for being right, not for trying - Volume of attempts is low - Learning loops are weak or ignored So when a good idea appears, it feels like luck. In reality, it is the result of many invisible attempts behind it. ## Breaking Down the Formula ![Formula Components](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-20-143318.jpg) ### 1. Conventional Practice — The Foundation Creativity does not start with new ideas. It starts with understanding what already works. - Established processes - Proven methods - Industry patterns Without this, teams produce noise, not creativity. In ERP and transformation programs, this is your: - standard processes - governance structures - baseline system design This is discipline. Not limitation. ### 2. Taking Chance — The Deviation Creativity requires deviation from the norm. - Trying a different process flow - Challenging a requirement - Testing an unconventional approach Without this, organisations optimise the past instead of creating the future. Most teams avoid this because: - risk is penalised - failure is visible Leaders must change this dynamic. ### 3. Learning — The Multiplier of Intelligence Attempts alone are not enough. If the organisation does not learn: - mistakes repeat - insights are lost - effort does not compound Learning converts activity into capability. In practice: - post-implementation reviews - feedback loops - capturing what worked and what did not This is where most organisations are weak. ### 4. Volume — The Hidden Lever This is where creativity actually emerges. One attempt rarely produces a breakthrough. Fifty attempts might. Volume increases: - pattern recognition - probability of success - speed of improvement Yet most organisations: - run one initiative - expect perfect outcomes - hesitate to try again This is why creativity appears rare. ### 5. Luck — The Amplifier, Not the Driver Luck matters. - timing - external conditions - unexpected connections But luck does not create creativity. It amplifies it. If there is no volume, no experimentation, no learning — luck has nothing to work with. Leaders often overestimate luck and underestimate system design. ## What This Means for Leaders Creativity is not something you wait for. It is something you design for. Your role is not to demand better ideas. Your role is to create the conditions where ideas can emerge. ## A Practical Leadership Model ![Leadership Model Shifts](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-20-144159-1024x487.jpg) To make creativity more achievable, focus on four shifts: ### 1. Increase Volume of Thoughtful Attempts - Encourage more pilots, not bigger projects - Reduce the cost of trying ### 2. Normalise Intelligent Risk - Separate failure from incompetence - Reward well-reasoned experimentation ### 3. Build Learning Loops - Capture insights consistently - Make learning visible across teams ### 4. Anchor in Strong Practice - Maintain standards and discipline - Use constraints to guide creativity, not restrict it ## The Reality Leaders Must Accept There are no shortcuts to creativity. There is only: - consistent effort - repeated attempts - structured learning And over time, something changes. What once felt difficult becomes natural. What once felt random becomes predictable. ## The Reframe Creativity is more achievable than most organisations believe. Not because it is easy. But because it is systematic. When leaders commit to: - practice - experimentation - learning - and volume They increase the surface area for luck to act. And when that happens, creativity stops being an accident. It becomes an outcome. ## Final Thought If creativity feels absent in your organisation, do not ask: “Why are we not creative?” Ask instead: “Have we built the system that allows creativity to emerge?” --- --- title: "CEO: How Successful ERP Implementation look like?" url: "https://spsingh.me/how-successful-erp-implementation-look-like/" lang: "en-AU" type: "post" description: "How Successful ERP Implementation look like? What a properly configured, implemented, and embedded ERP actually does A mature ERP is not a system upgrade. It is an organisational control system—the difference between managing fragments and steering the whole enterprise. 1. The" last_modified: "2026-04-29T03:09:55+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "CEO: How Successful ERP Implementation look like?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # CEO: How Successful ERP Implementation look like? ### How Successful ERP Implementation look like? What a properly configured, implemented, and embedded ERP actually does A mature ERP is not a system upgrade. It is an organisational control system—the difference between managing fragments and steering the whole enterprise. ![Key Indicators of Successful ERP Implementation](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-29-110644-1024x821.jpg) ## 1. The Shift in What You See Without ERP, a CEO sees reports. With ERP, a CEO sees the organisation in motion. **Example (Local Government context):** - Instead of waiting for month-end finance packs, you see **live financial position**: Current cash vs committed spend - Budget burn across departments - Emerging overruns before they occur - Instead of siloed capital updates, you see: All capital projects across directorates - Delays, cost drift, and delivery risk in one view - Instead of HR summaries, you see: Vacancy exposure by function - Overtime pressure - Workforce cost trends impacting budget - Instead of reacting to issues, you see: Procurement commitments before invoices hit - Asset failures before they become community issues - Compliance flags before audit findings This is not more data. It is **connected** **visibility**. ## 2. The Shift in How You Decide Most CEOs spend time **validating numbers**: - “Are these figures correct?” - “Why does Finance say one thing and Operations another?” A well-embedded ERP removes this friction. You move to steering priorities: - **Before Council meeting**: You already know where risks sit - You already understand budget pressures - You are not surprised - **During decision-making**: You act earlier (weeks, not months) - You decide with confidence, not interpretation - **Across the organisation**: Everyone is working off the same version of reality - Less narrative, more evidence **Example:** Instead of debating whether a capital project is “on track,” you see: - % completion vs budget - committed vs actual spend - delivery risk indicators The conversation shifts from “What is happening?” to “What do we do about it?” ## 3. The Shift in Control Most organisations operate on personality-based control: - Strong individuals hold knowledge - Interpretation drives decisions - When people leave, clarity disappears ERP enables institutional control: - Decisions are grounded in systemic visibility - Accountability is tied to transparent metrics - Performance is observable, not arguable **Example:** - Procurement cannot bypass controls because commitments are visible - Asset risks cannot be hidden because backlog is quantified - Budget misalignment is visible against the Strategic Community Plan This reduces reliance on: - individual capability - internal politics - narrative management ## 4. The Mandate-Level Impact When ERP is done properly, the impact is not operational—it is strategic: ### Financial Sustainability - Early visibility of cost pressures - Reduced leakage through procurement and inefficiencies ### Political & Audit Risk Reduction - Fewer surprises at Council - Strong audit trails and compliance visibility ### Strategic Execution - Alignment between strategy, budget, and delivery - Capital and operational priorities stay connected ### Public Trust - Reporting becomes credible - Numbers are consistent and explainable ### Institutional Stability - Less disruption from leadership changes - Continuity of decision-making quality ![Mandate-Level Impact on Organization](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-13-153416-1024x568.jpg) ## 5. The Reframe for CEOs ERP is often positioned as: - an IT project - a finance system - a back-office upgrade This is incorrect. **ERP is the mechanism through which you:** - see the organisation clearly - act earlier - reduce risk - execute strategy with precision ## 6. The Bottom Line A well-implemented ERP does one thing exceptionally well: > It removes ambiguity from leadership. And when ambiguity is removed: - decisions improve - risk reduces - performance stabilises This is not system implementation. This is executive clarity at scale. **Implication for you as CEO:** If your ERP is not giving you this level of clarity, you do not have an ERP problem. You have a governance and configuration problem. --- --- title: "Pattern Recognition: The Hidden Force Behind Your Decisions" url: "https://spsingh.me/pattern-recognition/" lang: "en-AU" type: "post" description: "Pattern Recognition In most organisations, decisions feel unique. Each situation appears different. Each challenge feels new. Each outcome is treated as a one-off. But in reality, much of what happens inside an organisation is highly predictable. Not because people lack" last_modified: "2026-04-05T10:32:30+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Pattern Recognition: The Hidden Force Behind Your Decisions" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Pattern Recognition: The Hidden Force Behind Your Decisions ## Pattern Recognition In most organisations, decisions feel unique. Each situation appears different. Each challenge feels new. Each outcome is treated as a one-off. But in reality, much of what happens inside an organisation is highly predictable. Not because people lack capability — but because human behaviour follows patterns. ## The Illusion of “New” Executives are constantly dealing with: - new projects - new systems - new pressures - new stakeholders It creates a sense that every situation requires a fresh approach. However, when you step back, a different picture emerges. Under similar conditions, people tend to behave in similar ways. And when behaviour repeats, outcomes repeat. What looks new is often just a familiar pattern in a different form. ## How Patterns Show Up in Organisations These patterns are not theoretical. They are visible every day. ### 1. The High-Performing Team Member A capable team member joins a project. They work hard. They try to impress. They take on more than they should. Initially, this looks positive. But over time: - they become overloaded - quality drops - frustration builds This pattern repeats across teams, projects, and organisations. ### 2. The Executive Shortcut An executive is presented with complex information. There is limited time. Pressure to decide is high. So they rely on: - experience - intuition - partial information They jump to a conclusion that “feels right.” Sometimes it works. Often, it creates second-order issues later. This is not poor leadership — it is a predictable pattern under pressure. ### 3. The Safe Manager A manager is asked to make a decision with unclear consequences. Instead of exploring options, they: - choose the safest path - avoid risk - protect their position The result: - slower progress - missed opportunities - incremental rather than meaningful change Again, this is not random. It is a consistent behavioural pattern. ## Why This Matters More Than It Appears Most leaders respond to these situations by trying to control outcomes: - pushing people harder - adding more governance - escalating issues - making more decisions themselves This approach treats symptoms, not causes. Because the real driver is not the decision itself — it is the pattern behind the decision. If the pattern remains unchanged, the outcome will repeat. ## The Leadership Shift: From Control to Recognition There are two fundamentally different ways to lead: ### 1. Control-Based Leadership - Direct decisions - Intervene frequently - Solve problems as they arise This creates short-term movement, but long-term dependency. ### 2. Pattern-Based Leadership (Higher Leverage) Instead of reacting, you begin to observe: - Where do similar decisions keep appearing? - What conditions lead to predictable behaviours? - Which roles consistently fall into the same traps? Once patterns are visible, your role shifts: - Ask better questions before decisions are made - Design guardrails instead of giving instructions - Prepare people for scenarios they are likely to face You are no longer managing events. You are shaping outcomes. ## A Practical Example Consider an ERP implementation. Most organisations treat issues as isolated: - delays in testing - resistance from users - rework in design Each is handled separately. But a pattern-aware leader sees something different: - unclear ownership → leads to delays - lack of understanding → leads to resistance - rushed decisions → leads to rework Instead of fixing each issue individually, they address the pattern: - clarify ownership early - build capability before design - slow down critical decisions The result is not just fewer issues — it is a fundamentally different trajectory. ## The Real Advantage Pattern recognition gives leaders something rare: **foresight.** You begin to see: - what is likely to happen - where pressure will emerge - which decisions will create downstream impact This allows you to act earlier, with less effort and greater effect. ## Final Thought Leadership is often framed as decision-making. But at a deeper level, leadership is about seeing what others do not. Most people see events. Some see problems. Very few see patterns. Those who do, shape the future before it arrives. --- --- title: "ERP Is Not an IT Project" url: "https://spsingh.me/erp-is-not-an-it-project/" lang: "en-AU" type: "post" description: "The Illusion ERP is treated as an IT problem In most Local Governments, ERP responsibility quietly shifts away from the executive table. It starts logically: The system is complex It is software IT understands technology So ownership moves to: ICT" last_modified: "2026-04-14T06:40:30+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "ERP Is Not an IT Project" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Is Not an IT Project ### The Illusion **ERP is treated as an IT problem** In most Local Governments, ERP responsibility quietly shifts away from the executive table. It starts logically: - The system is complex - It is software - IT understands technology So ownership moves to: - ICT Manager - ERP/Application Manager - Project team At the executive level, attention remains on: - Budgets - Council priorities - Community expectations - Operational pressures ERP appears “under control” because: - Steering committees exist - Reports are circulated - Vendors are engaged From the outside, it looks structured. **But this is the illusion.** ERP Is Not an IT Project — It Is Your Operating Engine ![ERP Is Not an IT Project — It Is Your Operating Engine](https://spsingh.me/wp-content/uploads/2026/04/QuickReel-Image-Apr-10-2026-11_46_17-AM-1024x572.png) ### The Reality **ERP is the organisational engine** Every critical function in your organisation runs through ERP: - Finance: how money is controlled, reported, and audited - Procurement: how spend is approved and tracked - Payroll: how people are paid - Assets: how infrastructure is managed - Projects: how work is planned and delivered ERP is not a system sitting beside the business. It is the system **through which the business operates.** It records: - Every transaction - Every approval - Every decision trail It defines: - How work flows - Where delays occur - Where controls exist or fail **Example** If your procurement process is inefficient: - Delays are not just process issues - They are embedded in ERP workflows If your financial reporting is unreliable: - It is not just a reporting issue - It is a data integrity issue inside ERP If payroll errors occur: - It is not just HR - It is how the system is configured and governed **ERP is the engine. Everything else is a reflection of how well that engine runs.** ### The Consequence ![ERP Underperformance: Unveiling the Hidden Depths](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-10-114841-1024x778.jpg) **Structural underperformance** When ERP is treated as an IT project instead of an organisational engine, a consistent pattern emerges. #### 1. Decisions are made without full ownership Directors make process decisions. IT configures the system. Vendors guide design. No one owns the **whole system outcome**. #### 2. Small compromises accumulate Each decision seems reasonable in isolation: - “Let’s customise this” - “We’ll fix that later” - “The business needs it this way” Over time, this creates: - Fragmented processes - Inconsistent data - Reduced transparency #### 3. Problems become normalised You begin to hear: - “That’s just how the system works” - “Reports need manual adjustment” - “We rely on spreadsheets for accuracy” These are not minor issues. They are signals that the engine is misaligned. #### 4. Opportunity is lost ERP is capable of: - Automation - Real-time visibility - Standardisation - Efficiency at scale But instead, organisations operate with: - Workarounds - Manual intervention - Delayed insights **The system is live, but the value is not realised.** ### The Reframe **ERP requires CEO ownership and governance clarity** ERP is not something the CEO needs to “manage day-to-day.” ![Achieving ERP Success](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-13-154714.jpg) But it is something the CEO must **own at a performance level.** This means: #### 1. Shifting the definition From: - “ERP implementation” To: - “How our organisation operates” #### 2. Setting the standard Clear expectations on: - Data integrity - Process consistency - System adoption - Reporting accuracy #### 3. Elevating the conversation ERP should not only appear in: - Project updates - IT reports It must be visible in: - Executive discussions - Performance reviews - Strategic decisions #### 4. Asking different questions Instead of: - “Is the project on track?” Ask: - “Are we improving how the organisation operates?” - “Do we trust the data we are making decisions on?” - “Where is the system slowing us down?” - “What are we still doing outside the system, and why?” ### This is where we stuck **This is where most organisations stop — and where problems persist** Recognising the importance of ERP is not enough. Without a structured way to: - Monitor performance - Detect early signals of failure - Align business and system decisions - Hold ownership at the right level The organisation gradually slips back into: - Delegation - Fragmentation - Reactive fixes This is why leading organisations introduce a **governance layer above the project and the system**. A layer that: - Sees the whole engine - Connects decisions across business and technology - Provides early visibility of risk - Maintains executive control without operational overload This is the role of an **ERP Control Tower**. Not another committee. Not another report. A mechanism to ensure that: **the system that runs your organisation is governed at the level it deserves.** --- --- title: "Why ERP Programs Become Messy — and Why Executives Feel It Before They See It" url: "https://spsingh.me/why-erp-programs-become-messy/" lang: "en-AU" type: "post" description: "Why ERP Programs Become Messy Two years into an ERP program, the reports still look acceptable. Milestones are being tracked.Steering committees are meeting.Vendors are presenting progress. Nothing appears out of control. And yet—something feels off. Decisions are harder than they" last_modified: "2026-04-14T06:39:35+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Why ERP Programs Become Messy — and Why Executives Feel It Before They See It" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Why ERP Programs Become Messy — and Why Executives Feel It Before They See It ## Why ERP Programs Become Messy Two years into an ERP program, the reports still look acceptable. Milestones are being tracked. Steering committees are meeting. Vendors are presenting progress. Nothing appears out of control. And yet—something feels off. Decisions are harder than they should be. Conversations are longer but less conclusive. Confidence is quietly eroding. At the executive level, this is often the first signal: > The program is not failing visibly — it is drifting structurally. ## The Dynamic: A Multi-Player System Without a Shared Game ERP programs are not just delivery efforts. They are **multi-player systems**, where each group operates with different incentives, constraints, and definitions of success. On paper, everyone is aligned. In reality, each stakeholder is playing a different game. - The vendor is optimising for delivery scope and commercial return - The internal project team is managing risk and continuity of employment - Business leaders are protecting operations and minimising disruption - Executives are balancing political, financial, and reputational pressures None of these are wrong. But they are not aligned. ## What It Feels Like at the Executive Level This misalignment does not present as a single failure. It shows up as friction. ![Executive Level Misalignment: Friction and Uncertainty](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-10-112747.jpg) ### 1. Decisions That Should Be Simple… Aren’t An executive asks: > “Should we standardise this process or customise it?” The room responds with: - “It depends” - “We need more workshops” - “The system can handle both” Weeks pass. No clear direction. What is actually happening: - Vendor prefers complexity (more effort, more revenue) - Business prefers customisation (less disruption) - Project team avoids committing (risk containment) The decision is not technical. It is **structurally conflicted**. ### 2. Everything Is “On Track”… But Nothing Feels Certain Reports show green. But: - Issues are being reframed, not resolved - Trade-offs are being deferred - Risks are being absorbed into scope Executives sense it: > “We are moving, but are we getting closer to the right outcome?” This is where perception and reality begin to diverge. ### 3. Compromises Start Accumulating Quietly No single decision is wrong. But collectively: - Processes are partially standardised - Data structures are inconsistently defined - Workarounds are accepted “for now” Each compromise is reasonable in isolation. Together, they form a system that is: > Delivered successfully, but operationally compromised. ### 4. The Burden of “Success” Becomes Heavy As the program progresses, a subtle shift occurs. The goal is no longer: > Deliver the right system It becomes: > Deliver something that can be called a success At this point: - Escalations reduce - Challenges are softened - Narratives are managed Executives feel it as tension: > “Are we solving the problem, or managing the story?” ## Why This Happens Because the program is operating without a **unified definition of success and aligned incentives**. In this environment: - Governance becomes reporting-focused, not decision-focused - Trade-offs remain implicit, not explicit - Accountability is distributed, but ownership is unclear The result is predictable: > Misalignment → Distorted decisions → Compromised design → Managed success narrative ## The Structural Problem: No One Owns the Whole Outcome ERP programs often have: - Project governance - Technical governance - Change governance But what is missing is: > **Value governance at the executive level** No single structure ensures that: - Decisions align to long-term organisational value - Trade-offs are made consciously and consistently - Incentives across stakeholders are aligned Without this, the system self-optimises… in different directions. ## The Shift Required: From Delivery Oversight to System Control Executives do not need more reports. They need: - Clarity on what game is being played - Visibility of where misalignment exists - Control over how decisions are made This is where a different model is required. ![Achieving System Control](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-10-113027.jpg) ## Introducing the ERP Control Tower™ The ERP Control Tower™ is not another governance layer. It is a **control mechanism for alignment**. Its purpose is to ensure that: > The entire system operates toward a single definition of success. ## What the Control Tower Changes ### 1. Makes Trade-Offs Explicit Every major decision is framed as a trade-off: - Standardisation vs flexibility - Speed vs quality - Cost vs long-term value Executives are not shielded from these—they are **guided through them**. ### 2. Aligns Incentives Across Stakeholders The Control Tower surfaces: - What each party is optimising for - Where those incentives conflict - What needs to be realigned This turns hidden tension into visible structure. ### 3. Shifts Governance from Reporting to Decision Quality Instead of asking: > “Are we on track?” It asks: > “Are we making the right decisions?” This changes the entire posture of the program. ### 4. Provides Early Detection of Drift Rather than waiting for failure signals (budget, timeline), it monitors: - Decision delays - Compromise patterns - Escalation avoidance These are early indicators of structural misalignment. ### 5. Re-establishes Executive Ownership Most importantly, it reinforces that: > ERP success is not a project outcome — it is an executive responsibility The Control Tower gives executives the mechanism to fulfil that responsibility. ![ERP Control Tower Hierarchy](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-10-113216-1024x571.jpg) ## What This Means in Practice When the Control Tower is in place: - Decisions are faster, because trade-offs are clear - Conversations are sharper, because incentives are visible - Compromises are deliberate, not accidental - Success is defined upfront—and defended throughout The program stops feeling “messy”. Because it is no longer a collection of competing agendas. It becomes a **coordinated system**. ## Final Thought ERP programs do not become messy overnight. They drift—quietly, structurally, predictably. Executives often feel it long before it is visible. The question is not: > “Is the project on track?” The real question is: > “Is the system aligned?” Because if it is not, no amount of reporting will fix it. Only control will. Reach out to us at info@bhaniconsulting.com- if you’d like to know more. --- --- title: "ERP Success Is Not Binary" url: "https://spsingh.me/erp-success-is-not-binary/" lang: "en-AU" type: "post" description: "ERP Success Is Not Binary. It Is a Spectrum Two years into an ERP program, a report reaches the executive table stating the project was delivered on time, within budget, and successfully went live. On paper, it is a success." last_modified: "2026-04-14T06:34:56+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "ERP Success Is Not Binary" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Success Is Not Binary ## ERP Success Is Not Binary. It Is a Spectrum Two years into an ERP program, a report reaches the executive table stating the project was delivered on time, within budget, and successfully went live. On paper, it is a success. Inside the organisation, a different reality is emerging. Workarounds are increasing. Reporting remains unreliable. Teams are frustrated. The expected value is unclear. This gap between what is reported and what is experienced is common. It is not primarily an execution issue. It is a definition issue. ## The Old Thinking: Success as a Binary Outcome Most ERP programs are governed by a simple model: Delivered equals success. Not delivered equals failure. This model is appealing because it is easy to communicate, easy to defend, and easy to close. However, it is fundamentally flawed. ERP is not just a project. It is a shift in organisational capability. Capability cannot be reduced to a binary outcome. ## The Reality: Success Is Multi-Dimensional To understand this, consider how success is defined outside of business systems. No one evaluates personal success based on a single measure such as income or fitness. It is understood as a combination of multiple factors, each contributing differently depending on the individual. ERP success follows the same principle. It is not one outcome. It is a position across a range of capabilities. ## A Practical Model: Measuring ERP Success as a Spectrum A more useful way to define ERP success is to assess it across a set of **value dimensions**, each representing a different aspect of organisational capability. These dimensions together form a spectrum. Where the organisation sits across them determines the real outcome of the ERP program. ![ERP success as a Spectrum of Value Dimensions](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-10-105632.jpg) **1. Project Delivery** This dimension assesses whether the program was executed in a controlled and disciplined manner. Example: The ERP goes live within approved budget and timeline, with no major operational disruption. Business users are able to perform core functions from day one, and there is no immediate fallback to legacy systems. Contrast: A system goes live “on time,” but key processes (e.g. payroll or procurement) require manual intervention for weeks. Technically delivered, but operationally unstable. **2. Relationships** This reflects whether the program built or eroded trust across stakeholders. Example: Business, IT, and the vendor maintain open communication. Issues are surfaced early. Stakeholders feel heard, and there is confidence in decision-making. Contrast: Escalations increase. Business blames IT, IT blames the vendor, and the vendor defends scope. Meetings become defensive rather than collaborative. Trust declines even if milestones are met. **3. Efficiency** This measures whether the ERP has improved how work is done. Example: Invoice processing time reduces from 10 days to 3 days within six months. Manual data entry is reduced significantly. Staff spend less time reconciling errors. Contrast: The system is live, but processes take the same time or longer. Users create spreadsheets outside the system to complete tasks. Efficiency gains are not realised. **4. Transparency** This assesses whether leadership now has better visibility of the organisation. Example: Executives can access real-time financial dashboards. Budget vs actuals are visible daily. Operational metrics are reliable and consistent across departments. Contrast: Reports still require manual consolidation. Different departments produce conflicting numbers. Decision-making is delayed due to lack of trust in data. **5. Scalability** This determines whether the system can support future growth and change. Example: The ERP integrates cleanly with CRM, asset systems, and Microsoft tools. New services or business units can be added without significant rework. Contrast: Every new requirement requires customisation. Integrations are fragile. The organisation becomes dependent on external vendors for even minor changes. **6. Standardisation** This evaluates whether the organisation is operating in a consistent and controlled way. Example: Procurement processes are standardised across departments. Policies are embedded in the system. Variations are minimal and intentional. Contrast: Each department uses the system differently. Processes vary widely. Workarounds are common. The ERP reflects existing inconsistency rather than resolving it. **7. Embedding** This measures whether the change has been sustained and internalised. Example: Internal teams are confident using the system. Continuous improvement initiatives are led by the business. Reliance on external consultants reduces over time. Contrast: Months after go-live, the organisation still depends heavily on vendors or contractors. Knowledge remains external. Improvements stall. ## The Combined View Individually, each dimension provides a partial view. Together, they reveal the true position of the organisation. For example: - Strong delivery but weak embedding → short-term success, long-term risk - High transparency but low standardisation → better visibility, but inconsistent execution - Good relationships but poor efficiency → collaborative environment, limited value realisation This is why ERP success cannot be reduced to a single outcome. It must be understood as a **profile across multiple dimensions**, each moving at a different pace. This model allows executives to see what is actually happening beneath the surface—and where intervention is required before issues become systemic. ## The Shift: From Outcome to Position When viewed through these dimensions, success is no longer a simple yes or no decision. It becomes a position across a spectrum. An organisation may have strong project delivery but weak adoption, good relationships but poor data visibility, or efficient processes that do not scale. This is the real picture of ERP performance. This perspective explains why many programs that are formally declared successful still feel like failures in practice. ## Why This Matters at the Executive Level At the executive level, the issue is not a lack of effort or intent. It is a limited lens through which success is defined and assessed. This creates systemic problems. Programs are declared successful too early. Decisions are made based on delivery milestones rather than capability outcomes. Risks related to adoption, data, and operations remain invisible until they become critical. In practical terms, the organisation cannot see what actually matters. ## A More Useful Question Instead of asking: Is the ERP project successful? Ask: Where are we on the spectrum of capability across these dimensions? This shift changes what is measured, what is discussed, and what is prioritised. ## The Bridge: What Executives Must Do Differently To move from the traditional model to this approach, three changes are required. First, define success before delivery. This must go beyond time, cost, and scope to include adoption, data quality, process consistency, and operational outcomes. Second, measure beyond go-live. Most value is realised months after implementation, not at the point of deployment. Third, accept trade-offs. Speed, cost, scalability, and standardisation cannot all be optimised simultaneously. These decisions must be made consciously at the leadership level. ![Bridging to Value-Driven Delivery](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-10-110949-1024x543.jpg) ## The Insight ERP success is not something achieved at a point in time. It is something the organisation moves towards over time. Without a structured way to understand that movement, organisations fall back on simplified reporting, misleading narratives, and repeated mistakes. ## The Next Step Most organisations do not struggle with ERP because of technology or vendors. They struggle because they have not clearly defined what success means. If this perspective resonates, the next step is to define your success dimensions, assess your current position across them, and identify where the gaps exist. That is where real governance begins. Email us at info@bhaniconsulting.com if you’d like to learn more. --- --- title: "The Illusion of ERP Success" url: "https://spsingh.me/the-illusion-of-erp-success/" lang: "en-AU" type: "post" description: "Why most organisations measure the wrong thing—and don’t realise it The Comfortable Story Every Executive Hears Two years into an ERP program, the update sounds familiar: The system has gone live The project stayed within budget Key milestones were achieved" last_modified: "2026-04-14T06:16:33+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Illusion of ERP Success" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Illusion of ERP Success _Why most organisations measure the wrong thing—and don’t realise it_ ### The Comfortable Story Every Executive Hears Two years into an ERP program, the update sounds familiar: - The system has gone live - The project stayed within budget - Key milestones were achieved - Stakeholders are broadly satisfied On paper, this is success. Boards are reassured. Steering committees close. Teams move on. But beneath that narrative, a quieter question remains—rarely asked: > **Did the organisation actually become better?** ### The Question We Avoid Most organisations spend time defining _what success looks like_. Very few ask: > **Why do we measure success in the first place?** This is not a philosophical question. It is structural. Because the purpose of measuring success is not reporting. It is not governance formality. It is not reassurance. It is to: - Enable better decisions - Drive meaningful action - Create learning loops - Expose inefficiencies - Validate real value In simple terms: > **We measure success to improve the organisation.** ![Success measurement strategies and benefits](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-13-140756.jpg) ### Where It Breaks Now consider how success is actually measured in most ERP programs: - Delivered on time - Delivered within budget - Scope achieved - Go-live completed These measures are widely accepted. Rarely challenged. But they do not serve the purpose above. They do not tell you: - Whether decision-making improved - Whether inefficiencies were removed - Whether capability increased - Whether value was actually realised Instead, they answer a different question: > “Was the project delivered?” Not: > “Did the organisation improve?” ### The Executive Success Distortion This creates a structural condition: > **Success is declared based on perception, not discovered through evidence.** Three forces reinforce this distortion. ![Concepts of executive decision-making pitfalls](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-13-135846.jpg) #### 1. **Manipulation of Information and Narrative** No one sets out to mislead. But systems and incentives shape behaviour. - Reports highlight what is progressing well - Risks are softened or contextualised - Metrics are selected to support a positive narrative Over time: - Green dashboards replace real insight - Issues become “managed” rather than solved - Success becomes a story the organisation agrees to believe #### 2. **Static Baselines in a Dynamic Reality** At the start of the program: - Business case is defined - Budget is approved - Timelines are locked At that point, understanding is limited. Yet those early assumptions become: - Fixed benchmarks - Anchors for success - The reference point for judgement The problem is simple: > **The organisation learns more as the program progresses—but continues to measure success against what it knew at the start.** Reality evolves. Measurement does not. #### 3. **Binary Thinking** Success is treated as: - Success / Failure - Delivered / Not delivered This simplifies reporting. But it removes meaning. Because organisational improvement is never binary. It is gradual, uneven, and contextual. ### The Shift: Success Is a Spectrum If the purpose of measurement is improvement, then success must be measured as a **degree**, not a state. A more accurate view looks like this: ![Pyramid illustrating success spectrum stages](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-13-140538-1024x550.jpg) Most organisations stop at base levels 4 and 5—and declare success. Very few reach Level 1 or 2. Fewer still measure it. ### The Business Case Illusion Executives often rely on the business case as the ultimate benchmark. But consider this: > The business case is not a truth. It is an early hypothesis. It is built when: - Information is incomplete - complexity is underestimated - organisational behaviour is not fully understood Yet it becomes: - The anchor for accountability - The justification for decisions - The definition of success This creates a subtle but critical issue: > **The organisation becomes accountable to its initial assumptions—rather than to actual outcomes.** ### What This Means for You If success is misdefined: - Governance cannot function properly - Reporting cannot reveal truth - Decisions cannot be optimised - Capability cannot develop What remains is: - Delivery without transformation - Stability without improvement - Confidence without evidence ### How to Recognise It Early You are likely operating in this condition if: - Reports are consistently positive, but operational pain persists - Go-live is treated as the finish line - Benefits are assumed rather than measured - The business case remains unchanged despite evolving scope - There is no visibility of decision quality or rework - Success is discussed in milestones, not outcomes These are not project issues. They are **measurement design failures at the executive level**. ### The Reframe ERP is not a technology project. It is a mechanism to: - Understand how the organisation works - Improve how decisions are made - Redesign how value is created If success measurement does not support this: > The system may be delivered—but the organisation remains unchanged. ### A Different Standard The question is not: > “Did we deliver the ERP?” It is: > **“To what extent are we now better than before?”** Better in: - decision-making - efficiency - clarity - performance - value creation This requires: - Dynamic measurement - Honest reporting - Continuous recalibration of success ### Final Thought Most ERP programs do not fail because they miss targets. > They fail because the targets were never designed to reveal the truth. Until that changes, success will continue to be declared— without improvement ever being realised. _Why most organisations measure the wrong thing—and don’t realise it_ without improvement ever being realised. --- --- title: "The Story of ERP Implementation" url: "https://spsingh.me/the-story-of-erp-implementation/" lang: "en-AU" type: "post" description: "Two years ago, the CEO approved a major ERP program. It made sense. The organisation had outgrown its systems. Processes were fragmented. Reporting was inconsistent. Everyone agreed — something had to change. A strong business case was presented. A reputable" last_modified: "2026-04-14T06:33:58+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Story of ERP Implementation" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Story of ERP Implementation Two years ago, the CEO approved a major ERP program. It made sense. The organisation had outgrown its systems. Processes were fragmented. Reporting was inconsistent. Everyone agreed — something had to change. A strong business case was presented. A reputable vendor was selected. A capable implementation partner was engaged. Governance structures were established. Steering committees were formed. Monthly reports were circulated. From the outside, everything looked right. Inside the organisation, something else was happening. The CEO had other priorities — budget pressures, community expectations, political sensitivities. ERP remained important, but not urgent. So responsibility shifted. Directors stepped in. They were capable, committed, and accountable for their areas. But ERP was not their only concern. They were balancing: - operational demands - staff issues - compliance pressures - competing initiatives ![Ineffective ERP Implementation due to competing priorities](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-13-150607.jpg) They were making decisions in a domain they did not fully control. The system design began to take shape. Workshops were held. Requirements were gathered. Vendors provided guidance. Small decisions were made daily. Each one reasonable. Each one justified. - _“We need to adjust this to fit our process.”_ - _“The vendor recommends this approach.”_ - _“We can fix that later.”_ No single decision was wrong. But collectively, something was drifting. Months passed. Progress reports remained positive. - _“On track”_ - _“Within scope”_ - _“Risks managed”_ There was no obvious failure. Only a gradual shift away from the original intent. Then came go-live. The system worked. But not as expected. Processes felt heavier. Workarounds began to appear. Spreadsheets quietly returned. Users adapted — but not optimally. The organisation stabilised. From the outside, it was called a success. From the inside, it felt different. Value was lower than expected. Effort was higher than planned. Confidence was uncertain. Eighteen months later, the real questions began. Why are we still struggling with reporting? Why are processes more complex? Why are we not seeing the benefits we expected? The CEO now had to answer. To Council. To the Board. To the organisation. By this time: - the project team had moved on - the vendor had delivered their scope - key decision-makers had shifted roles What remained was the system. And the outcome. No single decision caused the problem. No individual failed. Yet the result was not what was intended. The organisation did not fail. It simply absorbed the outcome. Adjusted. And moved forward. And in many cases — prepared to do it again. ### **The Real Question** Why does this keep happening? Not in one organisation. But across many. ### **The Insight** ERP outcomes are rarely determined by effort, capability, or intent. They are shaped by something far less visible: - how decisions are made - who holds accountability - how risk is surfaced - how closely leadership stays connected In most organisations, these elements are not actively controlled. They are left to emerge. ![ERP Outcomes Depend on Hidden Factors](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-13-143655.jpg) ### **The Truth** When there is no clear control over decisions, governance, and signals: **ERP outcomes are driven by drift, not design.** And drift feels like: **Luck** ### **The Bridge** This is why most organisations do not have a system problem. They have a **control problem**. ### **Introducing the Shift** The organisations that succeed do one thing differently. They do not leave ERP to: - project teams - vendors - or fragmented governance They create a mechanism that: - maintains executive visibility - surfaces risk early - controls decision pathways - aligns the organisation continuously What do we do to help organisations guarantee successful ERP implementations? We set-up: **ERP Control Tower™** Most organisations implement ERP. Very few actually control it. ![ERP Control Tower Hierarchy](https://spsingh.me/wp-content/uploads/2026/04/Screenshot-2026-04-13-145605.jpg) --- --- title: "Why Organisations Feel Complex?" url: "https://spsingh.me/why-organisations-feel-complex/" lang: "en-AU" type: "post" description: "It Looks Simple—Until You Look Closer From the outside, an organisation looks straightforward. There is: A structure A system A team of people doing their jobs Everything appears organised. You would expect it to work smoothly. But then questions start" last_modified: "2026-04-29T06:38:03+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "Why Organisations Feel Complex?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Why Organisations Feel Complex? ## It Looks Simple—Until You Look Closer From the outside, an organisation looks straightforward. There is: - A structure - A system - A team of people doing their jobs Everything appears organised. You would expect it to work smoothly. But then questions start to appear: - Why do decisions feel inconsistent? - Why do systems not deliver expected value? - Why does progress feel harder than it should be? Nothing is obviously broken. And yet, something is not quite right. To understand this, we need to look at the organisation in a simpler way. ## Imagine It Like a Playground Think of an organisation like a playground. There are: - Children playing - Rules written on a board - Equipment designed for play At first glance, everything is set up correctly. But if you watch closely, something interesting happens. Not all children play the same game. ## Different Games, Different Goals Some children want to win. Some want to have fun. Some want to avoid getting hurt. Some just want to finish quickly and leave. They are all in the same playground. But they are not playing the same game. **Now bring this back to an organisation.** ## Your Organisation Is an Ecosystem Your organisation is surrounded by different players: - Board - Executives - Regulators - Government - Suppliers - Employees - Auditors ![Ecosystem of Your Organisation](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-04-29-142835-1024x799.jpg) Each one is part of the same environment. But each one has different objectives. - Regulators want compliance - Finance wants control - Operations want speed - Suppliers want efficiency - Executives want outcomes Everyone is involved. But not everyone is aiming at the same thing. ## And These Objectives Don’t Always Align Sometimes they align. Often, they don’t. - What speeds up delivery may reduce control - What improves compliance may slow operations - What benefits one team may create friction for another This is where complexity begins. Not in systems. Not in structure. But in competing objectives. ## Now Bring It Inside the Organisation Inside this ecosystem, the organisation tries to bring order. It does this using two things: **Structure** This defines: - Who does what - Who reports to whom - What rules should be followed **System** This enables: - Workflows - Transactions - Reporting - Day-to-day operations Together, structure and system are meant to create clarity. ## But Here Is What We Miss We assume: > _If structure is clear and systems are in place—the organisation will work as expected._ ![ChatGPT Image Apr 29 2026 02 31 18 PM SP Singh Blog](https://spsingh.me/wp-content/uploads/2026/03/ChatGPT-Image-Apr-29-2026-02_31_18-PM-1024x683.png) But this assumption ignores something important. ## People Don’t Follow Systems—They Play Their Own Game Just like the children in the playground, people in organisations: - Adapt - Optimise - Work around constraints They respond to: - Pressure - Incentives - Time constraints - Personal goals So even with: - Clear structure - Strong systems People will still: - Take shortcuts - Find faster ways - Prioritise what matters to them ## This Is Where Things Start to Drift Now you have: - An ecosystem with different objectives - An organisation with defined structure - Systems designed to control work - People responding to real-world pressures These do not automatically align. **So what happens?** - Systems are used differently than intended - Processes are followed sometimes, not always - Decisions vary depending on context From the outside: Everything still looks fine. From the inside: It feels harder than it should be. ## The Real Role of Executive Management This is where leadership becomes critical. The role of executive management is not just to: - Approve decisions - Review reports - Drive performance The real role is: > _To create awareness and alignment across all these different “games.”_ This means: - Understanding who wants what - Recognising where objectives conflict - Making trade-offs explicit - Aligning structure, systems, and behaviour Why This Is So Difficult Because much of this is not visible. You can see: - Org charts - Systems - Reports But you cannot easily see: - Incentives - Informal decisions - Workarounds - Hidden pressures And what is not visible—is rarely managed. ## A Simple Way to Think About It Think of your organisation as three things happening at once: - A system that processes work - A structure that defines rules - An ecosystem of players with different goals And within all of this: > _People are constantly adjusting to make things work._ ## Why Organisations Feel Hard Organisations are not hard because they are broken. They are hard because: > _Multiple players are playing different games within the same system._ And no one is fully aligning them. ## Closing Thought Most organisations try to improve by: - Changing systems - Updating structure Very few focus on: > _Understanding and aligning the different objectives and behaviours at play_ Until this is addressed: - Complexity will remain - Effort will increase - Outcomes will vary Not because people are failing—but because the organisation is not designed to align how it actually works. If you can start to see this clearly, you begin to move from: Managing parts of the organisation to Understanding the organisation as a whole. --- --- title: "The Hidden Setup Inside Every Organisation" url: "https://spsingh.me/hidden-setup-inside-every-organisation/" lang: "en-AU" type: "post" description: "Why structure, systems, and behaviour rarely align? The Illusion of a Well-Designed Organisation Most organisations appear structured. They have: Defined organisational charts Documented processes Implemented systems On the surface, everything suggests control. Workflows exist. Systems are in place. Responsibilities are" last_modified: "2026-04-29T06:20:03+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Hidden Setup Inside Every Organisation" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Hidden Setup Inside Every Organisation _Why structure, systems, and behaviour rarely align_? ## The Illusion of a Well-Designed Organisation Most organisations appear structured. They have: - Defined organisational charts - Documented processes - Implemented systems On the surface, everything suggests control. Workflows exist. Systems are in place. Responsibilities are assigned. And yet, beneath this apparent order, a quieter reality exists. - Systems are used—but not always as intended - Processes are defined—but inconsistently followed - Decisions are made—but not always through formal channels This is where most leaders begin to feel the gap. Not because the organisation lacks effort, but because it lacks clarity on how it truly operates. ## Seeing the Organisation as It Is To understand this gap, it helps to step back and observe the organisation differently. Every organisation operates across three layers: - Structure - System - Behaviour ![Organisational Layers](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-04-29-141516-1024x720.jpg) These layers are always present. But they are not equally visible. And more importantly, they are rarely aligned. ## Structure — The Intended Design Structure is where organisations begin. It defines: - Roles and responsibilities - Reporting lines - Policies and procedures - Governance frameworks Structure represents intent. It answers the question: > _How should this organisation work?_ ## A simple example A procurement process is designed with: - Defined approval limits - Clear escalation paths - Documented policies On paper, everything is logical. Responsibilities are clear. Controls are defined. The organisation, at this level, appears well designed. ## System — The Operational Expression To bring structure to life, organisations implement systems. These include: - ERP platforms - Workflow tools - Data and reporting systems Systems translate structure into activity. They answer the question: > _How does work move through the organisation?_ **Continuing the example** The procurement process is now embedded in an ERP system. - Requests are logged - Approvals are routed - Transactions are recorded From a system perspective, everything is functioning. The workflow exists. The process is digitised. The organisation, at this level, appears controlled. ## Behaviour — The Lived Reality But there is a third layer. This is where the organisation truly operates. Behaviour is: > _How people interact, decide, and act—based on both written and unwritten rules._ It includes: - Informal practices - Workarounds - Incentives and pressures - Local decision-making Behaviour answers the question: > _How does work actually get done?_ **The reality behind the example** In practice: - A manager is called directly to fast-track approval - Purchase orders are split to stay within limits - Approvals are completed after the fact From the outside: - The system shows compliance - The structure appears intact But the lived reality is different. The organisation is functioning— but not as designed. ## Where Misalignment Begins Most organisations assume a simple flow: > **Structure → System → Outcomes** Design the structure. Implement the system. Achieve the outcome. But this assumption misses a critical truth. In reality: > **Behaviour → shapes system usage → determines outcomes** ## The Consequence of Ignoring Behaviour When behaviour is not understood or aligned: - Systems are bypassed - Processes become inconsistent - Data loses integrity - Controls weaken over time The organisation continues to operate—but begins to drift. ![Ignoring Behaviour Leads to Organisational Drift](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-04-29-141807-1024x643.jpg) ## Why This Problem Remains Invisible One of the reasons this issue persists is that each layer tells a different story. **IT sees system performance** The system is implemented. Workflows are running. Data is being captured. From this perspective, the organisation is functioning. **Business sees output** Work is getting done. Customers are being served. Deadlines are being met. From this perspective, the organisation is delivering. **Behaviour sits in between** It is rarely measured. Rarely discussed. Rarely owned. Workarounds become normal. Shortcuts become accepted. Unwritten rules take over. ## A Simple Way to Understand It Think of an organisation like a road system. - Structure is the road rules - System is the roads and signals - Behaviour is how people actually drive You can have: - Perfect rules - Well-designed roads But if behaviour does not align—the outcome will not match the design. ## Where Most Transformation Efforts Fall Short Most transformation efforts focus on: - Redesigning structure - Implementing systems Very few address: > _How behaviour must change to make both effective_? This is why we see repeated patterns: - ERP systems go live, but adoption is partial - Process redesigns are documented, but not sustained - Change initiatives start strong, but fade over time The organisation changes—but does not improve in a lasting way. ## The Missing Link To bring these layers together, organisations need to recognise something fundamental: > _ Improvement does not happen through structure or systems alone._ It requires alignment across all three layers. This is where [Capability Development](https://spsingh.me/capability-development/) becomes critical. Not as a project. Not as a temporary initiative. But as a [discipline responsible](https://spsingh.me/the-three-disciplines-of-an-organisation/) for: - Designing how work should happen - Ensuring systems support that design - Aligning behaviour to sustain it ## Closing Thought Most organisations are not failing. They are simply incomplete in how they understand themselves. They manage what is visible: - Structure - Systems But overlook what is decisive: - Behaviour And what is not clearly seen—cannot be properly managed. If you can begin to see these three layers together, you start to understand why: - Well-designed organisations struggle. - Well-implemented systems underperform. - And well-intentioned change does not last. Because an organisation is not defined by what is designed—but by what is consistently done. --- --- title: "Watching your mind" url: "https://spsingh.me/watching-your-mind/" lang: "en-AU" type: "post" description: "It usually starts small. A thought. A comment. A moment that doesn’t sit right. Nothing significant on the surface. Yet within minutes, something shifts. You are no longer in that moment. You are inside your head, trying to figure it" last_modified: "2026-03-29T14:12:08+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Watching your mind" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Watching your mind It usually starts small. A thought. A comment. A moment that doesn’t sit right. Nothing significant on the surface. Yet within minutes, something shifts. You are no longer in that moment. You are inside your head, trying to figure it out. The mind begins doing what it does best. It searches for a cause, builds a scenario, and connects a few unrelated dots. It fills gaps, adds meaning, and creates a story. Not because something is wrong, but because the mind is wired to make sense of everything. What it cannot explain, it cannot tolerate. So it explains, even if the explanation is not true. At first, it feels like thinking. Then it becomes analysing. Then overanalysing. Then something subtle happens. The story starts to feel real, and the body responds. A bit of anxiety. A bit of heaviness. A bit of discomfort. Now the loop begins. The emotion reinforces the thought, and the thought strengthens the emotion. You feel uneasy, so the mind looks for more reasons. It finds them, or creates them. What started as a moment becomes a narrative. What was simple becomes complicated. What was [neutral becomes negative](https://spsingh.me/individualism/). And the strange part is, it does not feel like a loop. It feels like truth. It feels justified. It feels necessary. Because the mind is not trying to harm you. It is trying to protect you. It prefers a bad explanation over uncertainty. It prefers control over ambiguity. It prefers noise over silence. When you are inside this loop, you cannot see it. You are not observing the thoughts, you are inside them. There is no separation. You are the story and the emotion. And in that state, everything feels real, even if it is not. Then time passes. Nothing dramatic happens, just time. And suddenly, the same situation looks different. Lighter. Simpler. Less important. You start to wonder why you thought so much or reacted that way. The clarity was always there, but not available in that moment. Time created distance, and distance created perspective. This is why looking back matters. It does not change what happened, but it shows you the pattern. You begin to see that the trigger was small, the reaction was large, and the story was created by the mind. And more importantly, you see that the mind does this again and again. Once you notice this a few times, something shifts. You begin to catch it earlier. The first thought. The second connection. The beginning of the story. And in that moment, a small gap appears. That gap is [awareness](https://bhaniconsulting.com/). Not control. Not fixing. Just seeing clearly that the mind is creating something. And when you see it, the loop starts to weaken. Over time, this becomes natural. The mind still creates thoughts and stories, but you do not get pulled in as deeply. You do not go as far, and you do not stay as long. Life becomes simpler, not because problems disappear, but because you stop turning small moments into complex narratives. The mind will always do what it does. But you do not have to believe every thought it creates. When you start watching your mind instead of becoming it, you save yourself from a lot of unnecessary misery. --- --- title: "ERP Is Not the Project. It Is the Journey Most Organisations Never Finish." url: "https://spsingh.me/erp-is-not-the-project/" lang: "en-AU" type: "post" description: "Most organisations believe ERP success is achieved at go-live. The system is implemented.Users are trained.Reports are running. On paper, the project is complete. But in reality, this is where the real work begins. And this is where most organisations quietly" last_modified: "2026-04-14T06:28:13+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "ERP Is Not the Project. It Is the Journey Most Organisations Never Finish." cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # ERP Is Not the Project. It Is the Journey Most Organisations Never Finish. Most organisations believe ERP success is achieved at go-live. The system is implemented. Users are trained. Reports are running. On paper, the project is complete. But in reality, this is where the real work begins. And this is where most organisations quietly stop. Note that ERP is not the project; here’s why! ## **The Problem No One Calls Out** ERP programs are treated as **projects to deliver**, not **capabilities to build**. So the focus becomes: - Timeline - Budget - Configuration - Go-live And once those are achieved, attention shifts elsewhere. What gets missed is far more important: - How the organisation actually works with the system - Whether processes are improving - Whether decisions are getting better - Whether value is being realised from the investment The result? A system that exists — but does not transform. ## **The Reality: ERP Maturity Happens in Stages** ERP is not a binary outcome (implemented vs not implemented). It is a progression of maturity. And each stage requires a fundamentally different mindset. ![ERP Maturity Stages](https://spsingh.me/wp-content/uploads/2026/03/visual-selection-8-1024x861.jpg) ### **Stage 1 – Foundation (Getting to Go-Live)** This is where most energy is spent. The organisation focuses on: - Configuration and data migration - Basic workflows - Minimal customisation - Basic security roles - Limited integrations The goal is simple: **Make the system work.** And when go-live happens, it feels like success. But this stage only delivers one thing: System availability — not business value. ### **Stage 2 – Optimisation (Making It Useful)** This is where ERP starts to matter. The organisation begins to: - Integrate systems - Refine workflows - Develop SOPs and training - Improve reporting and dashboards - Identify bottlenecks and inefficiencies - Tailor the system to real operational needs Now the question shifts from: **“Is the system working?”** to **“Is the organisation working better because of the system?”** This stage delivers: Efficiency, visibility, and improved decision-making. Yet many organisations only partially reach this stage. Because optimisation requires ownership. And ownership is often unclear. ### **Stage 3 – Embedded (Making It Valuable)** Very few organisations reach this stage. This is where ERP becomes part of the organisation’s DNA. At this level: - Systems, processes, and data are aligned - Continuous improvement is structured and ongoing - Governance is active and intentional - Decisions are driven by reliable insights - The organisation actively maximises return on its investment The focus is no longer the system. It is: How the organisation continuously improves how it creates and delivers value. This stage delivers: Strategic value, sustainability, and long-term return on investment. ## **The Opportunity Most Organisations Miss** The biggest mistake is not poor implementation. It is **stopping too early**. Most organisations: - Stop at Stage 1 - Struggle through parts of Stage 2 - Never design for Stage 3 Not because they lack capability. But because they never planned for it. There is no: - Ownership of improvement - Clear governance model - Defined roadmap beyond go-live So ERP becomes: A system to maintain — not a capability to evolve. ## **What Should Have Been Planned From Day One** ERP should never be planned as a single project. It should be designed as a **multi-stage maturity journey**. ![Essential Planning Elements](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-03-30-110556.jpg) ### **1. Plan for Foundation — But Don’t Anchor to It** Yes, go-live matters. But it is only the starting point. Design decisions should consider: - Future integrations - Scalability - Data structure for reporting - Long-term operating model ### **2. Define How Optimisation Will Happen** Before go-live, organisations should already know: - Who owns process improvement - How workflows will be reviewed and enhanced - How users will be supported and trained over time - How insights will be generated and used Optimisation does not happen organically. It requires structure. ### **3. Establish Governance for Continuous Value** This is the most critical and most neglected element. Organisations must define: - Who owns capability development - How decisions about changes are made - How value is measured - How continuous improvement is prioritised Without governance, ERP stagnates. With governance, ERP evolves. ## **The Deeper Issue** This is not a technology problem. It is a structural one. Most organisations have: - IT to manage systems - Business to run operations But no clear ownership of: Improving how the organisation works over time. This is the [missing discipline.](https://spsingh.me/capability-development/) And ERP exposes it more than anything else. ## **Final Thought** ERP does not fail because of software. It under-delivers because organisations treat it as an endpoint. But ERP is not the destination. It is the platform. The real question is: What capability will you build on top of it? ![ERP is not the destination. It is the platform.](https://spsingh.me/wp-content/uploads/2026/03/QuickReel-Image-Mar-30-2026-11_19_46-AM-1024x572.jpg) --- --- title: "The Roles within Capability Development" url: "https://spsingh.me/the-roles-within-capability-development/" lang: "en-AU" type: "post" description: "The Picture Most Organisations Are Living In A new system is implemented. The project is declared successful.Training is completed.The vendor is paid. Six months later: Workarounds start appearing Reports are questioned Processes still feel slow Teams complain the system “doesn’t" last_modified: "2026-04-14T06:26:41+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Roles within Capability Development" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Roles within Capability Development ## **The Picture Most Organisations Are Living In** - A new system is implemented. The project is declared successful. Training is completed. The vendor is paid. Six months later: - Workarounds start appearing - Reports are questioned - Processes still feel slow - Teams complain the system “doesn’t work properly” Leadership senses something is off—but can’t quite pinpoint why. So another initiative begins. Another improvement program. Another system enhancement. Another round of workshops. And yet, the organisation doesn’t fundamentally improve. ## **What’s Actually Happening** No one owns the outcome. - IT owns the system - The project team owned delivery - The business uses the process But no one owns whether the organisation is actually better as a result. This is not a capability problem. This is an ownership problem. ## **The Missing Discipline** Every organisation is doing capability development every day: - Implementing ERP and CRM systems - Redesigning processes - Improving data and reporting - Driving automation and efficiency But this work is fragmented across teams. It is not treated as a discipline with clear roles and accountability. ## **The Structure: The Roles within [Capability Development](https://spsingh.me/capability-development/)** In practice, capability development requires **five distinct roles**. Each role exists in most organisations— but rarely with clarity. When these roles are undefined or blurred, value is lost. When they are clear, transformation becomes predictable. ![Capability Development Roles and Challenges](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-03-30-092323-1024x482.jpg) ### **1. Capability Architect** **Design – Defines what should exist** **What this role does** - Understand how the organisation creates value - Map capabilities across processes, systems, and data - Identify inefficiencies and structural gaps - Design the future state - Define how systems should support operations - Build a roadmap aligned to business direction **Why it matters** Without this role: - Systems are configured around current problems - Projects optimise the wrong things - Roadmaps become reactive In many organisations, this responsibility is: - partially done by IT - partially by vendors - partially by business Which means it is **not truly owned by anyone**. **Real-world pattern** An organisation implements an ERP without clearly defining: - how procurement should work end-to-end - what good looks like for finance operations The system goes live… but simply digitises existing inefficiencies. ### **2. Implementation Team** **Delivery – Builds what was agreed** **What this role does** - Translate requirements into solutions - Configure systems - Manage timelines, risks, and stakeholders - Coordinate delivery - Test, train, and deploy Typical roles include: - Project Manager - Business Analyst - Change Manager - Testers and Trainers **Why it matters** Without delivery: - Strategy never becomes reality - Nothing changes But this role has a clear boundary: It is **temporary** They deliver the capability. They do not own it after go-live. **Real-world pattern** A well-run project: - Workshops completed - System configured - Users trained - Go-live achieved Everything looks successful. Yet, within months, issues begin to surface. Because delivery is not the same as value. ### **3. Product Owner (System Owner)** **Ownership – Ensures the system is used effectively** **What this role does** - Own the application (ERP, CRM, HR systems) - Manage enhancements and backlog - Ensure adoption across users - Provide ongoing support and training - Continuously improve system usage **Why it matters** Without this role: - Systems degrade over time - Users revert to manual workarounds - Features remain underutilised The system exists— but its value declines. **Real-world pattern** Post go-live: - Teams bypass workflows - Reports are inconsistent - Data quality drops A strong Product Owner: - corrects usage - refines configurations - reinforces adoption ### **4. Process Owner** **Ownership – Ensures the process delivers outcomes** **What this role does** - Own end-to-end business processes - Define how work should flow - Remove inefficiencies and bottlenecks - Align roles and responsibilities - Set and monitor KPIs - Drive continuous improvement **Why it matters** Without this role: - Process inefficiencies remain - Systems get blamed unnecessarily - Performance does not improve **Real-world pattern** A procurement system is implemented. But: - approvals remain slow - duplication still exists - accountability is unclear The system works. The process does not. ### **5. Capability Owner** **Control – Owns the outcome** This is the role most organisations are missing. **What this role does** - Own the end-to-end performance of a capability - Align system, process, and people - Track whether expected benefits are realised - Prioritise improvements across competing demands - Hold all roles accountable to outcomes **Why it matters** Without this role: - Ownership is fragmented - Improvements are localised - Value is never fully realised Everyone contributes. No one owns. **Real-world pattern** After an ERP implementation: - IT confirms the system is stable - The project team confirms delivery is complete - The business still struggles No one is accountable for closing this gap. A Capability Owner asks: - Are we faster? - Are we more efficient? - Are we reducing cost or effort? - Where is value leaking? ## **The Shift That Changes Everything** Most organisations focus on: - delivering projects - implementing systems - improving processes Very few focus on: **clear ownership of outcomes** ## **Final Thought** Capability development is not about more initiatives. It is about **clarity of roles and accountability**. When each role is clearly defined: - Design becomes intentional - Delivery becomes effective - Ownership becomes real - Value becomes measurable And most importantly: The organisation actually improves. ![Capability Development](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-03-30-093718-1024x757.jpg) --- --- title: "The Three Disciplines of an Organisation — And the One That Is Missing" url: "https://spsingh.me/the-three-disciplines-of-an-organisation/" lang: "en-AU" type: "post" description: "Most organisations believe they are well structured. They can clearly identify how work is divided, who owns what, and how decisions are made. But this clarity is only partial. In reality, every organisation operates across three distinct disciplines—yet only two" last_modified: "2026-03-27T00:40:56+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Three Disciplines of an Organisation — And the One That Is Missing" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Three Disciplines of an Organisation — And the One That Is Missing Most organisations believe they are well structured. They can clearly identify how work is divided, who owns what, and how decisions are made. But this clarity is only partial. In reality, every organisation operates across **three distinct disciplines**—yet only two are formally recognised. The Three Disciplines of an Organisation: | Discipline | What it Focuses On | Ownership Clarity | | --- | --- | --- | | IT | Systems and technology | Clear | | Business | Operations and service delivery | Clear | | Capability Development | Improvement of how the organisation works | Unclear / fragmented | This missing clarity is not a minor gap. It is the reason why organisations invest heavily in systems, projects, and change— yet struggle to get materially better. ## **IT — The Discipline of Stability and Control** **Why IT exists** IT exists to **enable and sustain the technology environment** of the organisation. It ensures: - Systems are available - Data is secure - Infrastructure is reliable - Technology aligns with architectural standards This is a **control function**. ### **How IT sees the organisation** IT views the organisation through a **systems lens**. It focuses on: - Platforms - Integrations - Architecture - Environments Its success is defined by: - Stability - Reliability - Controlled change If systems are implemented and running as designed, IT has succeeded. ### **Where IT stops** IT does not own: - Whether work becomes easier - Whether processes improve - Whether value is realised From its perspective, a system can be successful—even if the organisation struggles to use it effectively. Because IT is designed to **run systems—not redesign work**. ![Screenshot 2026 03 27 082348 SP Singh Blog](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-03-27-082348.jpg) ## **Business — The Discipline of Execution and Outcomes** ### **Why Business exists** Business exists to **deliver services and execute operations**. It ensures: - Work gets done - Customers are served - Targets are met - Operations continue This is an **execution function**. ### **How Business sees the organisation** Business views the organisation through an **outcomes lens**. It focuses on: - Tasks - Outputs - Deadlines - Customer needs Its success is defined by: - Delivery - Responsiveness - Throughput If work is getting done, Business is succeeding. ### **Where Business stops** Business does not own: - Structural design of processes - System alignment - Long-term capability uplift Instead, it adapts: - Creates workarounds - Solves problems locally - Prioritises immediate delivery Because Business is designed to **deliver within constraints—not redesign them**. ![Screenshot 2026 03 27 082924 SP Singh Blog](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-03-27-082924.jpg) ## **Capability Development — The Discipline That Should Exist** There is a third type of work happening in every organisation. It sits between IT and Business—but is owned by neither. ### **Why Capability Development exists** Capability Development exists to: **Systematically improve how value is created, delivered, and sustained.** It connects: - Strategy to execution - Systems to processes - People to outcomes This is a **design and improvement function**. ### **What Capability Development is responsible for** - Understanding business strategy in operational terms - Developing architecture and roadmaps for capability uplift - Designing processes, systems, data, and roles as an integrated whole - Governing system implementations from a value perspective - Driving continuous improvement - Ensuring adoption, training, and behavioural change - Coordinating across IT and Business - Embedding improvements into operations Its focus is: **Transformation, alignment, and long-term performance** ### **How Capability Development sees the organisation** It views the organisation as a **system of value creation**. It asks: - How does work flow end-to-end? - Where is value lost or delayed? - Are systems, processes, and roles aligned? - Are we improving over time—or repeating effort? ![Screenshot 2026 03 27 083958 SP Singh Blog](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-03-27-083958-1024x598.jpg) ## **The Structural Reality** Here is the critical insight: IT runs systems. Business runs operations. **No one owns how the organisation improves.** Capability Development work still happens. But it is fragmented across: - IT-led system implementations - Business-led process changes - PMO-led coordination - Consultant-led interventions Each contributes. No one integrates. ## **The Consequence: Fragmentation** When Capability Development is not formalised as a discipline, predictable patterns emerge. **1. Misalignment between systems and operations** Systems are implemented based on technical or vendor logic. Operations adapt around them. Alignment is assumed—but rarely achieved. **2. Poor adoption and wasted investment** Training is delivered. Systems go live. But: - Users revert to old ways - Workarounds emerge - Value remains unrealised **3. Continuous reinvention** The same problems reappear: - In different departments - In different systems - In different projects Because root causes are never structurally addressed. **4. Fragmented decision-making** Without a unifying discipline: - Decisions are inconsistent - Standards vary - Ownership is unclear Outcomes depend on individuals—not design. ## **Why This Is Hard to See** This problem persists because it is **structurally invisible**. - IT reports system success - Business reports operational success - Projects report delivery success All signals appear positive. But none answer the fundamental question: Are we improving how the organisation works? ## **The Strategic Implication** Capability Development cannot remain: - A project - A temporary transformation effort - A loosely defined initiative It must become a **formal discipline**. This requires: - Clear ownership - Defined architecture - Structured roadmap - Integrated governance across IT and Business ## **Link to the Broader Governance Problem** This is not an isolated issue. It directly reflects deeper structural gaps: - Fragmentation is a symptom of **unclear executive standards** - Lack of ownership is a **governance blind spot** - Absence of discipline leads to **predictable underperformance** This is where most ERP and transformation programs fail—not in execution, but in design. ## **Bottom Line** Most organisations are not failing. They are operating exactly as designed: - IT optimises systems - Business optimises delivery But no one is accountable for ensuring the organisation actually improves. And what is not clearly owned— will always remain fragmented. If you can see this clearly, you are already ahead of most organisations. Because the first step is not fixing the problem. The first step is **making it visible**. --- --- title: "The Missing Discipline in Most Organisations: Capability Development" url: "https://spsingh.me/capability-development/" lang: "en-AU" type: "post" description: "Most organisations are built around two clear disciplines. Business runs operations.IT runs systems. These are well understood.They have structure, ownership, budgets, and accountability. But there is a third responsibility that sits in every organisation—quietly, persistently, and often poorly managed. It" last_modified: "2026-03-26T04:06:05+00:00" categories: [The Sovereign Architect Series] custom_fields: cos_headline_text: "The Missing Discipline in Most Organisations: Capability Development" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Missing Discipline in Most Organisations: Capability Development Most organisations are built around two clear disciplines. **Business** runs operations. **IT** runs systems. These are well understood. They have structure, ownership, budgets, and accountability. But there is a third responsibility that sits in every organisation— quietly, persistently, and often poorly managed. It is the responsibility to **improve how the organisation works**. And in most organisations, no one truly owns it. ## **The Work That Everyone Does… But No One Owns** Think about the work required to make an organisation better: - Redesigning processes - Implementing ERP, CRM, or AI systems - Improving data and reporting - Standardising ways of working - Driving adoption and behavioural change - Removing inefficiencies and waste This is not Business-as-Usual. This is not IT infrastructure. This is **capability development.** **_Capability development is the disciplined design, alignment, and continuous improvement of an organisation’s processes, systems, data, roles, and behaviours to enhance how value is created, delivered, and sustained over time._** It is the mechanism through which strategy becomes executable, systems become useful, and operations become more efficient and effective. Yet, in most organisations, this work is fragmented: - IT leads system implementation - Business teams drive process changes - PMOs coordinate delivery - External consultants fill the gaps Each does their part. But no one owns the **end-to-end capability system**. ![Screenshot 2026 03 26 112200 SP Singh Blog](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-03-26-112200.jpg) ## The Consequence of Fragmentation When capability development is not treated as a discipline, predictable patterns emerge: - ERP programs become “IT projects” - Process redesign happens in isolation - Change management is reactive - Benefits are unclear or unrealised - The same problems reappear in different forms Organisations end up **working hard to change**, but not necessarily **getting better**. This is not due to lack of effort. It is due to lack of structure. ## **The Core Problem Is Not People—It Is Design** Most leaders assume: “We need better execution.” “We need better project management.” “We need the right system.” But these are symptoms. The underlying issue is simpler: The organisation has not defined **how capability development actually works**. Without this: - Decisions are inconsistent - Ownership is unclear - Standards vary - Outcomes depend on individuals And improvement becomes accidental rather than engineered. ## **Capability Development Is a Discipline** Capability development should sit alongside Business and IT as a **formal discipline**. Not as: - A project - A temporary transformation program - A loosely defined “initiative” But as a **structured, governed function** responsible for: - Designing how work should be performed - Aligning systems, processes, and roles - Governing implementation of change - Ensuring adoption and value realisation - Continuously improving organisational performance ## **A Simple Way to See It** Every organisation operates across three disciplines: **Business** Executes services and day-to-day operations **IT** Provides and maintains systems and technology **Capability Development** Designs and improves how the organisation works ![Screenshot 2026 03 26 120046 SP Singh Blog](https://spsingh.me/wp-content/uploads/2026/03/Screenshot-2026-03-26-120046-1024x652.jpg) ## **What Changes When This Is Defined** When capability development is treated as a discipline: - ERP is no longer “owned by IT”—it is governed as part of capability design - Process, system, and data decisions become integrated - Change is structured, not reactive - Benefits are tracked and realised - Improvement becomes repeatable, not dependent on individuals Most importantly: The organisation develops the ability to get better—consistently. ## **The Reality** Every organisation is trying to improve. Very few have designed **how improvement actually happens**. Until this is addressed: - Transformation will remain fragmented - Systems will underperform - And value will continue to leak quietly ## **Closing Thought** Organisations don’t fail because they don’t try to improve. They struggle because: > _Capability development exists everywhere… but nowhere as a defined discipline._ ![QuickReel Image Mar 26 2026 12 05 18 PM SP Singh Blog](https://spsingh.me/wp-content/uploads/2026/03/QuickReel-Image-Mar-26-2026-12_05_18-PM-1024x572.jpg) --- --- title: "The Results equation" url: "https://spsingh.me/the-results-equation/" lang: "en-AU" type: "post" description: "Numerous books, courses, and programs promise to teach us how to succeed and win the game we are in. Most offer tips, processes, and strategies—yet none can guarantee outcomes. Why? If someone has walked the path, followed principles, and applied" last_modified: "2026-03-25T13:38:00+00:00" categories: [Leadership] custom_fields: cos_headline_text: "The Results equation" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The Results equation Numerous books, courses, and programs promise to teach us how to succeed and win the game we are in. Most offer tips, processes, and strategies—yet none can guarantee outcomes. Why? If someone has walked the path, followed principles, and applied the right tactics, it seems success should be repeatable. That others could follow the same path and arrive at the same result. But it is not that simple. Let us look at the Results equation: **Results = f (Luck, Decisions, Environment)** Results are shaped by three forces—our decisions, the environment we operate in, and luck. We can learn how to make better decisions. But we cannot borrow someone else’s luck. Nor can we recreate the exact environment in which they succeeded. This is where most advice breaks down. It isolates decisions and ignores context. So, the path forward is different: - Be selective in what you adopt - Be humble about what you control - Be agile in how you respond There are no guarantees. But accepting this is not limiting—it is [grounding](https://spsingh.me/strength-emerges-from-balance/). It brings [clarity](https://bhaniconsulting.com/), keeps us close to reality, and allows us to navigate uncertainty with intent rather than illusion. --- --- title: "Strength emerges from balance" url: "https://spsingh.me/strength-emerges-from-balance/" lang: "en-AU" type: "post" description: "Strength is often mistaken for power — the ability to influence, control, or act at scale. The more power we have, the stronger we appear. But strength is not power alone. It is a coordinated force: Strength = f (Power," last_modified: "2026-03-24T13:49:16+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Strength emerges from balance" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Strength emerges from balance Strength is often mistaken for power — the ability to influence, control, or act at scale. The more power we have, the stronger we appear. But strength is not power alone. It is a coordinated force: **Strength = f (Power, Resilience, Bravery)** - **Power** — what we can do, and how far our influence extends - **Resilience** — what cannot break us; our capacity to absorb and continue - **Bravery** — what we are willing to lose; the risks we are prepared to take Strength emerges from balance. Power without resilience collapses under pressure. Resilience without bravery becomes passive endurance. Bravery without power turns into noise. To build strength, the [path is deliberate](https://spsingh.me/the-battle-between-status-quo-and-change/): - Expand capability and influence → build **power** - Reduce attachment to status, control, and possessions → build **resilience** - Take calculated risks where loss is possible but upside is asymmetric → build **bravery** Strength is not a standalone trait. It is a strategic composition — a system where power, resilience, and bravery are aligned and applied with intent. When they move together, [strength becomes leverage](https://bhaniconsulting.com/). --- --- title: "We are racing without direction" url: "https://spsingh.me/we-are-racing-without-direction/" lang: "en-AU" type: "post" description: "Achieving more is celebrated. Being content with less is quietly dismissed. Each year, we invest in more compute, more technology, more infrastructure. We find faster ways to extract, optimise, and scale. Economies are engineered to keep expanding—where even a slowdown" last_modified: "2026-03-23T13:52:12+00:00" categories: [Emerging Technologies] custom_fields: cos_headline_text: "We are racing without direction" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # We are racing without direction [Achieving more is celebrated](https://spsingh.me/individualism/). Being content with less is quietly dismissed. Each year, we invest in more compute, more technology, more infrastructure. We find faster ways to extract, optimise, and scale. Economies are engineered to keep expanding—where even a slowdown is treated as failure, and inflation becomes a tool to stretch the cycle. We are solving for efficiency faster than we are solving for meaning. And beneath this progress, there is an uncomfortable possibility: We are racing without direction. We push toward general and super intelligence, without clarity on what we will do with it. We automate work, without a clear answer for displaced livelihoods. We build systems that may transact with each other—while the role of humans becomes uncertain. These are not fringe questions. They are [foundational](https://bhaniconsulting.com/). But for now, they remain conveniently ignored. Optimism, incentives, and bias keep us moving forward—faster, harder, further. Not because we are certain of the destination… But because the system rewards motion, not meaning. --- --- title: "Build cultures where problems can surface early" url: "https://spsingh.me/build-cultures-where-problems-can-surface-early/" lang: "en-AU" type: "post" description: "Some problems have no clear solution. Yet, sharing them with people we trust gives us the strength to carry them. Some problems feel overwhelming—until we speak them out. A shift in perspective can dissolve them, like rock salt in water." last_modified: "2026-03-22T13:32:28+00:00" categories: [Organisation Culture] custom_fields: cos_headline_text: "Build cultures where problems can surface early" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Build cultures where problems can surface early Some problems have no clear solution. Yet, sharing them with people we trust gives us the strength to carry them. Some problems feel overwhelming—until we speak them out. A shift in perspective can dissolve them, like rock salt in water. Others seem too complex to solve alone. But once shared, new angles emerge. What felt tangled becomes manageable. Many problems don’t need solving first—they need surfacing. What it takes is [courage](https://spsingh.me/individualism/): to move past shame, vulnerability, and hopelessness. What it requires is trust: the right people, and the right environment. [As leaders](https://bhaniconsulting.com/), this is not optional. We must build cultures where problems can surface early, thinking becomes collective, and solutions emerge faster. --- --- title: "Individualism" url: "https://spsingh.me/individualism/" lang: "en-AU" type: "post" description: "Family, community, organisation, tribe, nation—these are human constructs that give us meaning, structure, and shared direction.They align us to coordinate and play a common game. They keep us engaged, create stability, and carry values across generations. For millions of years," last_modified: "2026-03-21T13:51:01+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Individualism" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Individualism Family, community, organisation, tribe, nation—these are human constructs that give us meaning, structure, and shared direction. They align us to coordinate and play a common [game](https://spsingh.me/the-battle-between-status-quo-and-change/). They keep us engaged, create stability, and carry values across generations. For millions of years, these structures have propelled civilisation forward. But look deeper—these structures are not designed to maximise individual happiness. They exist to organise, sustain, protect, and pass forward what we build. Now, there is a quiet force weakening them: individualism. Individualism centres on personal happiness. In that pursuit, we consume more, sacrifice less, and constantly ask: _What’s in this for me?_ And slowly, without noise, the structures begin to weaken. Families lose cohesion. Organisations lose alignment. Communities lose identity. Not because they are attacked— but because they are no longer prioritised. So, what can we do? First, recognise the pattern. Awareness is the starting point. Second, anchor our associations in a compelling vision—something larger than individual gain. Third, [lead through action](https://bhaniconsulting.com/), not words. No speeches—just example. And above all, accept this: individualism is not an exception—it is the default of our time. The real question is not whether it exists— but whether we are willing to sacrifice enough to hold something together. --- --- title: "The game orchestration problem" url: "https://spsingh.me/game-orchestration-problem/" lang: "en-AU" type: "post" description: "Why do some organisations transform successfully while others keep failing? Yes — leadership matters.But what exactly within leadership? Why do some Executive Sponsors succeed while others struggle? Yes — capability matters.But which capability actually moves the needle? It’s this: The" last_modified: "2026-03-20T13:33:32+00:00" categories: [Project Sponsorship] custom_fields: cos_headline_text: "The game orchestration problem" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The game orchestration problem Why do some organisations transform successfully while others [keep failing](https://spsingh.me/why-do-business-systems-turn-into-a-mess/)? Yes — leadership matters. But _what exactly_ within leadership? Why do some Executive Sponsors succeed while others struggle? Yes — capability matters. But _which capability actually moves the needle?_ It’s this: The ability to **see the game behind the game**. Strong leaders don’t just manage plans, budgets, or milestones. They read incentives. They see: - what vendors are really optimising for - what staff are protecting - what consultants are incentivised to deliver - what other executives are quietly resisting They cut through the noise and focus on **signals that actually matter**. Then they act: - reshape the narrative to align people - adjust incentives to drive the right behaviour - redirect energy where it creates momentum - and when needed, change the game for those not contributing Transformation is not a delivery problem. It is a **game orchestration problem**. And the [leaders who win](https://bhaniconsulting.com/)… are the ones who can see it clearly. --- --- title: "The battle between Status Quo and Change" url: "https://spsingh.me/the-battle-between-status-quo-and-change/" lang: "en-AU" type: "post" description: "The battle between Status Quo and Change is never won on a single front. To win, leaders must start with clarity—a sharp objective and a narrative strong enough to move people against the Status Quo. That narrative must align leadership" last_modified: "2026-03-19T13:16:58+00:00" categories: [Change Management] custom_fields: cos_headline_text: "The battle between Status Quo and Change" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # The battle between Status Quo and Change The battle between Status Quo and Change is never won on a single front. To win, leaders must start with clarity— a sharp objective and a narrative strong enough to move people against the Status Quo. That narrative must align leadership as one front. No energy wasted inward. No competing agendas. All focus directed where it belongs—against the real resistance. Then comes execution: A grounded plan. Capable people. Committed funding. Visible support where the work actually happens. And then—culture. The discipline to persist. The ability to adapt. The coordination to keep moving, even when momentum fades. [Sound heavy](https://spsingh.me/every-solution-carries-an-invisible-load/)? It is. Yet most transformation efforts underestimate this. They reduce it to systems, timelines, and vendors. But [transformation](https://bhaniconsulting.com/) is not a project. It is a campaign against the Status Quo. If leaders stay anchored in technology alone, the Status Quo doesn’t lose. It quietly wins. --- --- title: "Gap between decisions and outcomes" url: "https://spsingh.me/gap-between-decisions-and-outcomes/" lang: "en-AU" type: "post" description: "When the gap between decisions and outcomes spans years, learning breaks down.We don’t revisit what we decided or why. So we repeat the same patterns — same biases, same choices, same results. In response, organisations reshuffle teams, replace people, and" last_modified: "2026-03-18T13:47:54+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Gap between decisions and outcomes" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Gap between decisions and outcomes When the gap between decisions and outcomes spans years, learning breaks down. We don’t revisit what we decided or why. So we repeat the same patterns — same biases, same choices, same results. In response, organisations reshuffle teams, replace people, and hope for a different outcome. But people are not the constraint. Poor decisions are. If the inputs are flawed — unclear assumptions, weak logic, ignored risks — then even the best people are set up to fail. Changing the team won’t change the trajectory. So what can we do? Introduce a **[decision log](https://spsingh.me/designing-a-system-where-the-right-things-happen-by-design/)**. Document each key decision with: - Context and objectives - Assumptions made - Conditions at the time - Options considered - Risks acknowledged - Expected outcomes This creates a baseline. Over time, you can revisit decisions, compare intent vs reality, and refine how decisions are made — not just what decisions are made. [Better decisions compound.](https://bhaniconsulting.com/) And so do poor ones — unless you make them visible. --- --- title: "Every solution carries an invisible load" url: "https://spsingh.me/every-solution-carries-an-invisible-load/" lang: "en-AU" type: "post" description: "When evaluating solutions, it is dangerously easy to fall in love with the outcome and ignore what it takes to get there. A gym membership is not $100 a week and a better physique.It is discipline, time, consistency, learning, setbacks," last_modified: "2026-03-17T13:29:24+00:00" categories: [Project Sponsorship] custom_fields: cos_headline_text: "Every solution carries an invisible load" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Every solution carries an invisible load When evaluating solutions, it is dangerously easy to fall in love with the outcome and ignore what it takes to get there. A gym membership is not $100 a week and a better physique. It is discipline, time, consistency, learning, setbacks, and persistence. The result is not purchased — it is earned. The same illusion plays out in ERP decisions. We compare features. We build business cases. We justify cost vs benefit. But the real investment sits beneath the surface — employee time, change resistance, communication effort, testing cycles, process redesign, and ongoing governance. This is the work that determines success. Every solution carries an invisible load — the unwritten assumptions about effort, behaviour change, and organisational maturity. Ignore it, and even the best system will fail to deliver. Most [ERP failures](https://spsingh.me/why-do-business-systems-turn-into-a-mess/) are not technology failures. They are underestimation failures. You will never model every scenario — and you don’t need to. But you must [evaluate the full picture](https://bhaniconsulting.com/). Not just what you get. But what it takes. --- --- title: "Why do business systems turn into a mess over time?" url: "https://spsingh.me/why-do-business-systems-turn-into-a-mess/" lang: "en-AU" type: "post" description: "Why do business systems turn into a mess over time? When organisations keep investing in technology, one side effect is that their technology landscape becomes increasingly complex. Systems grow, integrations multiply, and processes evolve. Over time, what once looked simple" last_modified: "2026-03-16T13:46:18+00:00" categories: [Project Sponsorship] custom_fields: cos_headline_text: "Why do business systems turn into a mess over time?" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Why do business systems turn into a mess over time? **Why do business systems turn into a mess over time?** When organisations keep investing in technology, one side effect is that their technology landscape becomes increasingly complex. Systems grow, integrations multiply, and processes evolve. Over time, what once looked simple begins to feel chaotic. There are many reasons for this. But one of the biggest is the absence of architecture. Imagine building a house with no architect. Everyone involved has complete freedom to design whatever they like. One room here, another extension there, a staircase added later, a wall removed somewhere else. Very quickly, the house becomes strange, inefficient, and difficult to live in. Business systems are no different. ERP, CRM, integrations, reporting tools, automation platforms — they are all parts of the same digital house. Without a guiding architecture, every team optimises for its own needs. Decisions are made based on urgency, convenience, or personal preference. Over time the structure loses coherence. [Architecture prevents this](https://spsingh.me/protecting-digital-assets/). It introduces principles, structure, and decision pathways. Technology decisions stop being emotional or personal. Instead, they follow a defined process and align with a broader design. Architecture is not an optional discipline anymore. It is the [foundation](https://bhaniconsulting.com/) of modern digital systems. Without it, complexity is guaranteed. --- --- title: "I don’t care!" url: "https://spsingh.me/i-dont-care/" lang: "en-AU" type: "post" description: "“I don’t care.”Or a version of it — “Who cares?”“I don’t give a …” We say these words more often than we realise.Sometimes even with pride — enjoying the sense of freedom that comes with them. But there is something" last_modified: "2026-03-15T12:21:20+00:00" categories: [Leadership] custom_fields: cos_headline_text: "I don’t care!" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # I don’t care! **“I don’t care.”** Or a version of it — _“Who cares?”_ _“I don’t give a …”_ We say these words more often than we realise. Sometimes even with pride — enjoying the sense of freedom that comes with them. But there is something hidden inside those words. When we say _“I don’t care,”_ we quietly surrender our connection to that thing. The other side — the event, the person, the issue, the decision — also stops caring about us. This imagined detachment may feel liberating for a moment. Yet it can slowly create damage, grief, or despair. Because the moment we stop caring, we lose visibility. We lose influence. We lose the ability to shape the outcome. This applies everywhere around us: our employees’ behaviour, our boss’s attitude, our [company](https://bhaniconsulting.com/) culture, our relationships, our customers’ expectations. The list never ends. The words _“I don’t care”_ may feel like freedom. But often they are simply quiet resignation. So perhaps the better discipline is this: Don’t casually declare that you don’t care. Instead, be [intentional about](https://spsingh.me/true-leaders/) **what you truly choose not to care about.** Because indifference, when used carelessly, disconnects us from the very things we may later wish we had shaped. --- --- title: "Life can feel unbearable" url: "https://spsingh.me/life-can-feel-unbearable/" lang: "en-AU" type: "post" description: "Life can feel unbearable when my focus stays only on myself. My problems begin to look larger than they truly are, and it feels as if there is no way out. But something changes when I lift my eyes and" last_modified: "2026-03-14T15:02:53+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Life can feel unbearable" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Life can feel unbearable Life can feel unbearable when my focus stays only on myself. My problems begin to look larger than they truly are, and it feels as if there is no way out. But something changes when I lift my eyes and look around. I start to notice people carrying burdens far heavier than mine. Slowly, I begin to count the blessings I had forgotten. I may still be a victim of bad luck. My pain may be real, and it may hurt deeply. Yet sometimes there is little I can change about the situation itself. What I can [change is the way I see it.](https://bhaniconsulting.com/) When I [shift my view](https://spsingh.me/know-the-role-you-have-been-given/), the same world begins to look different. A wider horizon appears. New perspective quietly replaces the weight I was carrying. Sometimes nothing around us changes. Only the way we look at it does. And that alone can ease the pain we were holding. --- --- title: "Battles are not won merely by applying brute force" url: "https://spsingh.me/battles-are-not-won-merely-by-applying-brute-force/" lang: "en-AU" type: "post" description: "Battles are not won merely by applying brute force.Brute force works only occasionally — usually when the opponent is much weaker. Most battles are won by changing the variables so that the outcome begins to favour us.That is strategy first," last_modified: "2026-03-13T16:45:34+00:00" categories: [Leadership] custom_fields: cos_headline_text: "Battles are not won merely by applying brute force" cos_seo_score: 0 cos_headline_score: 0 ig_es_is_post_notified: 1 --- # Battles are not won merely by applying brute force Battles are not won merely by applying brute force. [Brute force](https://spsingh.me/power-is-a-tool/) works only occasionally — usually when the opponent is much weaker. Most battles are won by changing the variables so that the outcome begins to favour us. That is strategy first, followed by strength and resilience. The same applies inside organisations. When we challenge the status quo, we often face change resistance. Our instinct is to push harder — more persuasion, more meetings, more pressure. But resistance rarely dissolves through force alone. A better approach is to change the variables that are feeding the resistance. Take a common example: one department refuses to adopt a new system. Rather than exhausting energy trying to convince them, migrate other departments first. As the rest of the organisation moves forward, the environment changes. The remaining department finds itself operating in a different reality — and resistance naturally weakens. Change is rarely won head-on. More often, it is won by changing the conditions around the battle. Change management is therefore less about force — and far more about [strategy.](https://bhaniconsulting.com/) ---