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 !
Comments and feedback lead to Part 2 and Part 3 !
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.
ReplyDeleteDavid,
DeleteThe 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
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.
DeleteGreat 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.
ReplyDeleteLook at http://totallyoptimizedprojects.com/
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.
ReplyDeleteThe 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.
DeleteI 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.
ReplyDeleteYou have highlighted a very important aspect "keeping your cool" that aids the journey.
Delete-A
Good topic...Arun.
ReplyDeleteIn 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
Subbubhai :
ReplyDeleteYou have clearly never created a Requirement document. Even after three readings I am not sure what you're trying to communicate.
Aniket
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.
ReplyDeleteIt 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.