SUCCESS = RESULTS – EXPECTATIONS (Part 1 of 2)

When 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 – EXPECTATIONS

This 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.”

The response of the software delivery team is usually something like, “But you signed the requirements document” or “Those are great ideas; we’ll need to do that in the next phase” or “That will need to go through the change control process; we’ll need to escalate this.” Ultimately, the team isn’t happy because they don’t get to experience SUCCESS. The RESULTS fall short of EXPECTATIONS. On top of this, the customer isn’t happy either.

In an agile software approach, we can improve our SUCCESS rate by applying 4 very basic ideas. On Friday I will follow up with these 4 ideas and provide some tips on how you can give both your software delivery team and your customers a feeling of SUCCESS that is difficult to achieve in traditional project management.

This entry was posted in Agile Adoption, Agile Benefits, Agile Management, Agile Project Management, Enterprise Agile. Bookmark the permalink.

One Response to SUCCESS = RESULTS – EXPECTATIONS (Part 1 of 2)

  1. George Odum says:

    How do we measure or determine the elements of success, results and expectations of software products or applications?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>