Last Updated Apr 02, 2012 — Enterprise Agile Planning expert
SUCCESS = RESULTS / EXPECTATIONS (Part 1 of 2)
Enterprise Agile PlanningWhen I talk with people learning about agile software, I often play the game Presto Manifesto where the room talks about what it means to have a successful project and then breaks up into groups and / based on their experiences / comes up with a list of critical elements they've noticed on successful projects. This exercise is meant to bring people to the concept of what makes up the Agile Manifesto.The interesting thing is that in many cases, we discover that we're programmed to believe that project failures relate to not knowing everything up front. I almost always hear, "complete, thorough and approved requirements" as elements of a successful project. This programming aligns well with the formula of success, which I learned during my short stint at an ERP consultancy firm:
SUCCESS = RESULTS / EXPECTATIONSThis formula leads us make sure that we set clear expectations so that we can meet and hopefully exceed them / thus, leading to success. However, as we know and learn in agile software delivery (and really in any process), thinking that the users/customers know everything about a project (a.k.a. need) 6/9 months before they get their hands on it is simply a fallacy. Sure, we can make the customers agree to the expectations ahead of time. But doesn't that negate the ability to achieve value and ROI for the project? What generally happens is that the users/customers define the requirements and agree to them; then sometime about a month before the project is delivered, they get their hands on some working capabilities and then say things like:
- "This doesn't work like I expected; can you add a screen that does this?"
- "We'll need a report that gets generated daily."
- "If we don't get these, we really can't use this product."