[{"data":1,"prerenderedAt":49},["ShallowReactive",2],{"blog-post-el-proyecto-que-se-extendio-tres-meses-mas-de-lo-planeado-lo-que-aprendi-de-ese-error-en-us":3},{"id":4,"title":5,"slug":6,"cover_image":7,"cover_image_credit":8,"cover_image_credit_url":9,"excerpt":10,"content":11,"content_json":12,"sources":37,"category":38,"read_time_minutes":39,"is_featured":40,"author":41,"meta_title":42,"meta_description":43,"meta_keywords":44,"is_published":45,"published_at":46,"created_at":47,"updated_at":48},59,"The Project That Ran Three Months Longer Than Planned. What I Learned From That Mistake.","el-proyecto-que-se-extendio-tres-meses-mas-de-lo-planeado-lo-que-aprendi-de-ese-error","https:\u002F\u002Fimages.unsplash.com\u002Fphoto-1454165804606-c3d57bc86b40","Photo by Scott Graham on Unsplash","https:\u002F\u002Funsplash.com\u002F@homajob","Software projects don't fail because of the code. They fail because of conversations that weren't had in time. This is the most uncomfortable story I've told about ProjectApp.","",{"cta":13,"intro":14,"sections":15,"conclusion":36},"If you have a software project that feels like it's not advancing or losing direction, that conversation interests me. Sometimes an external diagnosis identifies in days what internally has been unclear for weeks.","I'm going to tell something that service company founders rarely tell publicly: the story of a project that went wrong. Not because the team was bad. Not because the technology failed. But because there were decisions not made in time, conversations postponed to avoid discomfort, and a scope that grew silently until the project never ended. That project ran three months longer than planned. It was one of ProjectApp's hardest experiences. And the one that taught us the most.",[16,22,29],{"quote":17,"content":20,"heading":21},{"text":18,"author":19},"Scope creep doesn't arrive all at once. It arrives in small doses, each one reasonable enough that you don't say no.","The most expensive lesson we paid in that project","The project started with good diagnosis, defined scope, and clear dates. The first weeks went well. But at some point something started happening that is one of the most common and most silent patterns in software development: scope creep. The scope kept growing. A feature that 'wasn't in the original plan but was small.' A new module that 'made sense because we'd need it anyway.' An integration that 'was fundamental and hadn't been considered.' Each addition, individually, seemed reasonable. Together, they tripled the original scope without anyone making an explicit decision to do so.","How It Started Well and Slowly Changed",{"callout":23,"content":27,"heading":28},{"text":24,"type":25,"title":26},"When a project goes more than two weeks without a new functional demo, or when the team says 'almost done' for the third consecutive week, something isn't working in scope management. That's the moment to have the difficult conversation — not to wait.","warning","The Most Important Warning Signal","Here's the part that was hardest to accept: the project didn't run long because the client asked for impossible things. It ran long because I didn't have the difficult conversation in time. Every time a new request appeared outside the original scope, the right response was: 'This isn't in scope. We can do it, but it means adjusting time or price.' I avoided that conversation more times than I should have. To not create friction. Believing we could absorb it. Out of optimism about timelines. The result was a project that never ended, an exhausted team, and a client who also lost clarity about what they expected.","The Conversation I Didn't Have in Time",{"heading":30,"key_takeaways":31},"Key Takeaways",[32,33,34,35],"Software projects don't fail because of code. They fail because of conversations that weren't had in time.","Scope creep arrives in small, reasonable doses. Each addition seems innocent until together they tripled the original scope.","The difficult conversation about scope and expectations is always cheaper when had early.","A project with weekly demos and active scope management finishes. A project without them has no real end date.","That project that ran three months long was expensive in time, energy, and the trust that had to be rebuilt with the client. But it was the one that most clearly showed us where the gaps were in our methodology. Today, every project at ProjectApp has explicit scope, mandatory weekly demos, and a change protocol that protects both client and team. Not because we're perfect. But because we learned firsthand what it costs not to have them.",[],"guides",7,false,"projectapp-team","Why Software Projects Fail: The Story of the Project That Ran 3 Months Over","Software projects don't fail because of code. They fail because of conversations not had in time. The most honest story I've told about ProjectApp.","software projects fail colombia, scope creep software development, software project management, why software fails, software development lessons",true,"2026-05-07T16:13:00Z","2026-05-07T04:13:53.041714Z","2026-05-07T04:13:53.041722Z",1784937870591]