Eugeniu Lipcean | AI Delivery Manager & Consultant

Author: Eugeniu

  • Why Delivery Management Is Critical

    Why Delivery Management Is Critical

    In many software projects, clients tend to focus solely on developers, underestimating the crucial role of Delivery Managers. They often believe that developers are the sole contributors to value creation. However, this perspective overlooks the significant impact that Delivery Managers have on the success of a project.

    The Misconception

    Clients often perceive Delivery Managers as overhead, not realizing that without proper delivery management, projects can veer off course, leading to wasted resources and unmet objectives. The absence of effective delivery oversight can result in teams working on features that don’t align with business goals, causing delays and increased costs.

    The Reality

    Delivery Managers ensure that the development process aligns with business objectives, facilitating communication between stakeholders and development teams. They help in prioritizing tasks, managing risks, and ensuring that the project stays on track.

    ✅ According to McKinsey, agile delivery leads to:

    30–50% faster time to market
    20–30% increase in customer satisfaction
    30–50% gains in operational performance
    McKinsey: Five trademarks of agile organizations
    Even though the article is about Agile in general, these gains are only possible when delivery is handled properly — that’s where Delivery Managers come in.

    Real-World Example

    In one of our projects, the client chose to proceed without a Delivery Manager, believing the technical team could handle tasks on their own and it would save costs. The result?

    The team spent months building features that were eventually deemed unnecessary.
    The work lacked clear goals or stakeholder alignment.
    Ultimately, this led to significant financial losses and project delays.
    This could have been avoided with proper delivery oversight.

    The Value of Delivery Management

    • Alignment with Business Goals: Ensures that development work matches strategic objectives.
    • Risk Management: Identifies issues early and implements mitigation strategies.
    • Improved Communication: Keeps all parties in sync and reduces misunderstandings.
    • Efficiency: Streamlines processes, reduces waste, and improves productivity.

    Cost/Benefit Analysis

    Let’s say you add a Delivery Manager to a team of 5 developers at 0.5 FTE. They won’t write code — but their presence can optimize the work and focus of the entire team.

    According to McKinsey and Atlassian, that optimization can boost team efficiency by 20–30%.

    That means:
    0.5 FTE of delivery input → 1.5 FTE of developer productivity gains.
    That’s ROI you don’t get by hiring “just one more dev.”

    Closing Thoughts

    While developers are essential for building the product, Delivery Managers are crucial for ensuring that the right product is built efficiently and effectively.
    Ignoring the role of delivery management often leads to costly mistakes, misalignment, and project failure.

    📚 Additional References

    ✅ Atlassian – Project Management in Agile Teams
    “Strong delivery roles reduce context-switching and clarify team focus, increasing delivery predictability and quality.”

    ✅ PMI Pulse of the Profession
    Companies that undervalue project management report 67% more project failures.

    ✅ Harvard Business Review – Why Good Projects Fail Anyway
    “Many projects fail not because of poor development, but due to misaligned goals and scope creep — all of which Delivery Managers help prevent.”

  • From ChatScript to GPT: 15 Years Around AI

    From ChatScript to GPT: 15 Years Around AI

    In 2011, I worked on a chatbot project for a Japanese startup called SpeakGlobal.

    At the time, AI wasn’t a buzzword.
    No large language models. No hype. No cloud-scale intelligence.

    Just one simple question: Could software help people practice spoken English without a human tutor?

    Today this sounds obvious. Fifteen years ago, it felt futuristic.

    When chatbots were built by hand

    Early chatbots didn’t really think — they reacted.

    They were based on rules, patterns, and carefully scripted dialogs. One of the most advanced systems of that era was ChatScript, created by Bruce Wilcox, a multiple-time winner of the Loebner Prize.

    During the SpeakGlobal project, I worked directly with Bruce on integrating his chatbot Suzette into our platform.

    Suzette’s engine was written in C++, roughly 25,000 lines of code — a serious, handcrafted system built long before modern AI frameworks existed.

    Back then, intelligence wasn’t trained. It was engineered.

    The SpeakGlobal idea

    SpeakGlobal, founded by Tosh Iguchi, aimed to help people practice English through chatbots, simple games, and conversations with other learners.

    The product worked. Demos were impressive.

    But after longer use, the limits became clear.

    The bots could talk — but they couldn’t teach.

    They couldn’t explain mistakes, adapt to a learner’s level, or show clear progress. Without that feeling of improvement, users didn’t stay — and they didn’t pay.

    Too early, not wrong

    Looking back, the idea itself wasn’t the problem.

    Timing was.

    In 2011, we didn’t have large language models, cheap compute, or AI that could reason across longer context.

    We were trying to manually build what today emerges naturally from scale.

    What changed with GPT

    Modern AI no longer follows scripts.

    It generates conversation, keeps context, explains reasoning, and adapts to the person it talks to.

    We stopped programming dialogs. We started training behavior.

    That changed everything.

    One delivery lesson

    AI still isn’t human.

    But it doesn’t need to be.

    What matters is this: It became useful.

    Not a replacement for people — but a thinking partner.

    And after 15 years around AI, that’s the biggest shift I’ve seen.

  • How to Schedule Software Development

    How to Schedule Software Development

    With years of experience in both Waterfall and Agile methodologies, I’ve seen what works—and what doesn’t—when it comes to project scheduling. While I personally prefer Scrum, I recognize that for certain projects, a Waterfall approach with detailed estimations is the better choice.

    One of the biggest mistakes I see in software development planning? Focusing only on coding. A schedule that only accounts for development time is doomed to fail. To help project managers and delivery leads build more accurate, realistic schedules, here are the key things to keep in mind:

    1. It’s Not Just About Coding

    A well-planned schedule includes more than just development time. Make sure to account for:

    ✅ Design & documentation
    ✅ Testing (functional, integration, rework)
    ✅ UI/UX design
    ✅ Demos & user acceptance testing
    ✅ Warranty & post-launch bug fixing

    2. People Aren’t Machines—Factor in Availability

    Your team isn’t coding 24/7, so neither should your schedule.
    Consider:
    📅 Holidays and vacations
    🤒 Sick leave

    3. Let the Team Estimate Their Own Work

    If estimates come from the actual developers, testers, and designers responsible for delivery, they’re more likely to be accurate—and the team will have a greater sense of ownership and accountability.

    4. Mark Hard Deadlines as Non-Negotiable

    Some milestones just can’t be moved—like a trade show launch or a regulatory deadline. These should be clearly identified so that the rest of the schedule works around them.

    5. Prioritize Features—Not Everything is a “Must-Have”

    Work with stakeholders to define what’s critical and what’s nice-to-have. This gives you room to adjust if things take longer than expected.

    6. Plan for Scope Creep—Because It Will Happen

    A change request (CR) process helps manage new feature requests without blowing up the timeline. Make sure the team knows how to handle them.

    7. Don’t Ignore Probability in Your Estimates

    Just because something is estimated to take 5 days doesn’t mean it will. If every task has an 80% chance of finishing on time, then multiple tasks reduce your overall confidence. Always build in a buffer.

    8. Balance Workload Across the Team

    A schedule where one developer is overloaded while others are idle leads to bottlenecks. Make sure work is evenly distributed and that over- and under-allocation issues are addressed early.

    9. A Good Schedule Should Guide the Work

    Your schedule shouldn’t just be a document—it should be usable. A well-structured plan helps the team kick off development without second-guessing what to do next.

    Final Thoughts

    Whether you’re working in Agile or Waterfall, the key to a realistic schedule is considering everything—not just coding. By keeping these principles in mind, you’ll build a project timeline that’s practical, achievable, and stress-free (well, almost 😉).