Monday, July 16, 2012

Requirement gathering


The journey of a thousand miles begins with a small step; similarly the development or deployment of systems and solutions begins with requirement gathering. Conventional wisdom has it that IT teams talk to business users to gather their requirements, and then go about creating or finding a solution which fulfils defined selection criteria. When an agreement is reached between the users and IT, the system is then implemented. No user requirement, no solution.

Over the years many research papers have been written on the methodology and science of gathering requirements. Consultants created templates and promised success with common and uncommon sense. It has also been the subject of ridicule with challenged implementations, many of them attributed to requirements either not being articulated adequately or changing requirements leading to scope creep and thus sliding timelines. The most famous amongst these has been the pictorial representation below.

When I reflect back on the time I was a rookie programmer, I too went through the journey albeit with not too many such experiences. I remember instances when the disconnect was complete while in many the users loved the solution and the benefit delivered right first time. It never occurred to me at that time to analyse why I got it right sometimes while everyone was miserable in other instances. 80% success was deemed good and that kept everyone happy.

So last weekend over dinner when I met a CIO who recently inherited a legacy of many challenged projects, I was curious to find out how he planned to overcome history and get everyone moving in unison in the right direction. When he took on the new position, the buzz in the market was that the veteran of many industries and acclaimed implementations had taken on more than he should have. Everyone wished him luck and wondered what went wrong in his previous company for him to take such a risk.

The first month was spent assessing status, understanding and cataloguing projects, getting the team to wake up from inertia, and getting the business teams to start talking. In the company with many custom solutions, there were many stories on what went wrong in the past with fingers pointing at lack of business domain, incorrect interpretation of requirements, discipline, engagement, low skills, sliding timelines with projects not delivering even with 200% escalation in time and budget. The IT team was demoralized and had given up all hope.

Many months into his new role the vendors were on fire hearing about the transformation, change and the investments that had suddenly mushroomed. Old projects rejuvenated, new initiatives being aired; there was a direction where none was thought possible. The story had believers inside as well as outside. Having heard about this I was excited to be in his company to extract some insights on how he went about solving the unsolvable problem.

The CIO smiled at the questions and said, I coached my team to ask all the right questions and did the same myself with the CXOs. He elaborated user requirements will always contain not just what they need, but also what they think they want or should have. The requirements always contain many elements that are nice to have and not necessarily aligned to current reality. That is why they are referred to as “requirements”. So what are the right questions ?

“What is the business problem you are trying to solve ?”, “What will change for you or your customer once you have this new capability ?”, “Is the benefit measurable in money or time or efficiency ?”. We all ask these questions but not too often; we are happy gathering requirements and then executing solutions which are then sub-optimally used. Requirements tend to get unwieldy with all the exception conditions being mapped; in the end it does not solve the original problem but creates new ones.

Winning teams today do not focus on requirements, they ask the questions above and create solutions that solve real business problems or capture real business opportunities. I believe that the future holds a lot of promise to those who follow the new way of thinking and discard the old requirements lead approach. What do you think ?

Comments and feedback lead to Part 2 and Part 3 !

11 comments:

  1. So what does those questions get you? Business Objectives. How do you get to the solution that meets those Objectives? You still need Requirements. If anyone did requirements discovery without the guidance of business objectives, they would not know what requirements are most important to success. I am assuming that is what you mean by the "new way of thinking", priority of requirements set by objectives. It isn't that new, really, but still not known by the kind or orgs that flail about with the wrong projects or just too many projects.

    ReplyDelete
    Replies
    1. David,

      The issue that I have noticed globally is to rush into requirement gathering and development without the context of what is the problem we are trying to solve ? When requirements are looked at in isolation the solution is always sub-optimal. As you say, nothing new in this approach, the discipline however is rarely observed.

      -A

      Delete
    2. Interesting post. It should be logical that IT focuses on understanding and defining the business problem (what-is) first before launching into a solution mode. The requirement gathering phase would be a necessary step in the solutioning phase ( what-should-be)when all stakeholders contribute to conceptualizing and designing the application to mitigate the original problem.

      Delete
  2. Great post. I believe there is actually an anti-consulting company that you should look at. They have taken the "traditional" view and reshaped it based on the business journey, turned it into process enabled via on-line delivery so that you can use it internally without a lot of expensive consulting time. Focus on outcome and what you can stop doing - simplify first.
    Look at http://totallyoptimizedprojects.com/

    ReplyDelete
  3. Anil - I think many a times the notion of user requirement is misunderstood. I feel prior to taking up any initiative, the user requirement has to look at internal processes, map them with industry dynamics and best practices and then design the system that meets user need at ease and provides long term strategic success to the business by the facilitation of right mix of technology which is business focussed. Failed projects are great learning kit.

    ReplyDelete
    Replies
    1. The general consensus within the IT fraternity is that Users don't know what they want. I would agree except that if IT started asking the right questions, maybe the answers would help extract the business problem to be solved. IT is also notorious in wanting to propose a solution even before the problem has been identified.

      Delete
  4. I concur with the views. In my experience, asking right questions to the user helps to have a broad picture and solution designed works smoothly. There are many times user flungs back but I manage to keep cool and make user understnad why I am questioning. This approach made me successful and my system work properly. Most of the times I could stop doing unnecessary things which according to me does not add any value. I listen first, have my own analysis before starting my questions. This makes me to highlight the needs and separate make ups.

    ReplyDelete
    Replies
    1. You have highlighted a very important aspect "keeping your cool" that aids the journey.

      -A

      Delete
  5. Anonymous9:10 PM

    Good topic...Arun.

    In today's agile world and Organization to be agile...to compete to be competitive and create the differentiation, we just can't wait for gathering requirements, freeze the requirements, get the buy in and deliver based on the requirements. This approach is quite traditional. In agile world, it's quite imperative as a leader to lead to proactively identify the business need, business challenges, business opportunities, business concerns and issues...create and come out with Clear cut business need through effective partnership approach...leading to integrated solution which can address the need to deliver or create value...which can be optimization, competitive edge, quality, service excellence, productivity, performance....innovation...profitability or break through performance. Need to move from requirements to deployment mindset to Need to Deliver or Execute or Enable or Transform.

    This Requires a leadership across with a winning mindset to understand and get insights on Business and Industry besides environment to get perspective on the business need to come out with appropriate strategy to address the need, and also most important is continual engagement across all levels of business to get a holistic view of the need...to come out with a compelling need.

    "Developing software and walking on water are easy if both are frozen". Every one of us have faced challenges in gathering and most important freezing requirements. If the same is a compelling business need which can be a business problem or concern or any...then not only buy in happens, but also there is team work built up to address the common business goal leading to possible solution which will be effectively deployed and used.

    Best Regards...Subbu

    ReplyDelete
  6. Anonymous6:41 PM

    Subbubhai :

    You have clearly never created a Requirement document. Even after three readings I am not sure what you're trying to communicate.

    Aniket

    ReplyDelete
  7. I think David has said it all. Requirements should be be gathered from different perspectives within an organisation but must align to the business objectives to be worthy of inclusion into the scope of the project. Simply put, the requirements are the activities that need to be taken in order to meet the business objectives otherwise they are not requirements.

    It may trouble some people to say that user requirements are not required but sometimes what individuals may think is a requirement may not actually be when analysed against the business goals. This technique keeps the project costs down and business focused.

    This is true whether the project approach is Waterfall, Agile or a combination of the two.

    ReplyDelete