[{"data":1,"prerenderedAt":129},["ShallowReactive",2],{"article-bad-scoping":3},{"id":4,"title":5,"accentColor":6,"body":7,"category":14,"coreIdea":15,"crossLink":18,"ctaBody":23,"ctaLinkText":24,"ctaLinkTo":25,"datePublished":26,"description":11,"extension":27,"headline":28,"headlineAccent":29,"heroParagraph":30,"meta":31,"navigation":32,"ogDescription":33,"ogTitle":34,"path":35,"publishedAt":36,"readTime":37,"sections":38,"seo":101,"seoDescription":102,"seoTitle":103,"sidebarLink":104,"stem":106,"summaryCards":107,"tags":123,"teaser":127,"__hash__":128},"articles\u002Farticles\u002Fbad-scoping.md","Bad Scoping","teal",{"type":8,"value":9,"toc":10},"minimark",[],{"title":11,"searchDepth":12,"depth":12,"links":13},"",2,[],"Scoping",{"heading":16,"body":17},"The brief is a starting point, not an answer.","Clients describe what they want. Rarely what they need. The gap between the two is usually where the expensive mistakes happen - and it closes during scoping, not during the build.",{"accentColor":6,"label":19,"title":20,"description":21,"linkText":19,"linkTo":22},"How we work","Scope first. Build carefully. Support long term.","Our scoping process is described in the 'How we work' section - it is the most important part of how we engage with every project.","\u002Fabout","If you have a brief for a piece of software and want to know whether it describes the right problem, we can work through it - no lengthy proposal before we understand your situation.","Start a conversation","\u002Fcontact","2026-06-09","md","Most software projects fail before the build starts.","Here's why.","The brief described a solution. The team built it. Six months later, the software did exactly what was asked - and did not fix what was wrong. Because what was asked and what was wrong were not the same thing.",{},true,"Most custom software failures are not technical failures. They are failures of problem definition - and the fix happens before a line of code is written.","Why Good Scoping Matters More Than Good Code","\u002Farticles\u002Fbad-scoping","June 2026","6 min read",[39,45,56,80,91],{"id":40,"navLabel":41,"paragraphs":42},"intro","The core problem",[43,30,44],"Custom software projects that fail almost never fail because of bad code. They fail because the problem was not understood properly before the build started.","This pattern is not a failure of intent. The client described their problem as clearly as they could. The development team built what they were told. The failure was in the process between those two things - the stage where the real problem should have been understood before any design began.",{"id":46,"navLabel":47,"pillLabel":48,"pillColor":6,"heading":49,"paragraphs":50},"why-briefs-mislead","Why briefs mislead","The gap","Why briefs almost always describe the wrong thing.",[51,52,53,54,55],"People describe problems in terms of solutions. It is natural. When something is frustrating, the mind moves quickly to what would fix it. But the first solution that comes to mind is usually a solution to the symptom, not the cause.","\"We need a reporting dashboard\" - but the actual problem is that nobody agrees on which numbers are correct. Building a dashboard does not fix the underlying data conflict; it surfaces it more visibly.","\"We need a mobile app\" - but the actual constraint is that two back-end systems do not talk to each other. A mobile app built on top of disconnected data is still disconnected.","\"We need this feature added\" - but the feature is a workaround for a broken process. The software is now being asked to permanently encode the workaround rather than fix the process.","In each case, the client brief is accurate - it describes something they actually need. The problem is that it is not the right starting point for a build.",{"id":57,"navLabel":58,"pillLabel":59,"pillColor":60,"heading":61,"paragraphs":62,"items":64},"five-mistakes","Five scoping mistakes","What goes wrong","lime","Five scoping mistakes we see most often.",[63],"These are not mistakes made by bad clients or careless developers. They are structural failures that occur when the scoping process is treated as a formality rather than the most important part of the project.",[65,68,71,74,77],{"title":66,"body":67},"Treating the brief as a specification","The brief describes what the client wants. A specification describes what needs to be built. Moving from one to the other is the job of scoping - skipping it means building from an incomplete picture.",{"title":69,"body":70},"Skipping process mapping","How does the work actually flow today? Where does it break down? What are the edge cases? What must not be lost when the new system goes live? If you have not mapped the current process in detail, you are building a replacement for something you do not fully understand.",{"title":72,"body":73},"Not surfacing constraints early","Every project has hard constraints: legacy systems that cannot be replaced, regulatory requirements, data that does not exist in the format assumed, third-party integrations with undocumented behaviour. Finding these at week ten is far more expensive than finding them at week one.",{"title":75,"body":76},"Assuming the happy path is the whole path","Software that works perfectly for the standard case and fails at the edge cases is not finished. Edge cases are where operations break down. Discovering them in production is the most expensive way to learn about them.",{"title":78,"body":79},"Not agreeing on what success looks like","If success is not defined before the build starts, it will be defined after it finishes - by whoever is most dissatisfied with the outcome. Agreeing on measurable outcomes upfront gives the build a fixed target.",{"id":81,"navLabel":82,"pillLabel":83,"pillColor":6,"heading":84,"paragraphs":85},"what-proper-scoping-looks-like","What proper scoping looks like","The approach","What proper scoping actually looks like.",[86,87,88,89,90],"Proper scoping is not a discovery workshop. It is not a questionnaire. It is a structured process of understanding the real problem before any solution is designed.","It starts with process mapping: how does work flow through the business today? Not the official version - the real version, including the workarounds, the exceptions, and the parts that only one person knows how to handle. This surfaces the things the brief did not mention, because the client has lived with them so long they have stopped noticing them.","It continues with constraint identification: what are the hard limits? What systems need to integrate? What data exists and in what form? What cannot change, and what must the new system accommodate?","It ends with outcome definition: what does success look like, specifically? What should the system do that the current process cannot? What should it stop requiring people to do by hand? What measurable change in the operation will confirm that the build solved the right problem?","This work takes time. It slows the start of the build. It also dramatically reduces the cost of the build - and the probability that the software delivers something useful.",{"id":92,"navLabel":93,"pillLabel":94,"pillColor":95,"heading":96,"paragraphs":97},"the-uncomfortable-bit","The uncomfortable part","Honest take","blue","The uncomfortable part of doing this properly.",[98,99,100],"Good scoping sometimes produces an uncomfortable finding: the thing the client asked to build is not the thing that will fix the problem. Or it will fix part of the problem - but the more important problem is elsewhere.","This conversation is easier to have before the build starts than after. It is also the conversation that determines whether a project ends with software that works and a problem that is solved - or software that works and a problem that remains.","We are not a feature factory. Before we design anything, we map the real process. The brief is the starting point. The job of scoping is to find out what it is not saying.",{"description":11},"Custom software projects fail when the problem is not understood before the build starts. Five scoping mistakes SA businesses make - and what proper scoping actually looks like.","Why Good Scoping Matters More Than Good Code | Sharp Software Solutions",{"text":105,"to":25},"Scope a project with us","articles\u002Fbad-scoping",[108,113,118],{"label":109,"value":110,"body":111,"icon":112,"accentColor":6},"The problem","Wrong problem, working software","A project can deliver exactly what was asked and still not fix what was wrong.","i-lucide-triangle-alert",{"label":114,"value":115,"body":116,"icon":117,"accentColor":60},"Where it goes wrong","The brief as the answer","Treating the brief as a specification rather than a starting point is the most common scoping mistake.","i-lucide-file-text",{"label":119,"value":120,"body":121,"icon":122,"accentColor":95},"The fix","Map the real process first","Proper scoping surfaces the things that sink a build - before the build starts, not halfway through it.","i-lucide-check-circle",[14,124,125,126],"Custom Software","Operations","Project Delivery","Most custom software failures are not technical failures. They are failures of problem definition. The brief described a solution, the team built it - and six months later, the software worked and did not fix what was wrong.","76RGCUjP90z3a9vpS-vsyvjTpaCMi-qUQCroQe-8M8k",1782825462953]