Challenges Teams Face in the Software Development Lifecycle

I’ve been working as a contractual Program/Project Manager on complex projects for the past 7 years, most of which followed Agile methodologies. While the Software Development Life Cycle (SDLC) is designed to reduce risk, poor implementation can have the opposite effect. If not executed properly, it significantly increases the risk of project failure. Here’s a quick ranking of critical failure points that commonly derail software projects: 🔴 1. Unclear or Changing Requirements Poorly defined needs or constant scope changes break alignment early and often. ✅ Fix: Involve stakeholders early, use user stories and clarify DoD (definition of done), and validate frequently; another advice: make sure to define change request in the initial contract with the client. 🔴 2. Inadequate Planning & Estimation Unrealistic timelines or budgets create pressure that leads to shortcuts and burnout. ✅ Fix: Buffer for unknowns, involve tech leads in estimation. 🟠 3. Ineffective Communication Team silos and misalignment cause costly rework and delays. ✅ Fix: Daily stand-ups, shared documentation, clear ownership. The tech team needs to understand the functional requirement to be able to implement it technically. 🟠 4. Weak Design & Architecture Hasty or shortsighted technical decisions lead to rework and scalability issues. ✅ Fix: Involving a software architect who could support drafting the best scalable architecture choices within the available projects needs, constraints and budget 🟠 5. Insufficient Testing & QA Testing cut short = bugs in production, bad UX, security holes. ✅ Fix: Invest in a QA strategy to identify tests to be run by type of release, and automate critical time-consuming tests 🟡 6. Lack of Stakeholder Involvement Software built in isolation rarely meets business goals. ✅ Fix: Demo regularly (ideally after each milestone), build feedback into the cycle. 🟡 7. Poor Change & Config Management Inconsistent environments and chaotic updates derail progress. ✅ Fix: Version control, CI/CD, and clear change protocols. 🟡 8. Inadequate Risk Management Unexpected issues become blockers when risks aren't flagged early. ✅ Fix: Ongoing risk logs, contingency planning. 🟢 9. Neglecting Post-Launch Support No plan for support = user churn and poor adoption. ✅ Fix: Monitor performance, address issues fast. 🟢 10. Lack of DevOps & Automation Manual processes delay releases and increase error rates. ✅ Fix: Embrace CI/CD and infrastructure-as-code. Strong software isn’t just about great code—it’s about clarity, communication, and continuous feedback. A strong Project Manager implements the right processes and follows each step methodically to spot weak links early and address them proactively. And when issues do arise (as they often do), they stay calm, communicate transparently, and ensure all stakeholders remain aligned throughout the journey. #SoftwareDevelopment #SDLC #TechLeadership #ProjectManagement #Agile #DevOps #ProductDelivery

As a Fractional CTO across many businesses over the years, here are some of the common issues I find in engineering organizations and tech stacks: 𝗟𝗮𝗰𝗸 𝗼𝗳 𝗔𝗹𝗶𝗴𝗻𝗺𝗲𝗻𝘁 𝗯𝗲𝘁𝘄𝗲𝗲𝗻 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗮𝗻𝗱 𝗧𝗲𝗰𝗵 𝗚𝗼𝗮𝗹𝘀 → Engineering teams are often working in silos. → Business objectives get lost in translation. 💡Solution: Regular syncs between engineering and business teams to ensure alignment. 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁 𝗔𝗰𝗰𝘂𝗺𝘂𝗹𝗮𝘁𝗶𝗼𝗻 → Quick fixes and hacks lead to longterm issues. → Scaling becomes a nightmare due to accumulated debt. 💡Solution: Implement a strategy to pay down technical debt incrementally. 𝗜𝗻𝗮𝗱𝗲𝗾𝘂𝗮𝘁𝗲 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 → New hires struggle to get up to speed. → Knowledge is often tribal and not formally captured. 💡Solution: Invest in comprehensive documentation from the getgo. 𝗢𝘃𝗲𝗿𝗹𝘆 𝗖𝗼𝗺𝗽𝗹𝗲𝘅 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀 → Engineers often overengineer solutions. → Complexity leads to more bugs and slower development. 💡Solution: Aim for simplicity and clarity in your tech stack. 𝗣𝗼𝗼𝗿 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗖𝗵𝗮𝗻𝗻𝗲𝗹𝘀 → Teams often rely on inefficient methods for updates. → Important information gets lost or delayed. 💡Solution: Encourage sharing information early and often (and reward people for raising issues versus shooting the messenger). 𝗜𝗻𝘀𝘂𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗮𝗻𝗱 𝗤𝗔 → Bugs make it to production far too often. → Customer experience suffers as a result. 💡Solution: Invest in QA automation tools and build your tests to run automatically once versus manually testing everything with your QA team and Dev team every release. 𝗟𝗮𝗰𝗸 𝗼𝗳 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 → Tech evolves rapidly, but teams often don't. → Skills and knowledge become outdated quickly. 💡Solution: Foster a culture of continuous learning and improvement. 𝗜𝗻𝗳𝗹𝗲𝘅𝗶𝗯𝗹𝗲 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸𝘀 → Older technologies often hinder innovation. → Migration to new stacks is seen as too disruptive. 💡Solution: Plan for gradual migration to more flexible technologies. 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗢𝘃𝗲𝗿𝘀𝗶𝗴𝗵𝘁𝘀 → Security is often an afterthought. → Vulnerabilities can lead to significant business risks. 💡Solution: Make security a foundational aspect of your development lifecycle and build it into your deployment pipeline. 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝗖𝗼𝗻𝘀𝘁𝗿𝗮𝗶𝗻𝘁𝘀 → Teams are often under resourced. → Leads to burnout and turnover. 💡Solution: Track metrics like team velocity and apply pragmatism to workload assigned each sprint or development cycle. These issues are common but solvable. What challenges have you faced in your engineering organization? Let’s discuss!

40-60% of your engineering delivery time is lost to handovers and coordination waste. Not to coding. Not to testing. Not to requirements. To waiting, asking, aligning, and passing work between people. The DevOps Handbook and Lean Software Development research make this painfully clear. Your biggest delivery bottleneck isn't technical complexity. It's the space between people. Here's what most organizations do: They add more process. More meetings. More documentation. More alignment rituals. And they wonder why things get slower instead of faster. What actually works? Eliminating the handovers entirely. Concurrent product development puts all the bright people working on the same thing, at the same time, in the same place. Requirements analysis, coding, testing, and documentation happen simultaneously, not sequentially. No waiting for specs. No waiting for code. No waiting for test results. No waiting for documentation. The Three Amigos approach (business analyst, developer, tester) working together in real-time on the same problem creates something you can't get any other way: shared understanding that doesn't need to be written down and handed off. The result? Teams that apply true concurrent development report what used to take 3 weeks being completed in a single day. Same people. Same skills. Radically different approach to how work flows between them. What percentage of your team's time is spent waiting for someone else? #ContinuousDelivery #TDD #ProductDevelopment

When you ask a company how they work, within the first two minutes someone will point to an intent tree. Three-year goals → one-year goals → strategic pillars → OKRs → initiatives → epics → work items. Useful… but absolutely not the full picture A few examples of what gets completely obscured in these trees: 1. How influence actually flows Two companies can have the exact same tree, but in one the teams genuinely shape strategy...and in the other teams are stuck at the bottom executing whatever comes down. 2. The shape and size of work “Key initiative” means something totally different when it involves 2.5 tribes for 12–20 weeks vs 1 tribe for 2–4 weeks. Same label, wildly different collaboration patterns 3. Shared teams and competing priorities Every department saying their request is P0 doesn’t mean the cost of delay is the same. Separate budgets create totally different outcomes than shared prioritization. A tree will never show this. 4. Dependency structure Two teams can be pointed at the same metric. One has minimal dependencies and experiments weekly. The other requires a giant coordinated rollout with multiple handoffs. On the tree, both look identical. 5. Type of team, type of bet A “program” looks neat in a hierarchy, but the reality is new-offering teams, growing teams, margin-optimizing teams, sustaining teams...they all work differently and produce different shapes of work. 6. Cross-cutting business + tech realities Three business segments with separate P&Ls + one shared R&D pool + shared product/platform teams = a completely different operating challenge than a tidy functional tree suggests. 7. The revenue chain is uneven A checkout-conversion team has a direct, clean line to revenue. A design-system team is essential but connects to revenue through several hops. A tree won’t show the real path between work and value. 8. Overlapping vs. diverging perspectives Intent, funding, value chain, collaboration patterns sometimes overlap neatly. More often, they drift apart as companies scale. That's the challenge Intent graphs/trees are helpful, but they’re only a small part of the picture. Most of the real operating model is in the relationships, interfaces, funding flows, dependencies, team types, and context collisions the tree doesn’t capture. That's what we try to model at Dotwork, and why custom fields and labels just don't cut it.

Not all communication is equal. Most software developers and management will argue vigorously the opposite. #DDDesign #ConwaysLaw #TeamTopologies 1. A puzzling take on team communication is that some subset of people on a team of any size must communicate well, while another subset doesn't. 2. Another puzzling idea is that everyone on the team will achieve sense giving and sense reading on the same level. (Although few would actually know what sense giving and sense reading are.) 3. There's also the practice of management forming teams and selecting team members in a vacuum, arbitrarily, with no feedback from technical leaders. 4. There's the extreme opposite of 3, that of full self-selection of teams. The first two of these are not true. Sure, humans and sometimes agree on where to eat lunch or the colors for a team room. Yet, agreeing on the same mental model of a complex software problem and solution just won't easily or even simply happen. Every single person, even identical twins, have different default concepts and heuristics, because they've all learned and experienced things differently and separately. Besides that some blank out on audible or visual, or at least favor one over the other. It takes a lot of careful communication, which is not only audible or written. It requires visualization of concepts, example scenarios written and visual, and patient reputation. The second pair of assumptions are likewise nearsighted. While point 3 is the worst of the two, even team self-selection can lead to deficiencies. One team with a lot of experience and skill could self-select on a clear or complicated problem, while another team could self-select and be ill-equiped to solve a complex problem. Note: Some highly skilled developers work on low-complexity problems so they can introduce complex technical mechanisms, tools, and software development approaches for fun. #TeamTopologies refers to this as cognitive load and focuses on decreasing cognitive load of all teams, with the first priority on stream-aligned teams. The primary problem with all kinds of team compositions is management (a) viewing all developers as equally skilled cogs, (b) not knowing how to determine levels of complexity, and (c) having little idea what's going on within teams. Skill here means mental capacity, clear, concise, complete communication; commitment; technical and software development capabilities; and willingness to challenge everything that they currently assume. This all traces back to Conway’s Law and what I refer to as Conway’s First Axiom: - Communication matters most - First designs are rarely the best - Flexible is required to improve and possibly reform teams based on the need to improve communication and possibly other skills Don't take these for granted. Keep a pulse on all teams involved in a system solution. Adjust as necessary.

Most AI and data programs do not fail because of technology. They fail because leadership cannot see the structural patterns early enough. The uncomfortable truth: By the time failure becomes visible, the damage was done months earlier. Here are the patterns we see inside real enterprise delivery: 1. Documentation is not executable Architecture, governance and operating models exist, but delivery teams cannot use them. If teams cannot apply it, it is theatre, not architecture. 2. Use cases are chosen where failure is visible but data maturity is invisible Board commitments are made before data readiness is validated. Visibility beats feasibility, and programs pay the price later. 3. Data debt is unmeasured Teams spend 20 to 40 percent of delivery time on reconciliation and pipeline stabilisation. If you never quantify the debt, the debt always wins. 4. Integration is ignored because incentives reward demos, not durability Everything looks fine until the moment work needs to touch real systems. The demo is celebrated. The integration is ignored. 5. Ownership is fragmented Teams own slices, not end to end outcomes. Signoffs stall and dependency chains grow. No one owns the whole, so no one can unblock the whole. 6. Leadership misunderstands what the work actually requires Hiring aligns to titles, not capabilities needed to run and maintain data flows. When the work is misunderstood, the hiring is misaligned. 7. Technology estates expand without lifecycle discipline New tools are added without retiring older ones. Complexity grows silently. Every new platform increases drag unless something is retired. 8. Value is not baselined or defended Without evidence of business impact, programs collapse during budget cycles. If value is not measured, value is not believed. 9. Incentives reward launch, not longevity Momentum gets rewarded. Stability does not. You get the behaviours you incentivise. 10. Failed programs do not produce honest retrospectives Vendors change. Slides change. The root causes stay the same. Without truth, the cycle repeats under a new wrapper. These patterns are predictable. They are also avoidable if leaders know how to recognize them early. Here are the questions worth asking inside your organisation: 1/ How long does it usually take for these patterns to surface and quietly derail a program? Is it 6 months? 12? 18? 2/ What do people start saying or doing when these patterns are active? 3/ What early signals show that your program is heading toward the same outcome? We help organisations recognize these patterns early and redesign around them. If you want to break the cycle, let's talk about what actually works. Transform Partner – Your Strategic Champion for Digital Transformation   Image Source: Eckerson

We recently released lifecycle reporting in DX, and I’ve loved seeing it help Platform teams build a concrete business case for funding important Platform and DevEx initiatives. While traditional metrics—like build times, pull request merge times, and issue cycle times—offer useful insights, they cover only a narrow slice of developer workflows. They also often fail to distinguish between non-blocking delays (where developers can switch context and stay productive) and true friction points that drain valuable engineering time. Lifecycle reporting helps pinpoint where in the development process teams are experiencing the most friction and delays—and ultimately costing organizations the most. Just like in the screenshot below, I’m seeing companies lose thousands of engineering hours each year to challenges understanding existing code, lengthy CI processes, dev environment issues, and excessive meeting schedules.

The reason it takes so long to build software with large teams isn't what you think... It's called "High WIP" (Work in Progress), and it's destroying your teams' ability to get stuff done. You've all seen it: • 100 projects started. • 0 finished • 37 stuck at 97% • How could it be that everyone's so “busy," yet nothing's getting done? The downstream results aren't good, as team morale tanks over time. But the worst thing? These teams' ability to have any material impact on meaningful business results becomes non-existent. But the truth too many leaders miss is that high WIP isn't the problem – it's a SYMPTOM. The real reasons are hiding below the surface: 1. The inability to make strategic choices – saying "yes" and trying to do it all. 2. The outdated "vendor" mindset, with "The Business" throwing requirements over the wall to "IT." (It's time to wake up and collaborate earlier instead of dictating. Last I checked, it's 2026...) 3. We're managing software development like a factory assembly line (velocity?), when it's actually a learning journey toward changing customer behavior 4. Leadership refusing to understand and accept true team capacity, instead of always pushing for more. ("Hoping" will never make it true) 5. The unending search for the next shiny object: (“NOW we're all doing agentic AI on our roadmaps! ...until the next hot thing comes along.) We have to face that we've become addicted to starting things, but hate doing the hard work of finishing them. The only way to break free? Start by accepting that less = more. Fewer things done well will be worth far more than trying and failing to do many more things badly. Your teams don't need more to do. You owe it to them to make clear, thoughtful strategic choices and prioritize the fewer, truly essential moves you need to make for your customers and your business. Agree? Share your thoughts below 👇

Building the ships is getting easy. Building the shipyard is harder than ever. AI is going to make coding faster. But at Luxury Presence we are already finding that speed is exposing bottlenecks that never felt urgent before. 1️⃣ Learning: Prototypes are fast, validation is slow. PMs and Designers are scrambling to try to get user validation before shipping. 2️⃣ Strategy & Architecture: Strategy and architecture used to be a fairly infrequent exercise that was mostly done by a handful of leaders. Now that new projects are spinning up so quickly, these activities aren't being done in time.  3️⃣ Scaling: Agentic coding is definitely possible but hitting very real bottlenecks: Code review, QA, CI/CD, compliance can’t keep pace with AI-generated output. PRs will stack up. Developers will spend a lot of time waiting. 4️⃣ Coordination: Teams are starting to create more inter-related bets than leadership has bandwidth to coordinate. There is a lot of toe-stepping with the amount of code that is actively being touched in any given week. 5️⃣ Cohesion: With so many teams building things in parallel, it's a challenge maintain a cohesive holistic platform that reflects our brand. 6️⃣ Killing Features is Harder Than Building: It's easier to build the next thing than figure out how to sunset and rip out old features that aren't pulling their weight. 7️⃣ GTM Complexity: Enablement and GTM coordination is becoming the long-pole to getting solutions rolled out widely. Some potential fixes? 1️⃣ Learning: We need to build an “always-on” user research/validation loop. PMs and Designers should just have user meetings dropped on their calendars daily. Unmoderated user tests should be frictionless. 2️⃣ Strategy & Architecture: I'm hopeful reasoning AI can help here if it has a ton of context about our existing solutions. 3️⃣ Scaling: Minor optimizations in build times and automated QA are going to feel like huge unlocks when coding agents are doing more and more writing of code.  4️⃣ Coordination: I’m not sure what the fix is here. I'm hopeful the next generation of project management tools will solve a problem that feels like it never has been fully solved. 5️⃣ Cohesion: Designers are going to be hard to replace, but AI loves to work with Design Systems and it will help scale cohesion. 6️⃣ Killing Features is Harder Than Building: I guess this has always been true? Just takes guts and conviction to make it happen. 7️⃣ GTM Complexity: I feel like this area is ripe for innovation. We have some cool ideas we are tinkering with. I'm honestly loving burning down the old shipyard and reimagining everything.

In a recent conversation with a telecom engineering team, they shared that their biggest pain point was not deploying new features. It was testing changes in a legacy billing system written in a mix of #COBOL and #ABAP. Every small update required weeks of regression testing because no one fully trusted the test coverage. Critical scenarios lived in production behavior, not in test suites. Teams relied on tribal knowledge and manual validation to avoid outages that could impact millions of customers. This challenge shows up across industries where systems have grown for decades under constant regulatory and commercial pressure. Automated testing struggles when the intent of the code is unclear. One learning we have seen at Adapts is that #AI can help teams reconstruct test intent from existing code paths and data flows. #Modernization becomes safer when testing is grounded in understanding, not guesswork. #LegacyCode #SoftwareMaintenance #SoftwareArchitecture #Code2Wiki #CodeKnowledge #SDLC