Emerging Tech

Project managers: Stop "gathering" IT requirements

Paul Glen often hears that the failure to gather good requirements is the main cause of project failures. He says that, instead of gathering requirements, project managers must negotiate requirements among the stakeholders.
Editor's note: This article was originally published Sept. 5, 2006.

Over the years, I've come to the conclusion that one of the most destructive notions circulating inside technical groups involves "gathering requirements." For decades, virtually everyone in the industry has accepted that the first phase of every IT project should be to gather requirements from business users. At least in theory, it should be the point of departure for all our efforts. (Of course, it's also the phase of the project that's most often skipped.) So now that our success rate for IT projects has risen to the still dismal level of about 25%, perhaps we should question some of this time-honored wisdom.

As I travel the country for consulting and speaking engagements, I often ask, "What are the main causes of project failure?" And invariably one of the first answers is something like, "There's a failure to gather good requirements."

And when I ask why projects get bad requirements, the answers are, "Users won't tell us what they want," or "We don't ask good questions," or "What they told us they wanted turned out not to be what they really wanted." But I think that the problem is more subtle than any of those answers.

The problem with gathering requirements is right there in the word gathering. What images does it conjure? For me, it's an image of a harvest, of a group of people standing among endless rows of vines picking ripened grapes and carefully placing the bunches in a bin. For others, it might be an image of a child collecting seashells on the beach or of a group of people huddled together at a town meeting. What's common in all these images of gathering is that there's something out there to be collected, like crops, shells, or people, and that those things are already whole and complete.

So if we're gathering requirements, we assume that they must be out there, ready to be assembled like a roll of coins. Our problem is finding and selecting the right ones. So if the users don't tell us what they really want, we should grab them by the ankles, hold them upside down, and shake them until those pesky requirements fall out on the floor. The only logical conclusion is that if we don't get good requirements, we haven't shaken enough.

Of course, this is ridiculous. Requirements don't exist out in the ether just waiting to be discovered. They aren't out there whole and finished. Clients and users aren't playing an expensive game of hide-and-seek with us. Usually, the clients' pockets are empty. Most of the time, they don't exactly know what they require. And even if they do, it's in the form of incomplete and inconsistent ideas that can be only partially articulated. Projects rarely start out with clear objectives or requirements; they begin in confusion and ambiguity.

The other problem with gathering requirements is that it suggests subservience or disinterested passivity on the part of the IT group. It gives the impression that the job of a technical team is to take orders like a waiter who couldn't care less what you eat and then deliver the cooked meal. Technical teams with this attitude rarely deliver high-quality service.

So what's the alternative? Obviously, projects need solid requirements on which to build technology.

We should think of a set of requirements as being like a multilateral treaty among a group of nations. Representatives of nations negotiate treaties by seeking out points of agreement, acknowledging constraints, compromising, and trading off. The forging of a treaty is an active and difficult process of creation. No one would suggest that you "gather paragraphs" to write a treaty.

So we must negotiate requirements among the many stakeholders whose positions and interests need to be acknowledged. There are the business interests of executives who fund projects, of course. There are the utility needs of the users who will work with the systems every day. There are also the technical needs of those who build, deploy, and support those systems. The list can go on and on.

Successful projects begin not with a harvest, but with a difficult set of discussions on what should be done. If you stop trying to gather requirements and start negotiating them, your projects will yield richer crops.

Paul Glen is the author of the award-winning book "Leading Geeks: How to Manage and Lead People Who Deliver Technology" (Jossey Bass Pfeiffer, 2003) and Principal of C2 Consulting. C2 Consulting helps IT management solve people problems. He regularly speaks for corporations and national associations across North America. For more information go to www.c2-consulting.com.

---------------------------------------------------------------------------------------------------------------

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!
52 comments
Jaqui
Jaqui

have a decent set of base templates to use for defining the requirements. The more detailed the template is, the better quality requirements you will wind up with, even if you don't need most of what is on the template. by the time the requirements team works through a good template the first time through, they will have started really thinking about what is needed. the second meeting will get them almost completely finalized. The third meeting will finalize the requirements. edited to add: http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=281790 a link to a TR discussion that starts with a link to such templates.

ebucao.pmp
ebucao.pmp

Reaction on: "Successful projects begin not with a harvest, but with a difficult set of discussions on what should be done. If you stop trying to gather requirements and start negotiating them, your projects will yield richer crops." Beginning a discussion as to what should be done is the result of gathering the requirement. How does one know what should be done if one doesn't know what are the requirements? Paul Glen, I think you've been around with weak Business Analysts, or psuedo-Business Analysts or psuedo-project managers. Because of this the requirements made on the projects you've involved or observed are impacted negatively. One way of enhancing the project success is asking who first before what. Who should work on a project and what needs to be done. Disciplined people with disciplined thoughts and actions lead to success. Good luck. Jun B., BA, PMP

rthb
rthb

developers with business Requirements and user experience in mind will do lot better job than a fake PM and BA because they do not know what can be done in what time,hehe

robin
robin

Good article but still overlooking a few key points about the "gathering" mentality. As suggested by the title of my book, Discovering REAL Business Requirements for Software Project Success, before there can be negotiating, the REAL requirements need to be discovered. The gathering metaphor actually interferes with discovering the REAL requirements, because what should be gathered is data about _what_ is needed; but gathering invites Product/System _how_ solutions masquerading under the name requirements. Unfortunately, the BABOK and much of the Business Analysis world does indeed act as if all that's involved is taking dictation, whereas effectiveness demands empahsizing the Analysis aspect that tends to get lost.

chris
chris

Also, it might be good to actually clarify that what you are going to get from business users are not requirements. You will get feature requests. "I need to be able to search for clients" is a feature, not a requirement.

robin
robin

Good article but still overlooking a few key points about the "gathering" mentality. As suggested by the title of my book, Discovering REAL Business Requirements for Software Project Success, before there can be negotiating, the REAL requirements need to be discovered. The gathering metaphor actually interferes with discovering the REAL requirements, because what should be gathered is data about _what_ is needed; but gathering invites Product/System _how_ solutions masquerading under the name requirements. Unfortunately, the BABOK and much of the Business Analysis world does indeed act as if all that's involved is taking dictation, whereas effectiveness demands empahsizing the Analysis aspect that tends to get lost.

robin
robin

Good article but still overlooking a few key points about the "gathering" mentality. As suggested by the title of my book, Discovering REAL Business Requirements for Software Project Success, before there can be negotiating, the REAL requirements need to be discovered. The gathering metaphor actually interferes with discovering the REAL requirements, because what should be gathered is data about _what_ is needed; but gathering invites Product/System _how_ solutions masquerading under the name requirements. Unfortunately, the BABOK and much of the Business Analysis world does indeed act as if all that's involved is taking dictation, whereas effectiveness demands empahsizing the Analysis aspect that tends to get lost.

sunsesh
sunsesh

I am not sure if I can readily agree with this proposition. Multilateral treaties happen between two equally 'powerful' entities and each knows what he wants. If it is a product, may be, we can say that the vendor and client are equally powerful. They both are familiar with the requirements and there could be negotiation. An architect building a house may be an example - where the architect as well as the guy-with-money know about the house and there exist some common notions about the requirements for the house. How do you achieve it as a vendor when a client calls you to build something for him and you are purely a software developer. You may or may not know about the 'domain' and naturally you need to understand what the client wants. I would love to negotiate the requirements if (a) I know what is to be built (b) I know what I know would satisfy the client. Sundar

ramkip
ramkip

This has been a major problem over years. The biggest assumption that is made while "gathering" requirements is that customer is completely aware of the requirements or has got excellent communication skills to communicate what he wants. This has been the major reason for Agile methodologies to pick up in the last few years (though many people really don't understand Agile well).

sergio.tarzia
sergio.tarzia

In my humble opinion, and based on first hand experience, I think Paul is looking at this from the IT end yet again - and this is at the core of the problem. I agree with requirements negotiation (in fact most consulting firms that barely know what they are doing take this approach). However the essence is to understand what the business objectives are - then this (and only this) should drive the scoping/requirements phase - and therefore negotiation comes out as a natural activity, because there is a focus on the outcome, not on the requirements alone.

ashmeedm
ashmeedm

more accurate analogy of the circumstances and activity at the requirements part of the project

tehwalkleys
tehwalkleys

Gather their needs and give them their requirements as a solution. Prototype the solution first and begin the education early. I have been doing this for years and have never had a project failure. The buy in of the users begins up front with their participation in the solution.

josechi_h
josechi_h

I think that the methodologies (many) suggest, and suggest ... but when developing software as it is on your side and leave them enough. Why? Speed, urgency and interest to show the product ... good article and are already more than 30 years of this item greetings sorry by me english Jose

royen.fernandes
royen.fernandes

I agree with Paul Glen. Infact the software phase is called Requirements Analysis and not Requirements Gathering. Analysis includes the right negotiation skills, analysis skills and other behavioural skills like Stakeholder Management, Articulation and Communication. A Project Manager and his team of analyst's need to build upon these skills so that the project moves in the right direction. During the course of Requirement Analysis, it is very important to understand and address the Technical, Cultural and Political reactions/issues of various stakeholders so that the Requirements are collected, prioritized and taken forward. And yes, the PM has to accept the fact that Requirements are bound to change during the course of project execution. That is why we have Change Management as an embedded process in Project Management. Thanks Paul for posting this article.

anshul_gupta
anshul_gupta

I agree with how this article describes one of the most important aspects of a BA's and PM's role. It's crucial that we discuss this paradigm amongst key stakeholders during project inception.

lsalazar
lsalazar

Great article, requirements and objectives are often not taken seriously from the very beginning of the project (and I'm saying this from a developer viewpoint). Worst thing is when a project collapses and everyone in the team is trying to find the solution among technical aspects rather than requirements and specifications. I think it's the technical team's responsability to strive for a better understanding of the problem (not only from a technical view) so as to propose more suitable solutions, otherwise rework will be the unavoidable consequence, over and over.

work
work

I really enjoyed these comments and am saving them for others to read, to help establish what should be done or expected by people.

fidlrjiffy
fidlrjiffy

In one of my many PM best practices books the same idea of negotiation is advocated and I have no doubt that as a concept it is valid and correct. The devil is in the details, of course. IT is all too often put in the position of a service organization and cost center who's role is to deliver "on time and on budget" when both time and budget have been predetermined by others. In industries that are regulated many times these are determined outside the company which leads to that wonderful game of musical priorities where every project has to find a seat as resources and time are continually being pulled away. It seems that every department gets to say no except for IT. So, yes, negotiation is a great idea and how to do it requires a top down approach from management. At least author Glen acknowledges that it's a difficult set of discussions, an understatement if I ever heard one. "Have fun storming the castle!!!"

rambuswolf
rambuswolf

I think Paul's contentions underscore a fundamental problem with the mindset of many IT people (which, in all fairness, is totally understandable) that we are just technical instruments. Forgive the analogy, but we are no more just instruments than a hairstylist is a scissor operator. At some point the stylist has to say, "No, that won't work with your hair," or, "You say you want me to do THIS, but what you really want is this result, which could be achieved like such," et cetera. I believe it is incumbent upon us to assert ourselves constructively and guide the process where our judgment tells us we NEED to intervene if anything fruitful is to come of the endeavor. Instead, we often decide that it is safer to just carry out what is asked of us -- and thus divorce ourselves from responsibility for the outcome -- than it is to stick our necks out and have a shaping hand in a project, and risk being perceived as responsible if it fails. Paul is really on track in his assertion that we need to negotiate requirements among the stakeholders, including (and not least of which) those who deploy and support the technology.

james.p.lamaster
james.p.lamaster

I think Paul Glen brought up a great point that project managers need to negotiate requirements rather than gather them. I was hoping the article would get into suggestions on how to do this negotiation. I'm sure we project managers could learn a lot from his ideas.

PhilipYandel
PhilipYandel

Jaqui, As I stated in your other thread, a template is nothing more than a tool. If the workman doesn't know how to elicit business requirements, then no tool or template will get the information that is really needed. The template does not know how to ask the right questions in the right way from the right people to dig down to find out the underlying business decisions, goals, issues, or problems that are trying to be addressed. Too often, the usiness partner just asks for what they THINK will solve their problem: "I just want a report", "add a check box", "create a database", rather than describe what the problem really is. there are tools that can be used to generate code, do you think that just because someone buys or downloads one that they will be creating well architected, designed, constructed, and tested applications? Probably not. http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=281790&messageID=2668790

spblais
spblais

Hi Jun No matter how skillful the BA is in elicitation, she cannot coerce requirements out of a user who does not know what to do about a business problem. After all, that is why the business has called the BA in the first place: to solve the business problem. The BA's job is to gather information which most likely includes business rules, perceived solutions, descriptions of how this particular user performs their functions in this business process, constraints, risks, user stories and scenarios, and a lot of non-germane facts and presumptions. From this information the BA distills through analysis what the real requirements are - what is necessary to solve that business problem. The "ah-ha" moment comes when the user or customer sees the solution and says, "Yes if you can do that, it will solve my problem!"

PhilipYandel
PhilipYandel

I agree that a PROFESSIONAL IT developer will do a better job than a FAKE PM and BA, but what is your definition of FAKE and PROFESSIONAL? If the PM or BA do not really know how to perform their job, do not have the skills to accomplish their role on the project, I guess I would consider them 'FAKE'. But if the PM and BA are fake, then where did the developers get their business requirements? Who worked with the business to discover what it is that they really wanted? Who is working with the developers to make sure that what is being developed is what was agreed to with the business? In this day and age when 70+% of projects are considered failures because of inadequate or incomplete or vague business requirements, I cannot believe some technical developer thinks they can do a better job of eliciting the requirements than a PROFESSIONAL Business Analyst. Almost as ridiculous as the BA or PM that thinks they know how much can be done in what time without consulting with the developers to put together a project plan. hehe indeed!

PhilipYandel
PhilipYandel

The IIBA defines a requirement as "A requirement is 1: A condition or capability needed by a stakeholder to solve a problem or achieve an objective. 2: A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. 3: A documented representation of a condition or capability as in (1) or (2). Requirements serve as the foundation of systems or system components. A requirement can be thought of as something that is demanded or obligatory; a property that is essential for the system to perform its functions. Requirements vary in intent and in kinds of properties. They can be functions, constraints, or other elements that must be present to meet the needs of the intended stakeholders. Requirements can be described as a condition or capability a customer needs to solve a problem or achieve an objective. For clarification purposes, a descriptor should always precede requirements; for example, business requirements, user requirements, functional requirements." - IIBA BABoK v1.6 So, what is your definition of a "Feature Request"? And why is it better than a "Requirement" as defined here?

geetao
geetao

Sergio, thanks for making this point. business requirement -> business case -> cost of requirement -> priority of the requirement -> etc etc are initiated at the 'business'. i.e business is the client here and IT provides the service. when u look at it from this angle, not just the 'negotiation potential' but the whole 'attitude' of the stakeholder approach takes a different direction, towards a more amicable and transparent side. underlying this is the point that 'most' people / stakeholders understand the 'language' of the business unit than that of 'IT'.

chris
chris

It's feature analysis.

chris
chris

Exploring Requirements, Quality Before Design. It does a great job in teaching how to think about things

starryknight
starryknight

Without going into a lot of detail here... the points in this article do not apply equally in all industries. As a systems analyst in a leading healthcare research hospital, I can say that there is not as much negotiating. Grant money is awarded to produce things already defined, and the money MUST be spent to obtain it, whatever "it" is. So there can be discussion of "how" things might work best, but not "what" or "if". Also, researchers are treated as demi-gods, so if they want something and have the money to pay for it - it WILL be done. But, maybe no other industry is like this.

pmaina2000
pmaina2000

They say madness is doing the same thing over and over again - expecting different results. Even though requirements have been statistically ranked as one of the TOP causes of IT projects failures since the nineties(see CHAOS report), there have been no major paradigm shift to date in Systems analysis courses. As long as business users are led to believe that Business Systems are ordered like Pizza and the Systems Analyst is a Waiter, we will always have the problem of the Pizza being too hot/cold/warm/soft/hard/not just right/almost-but not quite/ late/ early/ not needed any more/too small/too big/not mine/not anyones/ etc/etc 1. IT and Business need to work in projects as equal PARTNERS. I have said it before - and will keep saying it. If you "gather requirements" for the business, you end up creating "your system" which you then have to "sell to the users" (i.e. no one wants to take ownsership when you deliver). Users blame you for change requests and when the project fails, it's an "IT project" that has failed. When the project succeeds.. well, suffice it to say the lead programmer would be lucky to be mentioned in the company's newsletter. 2. Business users are expert negotiators. They practice negotiations every day! They also know that IT people are suckers when it comes to requirements negotiation. More often than not, the systems analyst will get suckered to "gather, analyze and understand our requirements, then give us a system - but we are too busy to be involved - hence you must understand what we do!" How can the Systems Analyst understand the business after spending just a few months/weeks/dayss doing interviews / research etc? He will always lack something vital to the solution BUSINESS INSIGHT. Systems developed without clear business insight end up being rejected by end users. Solutions to business insight problem have been lazily categorized as "domain knowledge" issues and systems analysts have been asked to study about business details which do not really interest them at all. How do you get more insight than someone who does something daily over and over for many years?? Are these users too dumb to state what they need in specific terms? Or is IT so dumb as to believe / fall for such crap? In one recent implementation, I maintained a hands off approach and isisted that the users define exactly what they want using predefined templates or checklists for guidance. This was followed by 4 pre-release prototypes which validated the look & feel in addition to certain core functionality aspects. All the times, the users were responsible for understanding what the prototype does and what is missing. Everything was documented and changes of mind had cost/schedule implications. At first it was hell. They fought like cornered tigers. Clawing, hissing, escalating, booby trapping etc etc... Luckily I had a boss who believed in me so it didnt take long for the business to catch the drift... Once they got the message (i.e. its their project - not mine i.e. A Business Project not an IT project)... everything became super smooth. Full ownership from Go-live day1. Project delivered on time, on budget; That was end of March 2008. We're now rolling out to 80 stations globally and guess what - they don't even need me. I can safely allocate 95% of my time to other projects and simply be content to watch from the sidelines - only chipping in when I have to. Glen, Excellent Article! I hope my story will support your ideas and hopefully inspire someone.

minstrelmike
minstrelmike

To negotiate, you essentially tell them that you can do anything they ask for, unless it's mathematically/logically/realistically impossible. However, anything costs time and money.How much of an improvement can you afford to pay for? And how much money will these improvements save us? Those are questions the biz folks can answer, but only if IT can do the analysis with them. Doing the analysis together _is_ the negotiation. It's very easy to just ballpark costs and delivery times for many ideas. Start your analysis/negotiations there.

jgraber
jgraber

I worked for a company once that had a software product that required client customization. We would meet with key people and do a walk through of the product and give them an opportunity to talk about how they did their work and then we would compare features of the software to the work activities and negotiate how to implement their needs into the product. It worked quite well. Although, we have a strong Change request approach that keep the project under control.

fnagelmann
fnagelmann

Clearly a well-articulated and negotiated set of requirements is a wonderful thing. That said, I have for years promoted that the only thing you know for sure about your project plan is that it's wrong -- it will require changes. I have found that the Agile approach embrases this assumption and allows the project to morph and evolve as the project team, stakeholders and sponsors all learn more about their objective -- including revisions to requirements. Treat your project plan as a living document and you will be able to revise requirements without destroying your projects.

PhilipYandel
PhilipYandel

With the realization that our projects are no longer failing due to time and money considerations thanks to the emphasis on project management, we now know that failure comes from missing the requirements for any number of reasons. With this new emphasis on getting the requirements right, the role of the Business Analyst has come of age. It has been recognized as a separate role on a project from the PM and requires a different skill set from that of a PM in order to be successful. The International Institute of Business Analysis (www.theiiba.org) is celebrating its 5th anniversary this month and has come a long way in putting together its own BABoK and advancing the education to equip BAs as they work on projects.

pmaina2000
pmaina2000

Hmmm.. the BA has been gathering requirements since time immemorial...and projects have been failing and failing and failing... With project management issues largely addresed by PMI, it has become clear that most of today's failures are due to shortcoming related to REQUIREMENTS (scope creep/quality/politics). A philosopher once described madness as doing the same thing over and over again expecting different results. You dont need to do a survey to be utterly convinced that the old fashioned "Gathering" concept for requirements capture has FAILED MISERABLY. Rather than an external party to "gather", we need an internal person on the ground to communicate and analyze. We need BUSINESS INSIGHT when capturing requirements! Requirements need to be communicated by the BUSINESS, in terms of business needs, and in BUSINESS LANGUAGE. This Analysis 101 tip has been largely ignored in favor of "tech-Gizmo-oriented" analysts. Example (business requirements): "We want to raise our revenues by x%. How? By reducing customer complaints. why? its affecting retention? how to reduce complaints? give customers an easy method of complaining so they are encouraged to talk to us. secondly, let it be easy for us to address the complaint, and finally we need to spot patterns in complaints so that we can improve our front-line service offering." There's no gathering here. This is just a guy telling yopu what he needs. Its quite easy to determine his Technicical solution (which could at a technical level comprise of several technologies - Mobile/Web/Business Intelligence/CRM etc) Compare that with the current approach of writing requirements: "We want a page on our website to collect customer complaints with a submit button and graphics; the page should conform to J2EE standards (????) and should be user friendly with highest level of quality". Then when you deliver the website, you discover there was more to it - but since you didnt have the business insight at requirements capture, your project gets thrown out. Business needs to realize that they don't need an IT degree to say what they want to a high degree of precision. It's time to heal the madness. Time to question the Status quo!

Tony Hopkinson
Tony Hopkinson

eliciting requirements from BAs to be just as difficult as getting them direct. Both tend to give me solutions, not requirements...... The interface between requirement and implementation has always been fraught with difficulty. In theory aside from cutting manning costs (hardly worth mentioning :p ), the analyst/developer role was meant to eliminate one level of communication failure. In terms of analytic ability, I remember doing ten times more work on analysing the efficiency of a sort algorithm as I did on analysing requirements. Fortunately for me in my working career, I ditched all that sort crap, and worked on the statement. "It should turn red".

spblais
spblais

Hi Phillip You said, "In this day and age when 70+% of projects are considered failures because of inadequate or incomplete or vague business requirements, I cannot believe some technical developer thinks they can do a better job of eliciting the requirements than a PROFESSIONAL Business Analyst" Unfortunately, it's not just one technical developer, but a whole movement called "agile software development". In Extreme Programming (XP) for example the developers meet directly with a user designated as the "onsite customer" and discuss decks of index cards containing user stories to define the requirements for the developers' next two-three week development iteration. When those requirements are implemented at the end of the iteration, the two groups meet again to define the requirements for the next iteration. In Scrum, the Product Owner from the business meets with the Scrum team to develop a prioritized "burn down" list of requirements and features to be developed in 30-day iterations called Sprints. Nowhere in these scenarios is the position of business analyst. The developers play the role of BA in defining the requirements, features and functions to be developed and implemented. I have had many discussions with leaders of the agile movement who have steadfastly proclaimed the BA as an extra unneeded layer of communication between the developer and the business. The only concession I have gotten is that it does make sense to have a BA as the onsite customer or product owner instead of a user. However, that concession was made grudgingly. I agree that a "PROFESSIONAL Business Analyst" is an essential component in the success of any software solution, or for that matter, any business process improvement. Unfortunately our viewpoint is becoming as outdated as developers are adopting the attitude that they can understand the business mentality and perspective better. I have to admit that as a recovering nerd I once held that belief. Hopefully, this extreme point of view will ameliorate over time and a reasonable approach which includes the BA will again reassert itself. There are already signs that such reasoning is already taking place. =steve

chris
chris

This is just a quickie. To me the difference is something like this... Feature Request:I want to be able to enter Clients Obviously this feature would require many things to be strickly defined and this is just a sampling and are not fully developed. I am just including them to give people who do not understand programming to see the kind of details that are often simply assumed. Requirements: Clients should entered into the system using (entere languages here) character set(s). Client name should consist of alphanumeric characters only. Client name should not exceed 100 characters in length. System should validate data using ("X" whatever that is defiened to be) validation standard. System should check for duplicate records based upon ("X" whatever that is defined to be) and prompt user if duplicates are found allowing existing records to be selected or edited. If dupliates are found, system should allow user to override and create a new record. If an override is chosen system should log action and notify supervisor this action was taken. --------- When a business person says "I want to be able to "search for..." or "I need to be able to have a contact field added" there is so much more that is needed to be known. Those things (those details) are requirements.

PhilipYandel
PhilipYandel

What your particular methodology calls it, it should never be called or thought of as Requirements GATHERING, like squirrels gathering acorns under an oak tree, more like detectives trying to solve a crime where some clues are readily appearant, but others are intentionally being obscured.

TownsendA
TownsendA

Glenn had me worried for a moment until the fourth last paragraph. You do need requirements, its how and from whom you get them that's important. Whther you use Delphi techniques,JAD's, brainstorming, mind mapping or whatever. Without knowing requirements how do we know what is in scope or not? Even the CFO has a stake in an IT project - yea the big $! All stakeholders need to have input and I think that is what he was saying.

kenny
kenny

I found that users often don't know what they want when you start a project. But they can certainly tell you what's missing when you finish the product.

g.khead
g.khead

It seems to me being someone with 20+ years involved in the IT - User interface that each body has evolved a series of artifice to prevent communication. Lets evolve another template rather than lets ask the users what they want and if its /too hard / too costly or not cost effective tell them so and offer a resolution. We have spent too much time trying to be all things to all people, for once we need to tell users that the monday button is a dream!

pmaina2000
pmaina2000

Exactly. Taking it further, have a look at my comment on "Requirements v/s specifications".

PhilipYandel
PhilipYandel

I totally agree with your assessment of good and bad BUSINESS requirements. The BUSINESS should be concerned with their BUSINESS and the BUSINESS GOAL/PROBLEM they want to resolve. They should not care about the TECHNOLOGY that IT decides to use in order to deliver the solution as long as it meets their requirements. As a Senior Business Analyst, I see many BA's (or IT organizations) that just do not understand what the role of the Business Analyst should be. While you may have assumed that the discipline of Business Analysis has been around forever, it really hasn't. It is just beginning to be recognized as a skilled role that should only be done with the proper training and apprenticeship experience. What was passed off as business analysis and requirements "gathering" (I hate that term), was relly a bunch of techies that wanted to build software and needed to figure out what to build, but did not understand what a business requirement was or how to communicate their techie translation back to the business in order to confirm that the business requirements were understood. A professional Business Analyst must be able to understand what the business is trying to accomplish so they can put the business' request into context and ask the necessary detailed questions (performing the analysis). Without getting the understanding of what the business is trying to ask for, how can we as BA's document the specifications for these business requirements that should be used by the business to measure whether IT actually met their business need. And it's the BA's role to then represent those detailed business requirements on the project as an advocate for the business to make sure that the technical solution will meet the business need and the intent behind their request. The role of the BA does not end just because the requirements are documented and both the business and IT have signed off. The BA is responsible for ensuring they are also delivered as specified and that any discovered changes, whether by the business or by technology, are managed and agreed to by both sides of the team. The business should not care what technologies were used to develop and deliver the solution, as long as it meets their 'nonfunctional' requirements for being useable, reliable, responsive, performs consistently, is adequately supported and maintained, etc. - Those qualities should be the value-adds that are automatically delivered in the technology solution to whatever degree the business is willing to fund.

Tony Hopkinson
Tony Hopkinson

We need an enterprise CRM solution, here's one we made ealier in access.... I love those people, they go to a Gartner symposium, have a good dinner with a vendor who just happened to be there. Then you and I get our hammers out and make gotta have it, sort of work. System dies a death and they employ two newbies for telesales and realise more sales then they would from the CRM....

PhilipYandel
PhilipYandel

Without a true Technical Expert (like yourself) on the project team, the BA would be trying to be all things to all people and performing too many roles on a technology project. I have a very diverse technical background, and feel I can out-perform most developers on software projects, BUT I do recognize that I CANNOT be doing both the BA and Technical Lead roles on the same project if I really want to do either to my best abiliity. I absolutely rely on my Tony's to figure out what it would take to give the customer what they think they cannot live without. I like to tell the business that nowadays, they can almost have anything they want from a software solution, BUT they have to be willing to pay for it in either time (taking longer) or money. And then the business needs to determine how fast, how reliable, how available are they willing to pay for. As for your hypothetical, I would ask the business why they need a database at all. Their business goal or problem will not be automatically met or resolved because we create a database. What if there was a better solution, maybe a data warehouse, or a web service, or room full of moneys that would give them the functionality as well as some of the nonfunctional requirements? I try very hard to always question when the business/customer says they 'need' something that is really an implementation decision. Why does the user think they need a command button? a check box? radio button? When the business, who are supposed to be experts on the BUSINESS, try to design the technical aspects of the solution, especially when they insist we do exactly what they ask without question, are like people that try to represent themselves in court. Who knows, maybe some day in this globalized world of business, we might find ourselves on the same project and deliver a kick-ass soltuion! Have a great holiday season! P

Tony Hopkinson
Tony Hopkinson

as long as they happy to work with me. A good analyst elicits useful requirements for the business, essentially by asking them about what they want, not about what they said they wanted. Then puts that together as a coherrent whole, from which I can realise those requirements, in my case usually with a bit or a lot of code. The big thing most business analysts I've worked with miss, is technical contraints. For that you need someone like me, because some of them can be very very technical. They can also be so critical that your general idea of how to realise the business's requirements could be impossible or more likely impractical. A classic is, we need a database, for high speed data recording and reporting. Unless either the collection or the reporting is trivial, with one datbase you are going to get low to medium speed in both. Would you think to ask, why one database. Would you know what the impact on in splitting those two different technical requirements, would/could be ? Do you know the cost of getting away with one? At a certain level the business user doesn't give a crap how many databases are in there. If we tell him the development budget just doubled because of the other database, one of us had better explain to him that his business requirement mandated the extra, not that propeller head Tony doing a purist design. :p

PhilipYandel
PhilipYandel

Tony, I agree that most people that are trying to perform the Business Analyst role, do not know what the heck they are doing and either do not understand technology or the business, and probably have not had any formal training or observed a good example of requirements elicitation and management on a project before. But, IT has always assumed that if you have good technical skills and can perform as a technical analyst (making a sort algorithm more efficent), that becoming the one to go figure out what the business needs is the natural progression you should follow. But it's just not true. There are some rare individuals that have a natural ability to work with the business to understand their requests and then be able to communicate that to the technology team so that the exact solution can be built. But most people that gravitate to technical positions do not have these abilities, and that is what makes them such good technologists. Just as the Project Manager is responsible for the overall schedule, scope, and cost of the project, the Business Analyst is responsible for ensuring the business requirements are understood and agreed to by both business and technology, and the solution delivered meets those requirements. But each member of the project team must also be cognicent of the schedule, scope, and cost, not just the PM. And each member must understand the requirements that his/her work is contributing to so they can continually test their work against the requirements as it is developed and not assume that testing against the requirements is the job of someone else later on in the project. As I have observed, the things being asked of Technology by the business to meet today's business goals and issues, are not as simple as what they asked for long ago. Back then we spent our days automating manual intensive processes, like payroll, inventory, general ledger, accounts payable, etc. These have become almost off-the-shelf packages companies purchase to do their day-to-day business. Now we are being asked for things that are more tactical or short-term operational in nature, needing to meet fleeting business opportunities, we don't have the luxury of long development times and being able to 'tweek' things as we go. We need to partner with the business, understand where they are going, what they are trying to achieve today, and what they think they need in the future. and the technologies we in IT use today are not simple and easy to fully comprehend by even some of the best technologists. So we tend to specialize, with generalists understanding the larger picture and coordinating/directing the activities of the specialists to achieve the project goals.

pmaina2000
pmaina2000

..ok all else being equal, why would you want to make $5 this week - when you can make $10? I think what they meant was that, it's better to make an *assured* $5 this week than a *promised* $10 "next week". Next week doesn't matter. It never will. Why? A dollar this week is worth more than an imaginary 2 dollars next week. Rationale: You dont know what will happen next week. Example: Say you are are in the fashion industry... Shoes may become contolled/banned substances requiring licenses to trade and then your promised earnings for footwear wont make sense! :-)

Tony Hopkinson
Tony Hopkinson

Do you mean comprehend , or see the reasoning? If it's the former, I'll explain. It's better to make $10 this week than 5$..... What about next week?. Wow you really don't get this business thing do you? :p :D

PhilipYandel
PhilipYandel

In today's economy, businesses need to concentrate on setting appropriate business goals and then developing their strategies and tactics for realizing those goals. They should not try to become technology experts and the technology folks cannot become business experts. Why not introduce an interpreter who can work with the business to understand thier goals, strategies, and tactical decsions, and then using their translational skills, transform these into a language and format that can be understood by those technology minded individuals who are being asked to provide a tool or solution for the business. This person, the skilled and experienced Business Analyst, bridges this gap and becomes responsible for both sides of the solution (business and technology) to understand the needs of the other. Let the business do what they do best, let the technologists do what they are trained to do, and let the BA help them to understand each other for the project. The paradigm shift is that the IT and business worlds are just too complex for people to be complete experts in both realms. Just as the introduction of a trained Project Manager has brought control to the project schedule, costs, and scope; the Business Analyst career should be developed and used to elicit, document, communicate, and manage the requirements throughout the phases of the project.

pmaina2000
pmaina2000

I would argue that what you call requirements are actually specifications and that "Requirements" and "requirement specs" are two different things. *** Users understand "requirements" (problem statements and use cases). *** Coders/designers understand "requirement specs" (e.g. analysis classes in UML). The "magic" still exists when converting requirements to Specs because "requirements" are seldom precise enough to be converted effectively into "requirement specs". IT wants approval on the Specs - but users dont understand the specs. Hence they give approval based on requirements. Solutions? ========================== Scenario 1: "Dumb" users: ========================== Ultimately you have to compromise and agree on specs which may not reflect the real requirement (even a single missing field can have major impact). This scenario reflects today's practice of "gathering requirements". It results in failures more often than not! Not to mention the inevitable conflict between IT and Business... ========================== Scenario 2 (proposed): "IT Savvy" users: ========================== The users develop both the use cases and analysis classes / EER Models. They have intimate knowledge of the process, business rules and data. Tech team (IT) gets the specs and implements. This would be the ideal paradigm. It requires that the "Business Systems Analyst" be a supervisor/manager within the business function - rather than an external "IT geek". Computing is now umbiquitous enough to warrant a major paradigm shift in development roles.

vanduyne
vanduyne

Had a sign when in Procurement (applie to all sorts of issues, not just this one).... "They Don't Know What They Want Until They See What They Don't Want"

Editor's Picks