Business Intelligence

Study: 68 percent of IT projects fail

Michael Krigsman examines key findings from a new report, which notes that success in 68% of technology projects is "improbable." He says the solution lies in recognizing that requirements definition is critical.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

According to new research, success in 68% of technology projects is "improbable." Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start.

These are staggering numbers, hitting the high end of the Standish Chaos Report and presenting a far worse picture than Sauer, Gemino, and Reich.

Key findings from the report, The Impact of Business Requirements on the Success of Technology Projects from IAG Consulting, include (emphasis added):

  • 1. Companies with poor business analysis capability will have three times as many project failures as successes.
  • 2. 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group's projects were "runaways" which had any 2 of: taking over 180% of target time to deliver; consuming in excess of 160% of estimated budget; or delivering under 70% of the target required functionality.
  • 3. Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
  • 4. Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
  • 5. The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.

This chart illustrates the requirements skills gap most companies face:

The impact of this skills gap is substantial, directly increasing project time, cost, and risk of failure. The "skills gap premium" is reflected in this graph:

My take. This research seems credible and insightful, intuitively corresponding to observations one sees in the field. I should mention the study talks about "companies," rather than projects, and it's unclear whether that distinction has numerical significance. Either way, the number is both high and disturbing.

It's important to quantify issues such as requirements failure, because many organizations over-estimate their capabilities in this area. As the study makes clear, few organizations perform these activities well. Let me be clearer: your organization probably does a lousy job setting up projects, which is why they fail.

The solution lies in recognizing that requirements definition is critical. Learn to make assumptions explicit; for example, if the business requests a specific requirement, do the following:

  1. Write it down
  2. Expand the requirement into a set of features
  3. Share the planned features with the business to get their feedback
  4. Rinse, lather, repeat until the technical team and the business are on the same page.

I asked Helge Scheil, CA's senior vice president and general manager of the company's governance group, for comment:

Solid requirements planning establishes a clear connection between the business case, project goals, and the project outcome.

Yes, it may seem obvious, but still many projects fail. Follow this perhaps-not-so-obvious advice and more of your projects will succeed than fail.

[Via PR goddess, Joan "have you seen this study" Levy, from Blanc and Otus.]

45 comments
Hugo J
Hugo J

I agree that poor requirements analysis plays a big role for failed projects. But many times you see that the project has failed to identify all stakeholders and how they influence the project and their expectations (not exactly the same as the requirements). The process of project planning fails in this respect. Without correct identification of the stakeholders you will ALWAYS end up with dissattisfaction somewhere. The planning of the project also lack many times one aspect - one person that can be a communicator between the IT people and the business people. Without that person/method the requirements/expectations will hardly be understood by the participants in the project.

Gabby22
Gabby22

Wow! Reading the above gives me faith in the world again. Pity the common sense here happens so rarely out on the road. I'll add a bit more, but I suspect I'm preaching to the choir. (And I know I'm repeating some of the above.) # You can never totally define all the requirements (well, almost never). This is just a warning. It's no excuse to avoid needs analysis, or to rush into incremental models. # The upfront analysis will help you plan and cost your project, not just the needs, but the environment, the change management etc. In my experience, it will also enable the project to be cancelled earlier (which is good). # Most users and managers are hopeless at business needs analysis. So are most developers. It needs a special mindset and special skills. # I've seen many apps and enhancements that fail simply because they end up not being used. They met their requirements OK, but they were based on unrealistic assumptions of how staff work, or the business processes of the org were too weak, or the changes in work practices were not supported elsewhere. (This backs up the issues of change management made by others here.) # The difference between requirements and design is too often misunderstood. Start by realising that one person's requirements is someone else's design. The initial post said "Expand the requirement into a set of features" which confuses the issue, muddying one of the design steps (which is not 'expansion' but a crossing of the design gap). For many business software projects, I see at least the following requirements/design products/activities: - Needs: what will you use it for, why, when, how, constraints, etc.). This one is often skipped, but it's the most important. - Features: what the software will do. - User interface: how the features will look in the app. - Software: the actual code, test, etc. Note that the user interface design is the requirements for the software design. For new projects there will also be an 'architecture' or 'system design' product/activity, after the Features product. As others have said, the business case is also a critical product. More at http://users.tpg.com.au/users/agabb/ if you're interested.

AlbertZr
AlbertZr

It is no wonder that they found this: 70% of organizations just don't have the organizational maturity to produce successful projects. First of all, the report is a marketing tool. They need something that scares people. Well, with research you will get what you are looking for. The first question that came up with me is: what do they mean with 'Good Requirements Management(RM)'. In the first part they say nothing about it, they only hint that 'Good RM' is RM as they (the sponsor of the report) teach it in their trainings. In the second and third part they suggest quite generic guidelines. But, I guess they really mean that you have to buy their consulting and training. How did they sample the organizations? They are not clear about it, but with a bit of irony you may think they provided their own customers to the research team... Another question is how do these findings relate to organizational maturity? You know CMMI and so? Again they leave it vague, but there are some remarks that make you think. For example: "Only companies that focus on both the process and the deliverables are consistently successful at changing project success rates." Sounds like level 3 to me. "...since companies do not collapse as a result of poor quality analysis. In fact, IT organizations and stakeholders involved will overcompensate through heroic actions to deliver solid and satisfactory results." Sounds like on the border of level 1 and level 2 (falling back to heroism if processes fail). How many companies in the world are really level 3 and above? I can't find the data, but found at SEI that of appraised companies (if you want your organization appraised you will target level 3) 20% of companies don't really make it to level 3 at another place I found that in 2000 there was only 1 of a sample of 60 companies that made it to level 5. Given that most companies don't even try to be at any CMMI level, given the examples in other replies here, and given that in surveys you can make your company shine better than it really is, I think 68% is a low number for the complete population. I think that requirements management will only have an effect if the organization as a whole wants to achieve defined (level 3) or better processes. If projects fail it is not only because of requirements management, the organization as a whole fails. And companies who want to go up a level are more likely to hire a company like the company that ordered the research for the report. If you address only requirements management thinking that that will help, I am sure your organization will not achieve its goals and fall in the 68% whether you hired the maker of the report or not.

wbeddoe
wbeddoe

Great comments to this topic, they should be consolidated and made into a white paper. Two main ingredients for project success is a strong BUSINESS CASE with top-level commitment and ACCOUNTABILITY of project owners (business & technology) when targets are missed for whatever reason. Major projects require real involvement by steering committees to make sure the right strategic issues are being raised and addressed.

afbrown
afbrown

After reading a number of the responses to the article, I have made a single observation that is meaningful to me. After 40 years as a developer in the computer industry, in my opinion, the one overriding factor that "made" projects fail or succeed was "Change Management". Only one respondent even came close to saying it. It isn't that the BA's got it wrong or that the users didn't know what they wanted, or that the Req specs were incomplete, too monolithic, or too rigid. It isn't something you do only after you deliver the project. It is something you do before you complete the design, during the design, after the design, during the coding, after the coding, during the testing, after the testing, during the life of the product. And not to be forgotten; after you retire the product figure out the reasons it survived or died. I wrote applications nearly 40 years ago that are still in use today. Why do you think that is? Cheap customers? Some cases, yes. Flexible application design? I prefer to beleive this. It does cost more to design and create a system that is flexible enough to survive 5 years much less 10 or 20, but that is part of your responsibility when presenting the concept to management. Rigid systems do indeed survive, because in some organizations such as state or federal government, sometimes the same users who were there when the application was put in place are still there now 30 years later. The users are just as inflexible as their application and will defend all attempts to upgrade or "modernize" some aging system that will run only on equipment out of manufacture for 20 years or more. In some cases the reason is just plain simple "There isn't enough money in the budget." It's funny but I actually believe that we did better upfront analysis decades ago, as an industry, than what is done now. At times, in order to learn what to create we were invited (ordered?) to go out and work out on the shop floor to learn what it was we were automating. I haven't seen much of that in the past decade or two. It is also true that we did not have the desktop PCs and software that allowed us to create elaborate and powerfully suggestive presentations. We had to do our work by hand and typewriter. I wonder if that helped us to "think" it through before we spent all of that time writing or typing those presentations. Anyway just some old guy blathering on. Good luck in the future.

robin
robin

The conventional requirements model referenced in the study invariably still leads to considerable creep because it goes from largely presumed high-level business requirements (which may or may not be accurate and complete, but usually are neither) to detailed product/system/software features, which really are design of a presumed solution for the presumed but usually inadequately-defined REAL business requirements that provide value when met. See my recent Artech House book, Discovering REAL Business Requirements for Software Project Success.

saqgoku
saqgoku

This ia an alerting report, and one that requires a lot of quiet attention. The question that needs to be asked, what is the number of IT requires that must be followed and are they easy to remenber? My answer, too many and not really.

RGRinc
RGRinc

Doesn't this dovetail with the numbers for success of projects in general - 34%? Perhaps a holistic approach is needed. Regardless of the type of project, in general, project requirements is the point where molehills are formed that are destined to become mountains.

addicted2speed
addicted2speed

This is not such an epiphany for those who consistently roll out successful projects (or products)... Just ask Toyota/Honda/BMW/Volkswagen etc. Rule #1 must always be to truly understand what your customers/clients want... even if they do not articulate it accurately or in terms that directly translate into Business Requirements. Constantly refine and verify with the customers to confirm that you truly understand what they want. Then ask a few more times. Do not become arrogant or overconfident simply because their answers become predictable or consistent. In the case of IT, the customers are the business units. For automakers, it's the car-buyer. You have no chance of success if you don't even know what your customers want - unless you're incredibly lucky or magically intuitive in which case you really need to buy a lottery ticket or something.

mikifinaz1
mikifinaz1

Just look at who and how. It took the auto industry a century to get its act together; expect no less of the computer industry, particularly since there is less common sense in the crowd.

jdclyde
jdclyde

When there is a new package, all the end users sees is one more thing they have to do, that they didn't have to before. That it may save them a lot of time in other areas is not thought about. Another issue, many of the packages are for gathering information to allow upper management to make better decisions, but the people in the trenches are smart enough to know that the less information they give out, the easier it is for them to fudge where they have to. If the package isn't "sold" to the rank and file on how THEY will benefit from it, they will find ways to make it fail. Of course, feature creep is another killer of projects.

Tony Hopkinson
Tony Hopkinson

Poor requirements, my arse. This study says, after they finished/abandoned the project, if they had known everything they needed to know at the start it would have gone better. Right now Mr Obvious has STFU, how do we cope with the fact we are not yet in a position to measure how bad the failure is...... It's really very simple, Change is a given, cope or fail, cope does not mean fail to take it in to account! If the goal turns out to be undesirable, stop ! If it moves, stop shift and head towards it. Why do IT projects fail, because some pratt somewhere chooses to stick to their old plan. Whether that's a developer's implementation, a PMs dashboard, a BAs heartfelt dogma, or a beancounters bottom line. If you aren't close to reality, all your succesess are imaginary. Small iterations, evaluation of unknowns, identification of risks, awareness of scope, management of expectation. Get the basics right, cease with this chimera of 'perfect' requirements. I've been hearing this crap for twenty plus years and I'm getting damn tired of it. It projects are not being managed they are being controlled. The difference between those two concepts is amply highlighted by the statistics.

reisen55
reisen55

First the information tech group (what little is left of it in America and not India) HAS to come up with realistic time, cost and result estimates for a project. Do not shortcut this. Then all three are delivered without sugar coating or hyperbole to management. Real stuff. Then results have to delivered to management as it progresses along, stumbling blocks will be encountered and the unexpected always shows up. Be bold and truthful. Testing along the way. Again, results. And if you are honest and smart and do enough preliminary work and study and testing, you've got a good project. Management may even reward you with a bonus and then outsource you because you've cost the company too damn much money.

minstrelmike
minstrelmike

At one government agency I worked, mgmt decided we needed a new system. We set up a user meeting and the various agencies across the nation sent whoever they could 'spare' for a week. They sent folks they didn't need in their office. It was horrible. At a different agency, mgmt decided they wanted a new system. We canvassed the users and decided which roles needed to be represented at a requirements meeting (State director, beaver specialist, district supervisor, etc.) Then mgmt decided who the best people would be in these roles and told the State Supervisors they had to send them for three separate one-week meetings. That project turned out well. Design is the _only_ part of the project where it is possible to add value faster than you add costs.

Steve Romero
Steve Romero

For the sake of discussion, I will assume the data and conclusions are correct. I would never argue the absolutely critical aspect of good requirements. But once again I am troubled by the specified and implied recommendations. The focus appears to be on the business analysts and the requirements process - which should result in focusing on improving the function and the process. Great! But what about the lack of good governance that should be identifying this deficiency in the first place? At best, good governance and the associated executive oversight identifies the lack of good requirements when the investment is first proposed. At worst, good governance and the associated executive oversight identifies the lack of good requirements when the projects have been completed. In either case, this governance would invoke the necessary improvements to the requirements process and business analyst function - or any of the other problems or issues related to project and portfolio management. Until this governance and executive oversight is in place and functioning properly, these studies just give executives the excuse to point fingers at the worker-bees who are struggling to succeed in its absence. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

JCP1
JCP1

I agree with the findings. However, even when companies recognize this fact, they do not provide adequate or appropriate training (they fail to recognize that it is a competency). Another issue also involves the type of methodology used to gather requirements. The method used must produce accurate requirements of good quality in a short amount of time; otherwise, the project might get stuck in 'analysis paralysis'.

StilesR
StilesR

This syndrome is not particularly new. The numbers seem higher than Barry Boehm's "Software Engineering Economics" suggest. If so, we have been going backwards in terms of effectiveness over the last 20 or 30 years. My immediate reactions were; 1. "Why haven't you started coding yet" is not dead! 2. We imagine that the artifacts that we produce for requirements specification produce agreement of the parties. Their approval is more likely to represent fatigue rather than a meeting of the minds. 3. Our Requirements Specification document do not often reflect viewpoint and context. 4. Terminology is not defined between users or IT. If you don't believe this last google requirements definitions. 5. Artifacts are still representing an IT centric view.

Cory M
Cory M

I believe there are a number of issues leading to project failure, some are rooted in BA skills, many are not. examples I have seen: -dates agreed to before project scope defined -system rewrites use old system as the model "make this look like that"--never works asa requirement -users don't know what they want until they see it (design during test) -SME's are stretched too thin during develop and test causing the timeline to extend -programming resources not available during test phase--more bugs than planned are found and they cant be tested quickly enough -not enough time allocated for adequate system and integration testing so it runs over schedule -business needs drive project schedule (i.e a major new product release) and nobody negotiates project scope to something close to possible -change controls are not used to adjust project when issues are found (often due to political climate, no bad news allowed, so project fails at last minute even though project team knew it was in trouble for some time) -PM's that don't know how to ask probing questions and use intuition to get at real project status, so slippages are not uncovered

ajn25
ajn25

Most of the projects fail due to IT management politics coupled with Finance downsizing the project budget. Until IT Management is perfected, projects will fail.

managedbymom
managedbymom

I'm thinking this number is actually quite low. But I'm not suprised. I've been a tech temp and consultant for almost 10 years now and these problems come to the same point repeatedly in my experience. 1. Companies won't pay to do it right. 2. Custom software testing is absent. 3. People without technical expertise modify the plan, removing critical components that would make it go smoother. 4. The lowest bidder/fast talker wins - but can't deliver or charges "extra" to do it right and fix what was started. 5. Hiring people they know, regardless of skill rather than experience. Hiring students or "fix what we dropped in people". 6. Not checking with other customers for references and satisfaction about completion of their projects. 7. Blaming IT for problems you warned them would happen by cheaping out or changing the plan. 8. ***Not providing training for those who will have to use the systems - users. This isn't exclusive to IT - take a look at most organizations, municipalities and operations - anytime you shake your head and go - they did what?

Hogie51
Hogie51

What a great stream of ideas about this very important part of the creative process, developing a product to meet a CUSTOMER's requirements. I loved afbrown's perspective and, as an oldster myself, I have to agree with him that requirements development were more detailed in the past than today. But that's true for many things. The idea of making anything for/with someone else is a give and take arrangement, never static, and always has a potential - maybe a destiny - for change. Whether it's a car, a house, or a SW project. Creation of something new involves both the artist/craftsman/developer/machinist/designer AND the customer/owner/user in creating something useful and elegant that could not exist without each other. It cannot be successful as an "us against them" whoever the us and the them is. Using Business Agents or Project Managers can be part of the process, but it begins with a desire by different parties to work together to create something. To do their best for each other. each side sets out their own requirements and limitations as they explore the project and it's risks/rewards for both. Men/women, Sales/service, Customer/provider, IT/business, it's all about customer service and respect for relationships. When that breaks down, it all goes to hell.

mkrigsman
mkrigsman

There is no generally accepted statistic for the rate of failure on IT failures. Would you share where you got 34 percent?

PhilipYandel
PhilipYandel

Big Requirements Up Front methodologies just don't work and anyone that thinks that everything can be known and agree to at the very beginning of a project is just a fool or someone that has never actually done anything of any size. When I see projects at my company trying to get the requirements completely identified, documented, and signed in blood before we take any steps to designing a solution, I just shake my head in amazement that they actually ever deliver anything of value at all. But I guess a stopped clock is right once or twice a day, so miracles may happen. I feel that for too long, IT has been notorious for not taking the time to understand what the user really was asking for. It was either an "we know what you need" or "start coding, I'll ask them what they want" attitude where the object was to deliver a product. but that may have worked back in the day when we were automating the larger business practices like AR, AP, GL, HR, etc. Now a days, the business needs change quickly to meet market demand and pressures. We don't have the luxury of knowing everything before we begin, but we should understand the business problem/issue/goal that we are trying to solve. The minor requirements that we need along the way cn be discovered as they are needed to be discovered as we iterate or move incrementally towards a planned solution. But PM's complain that it is hard to estimate, schedule, and manage an iterative or incremental development project, so they woud rather stick to the tried and true (failing) waterfall process. And then they try to figure out ways to punish the business when new requirements or refinements are discovered as more detail is known. The PM's goals are to complete the project on time, within budget, and for the originally agreed to scope. The BA should be the advocate for the business, the one fighting to make sure that what is delivered provides value to the business and directly contributes to solving their problem or gaining their goals.

mkrigsman
mkrigsman

Both are important. This post dealt with the requirements issue, however. Business analysts are often the intermediary between business groups and IT. When the "translation team" is biased, or doesn't fully understand the issues, then of course the project will fail. That's not a governance issue, per se. It's an HR issue, quite frankly: need to hire better folks. By the way, see my podcast today with the CIO of Univ of Wisconsin-Milwaukee today, on the IT/business alignment issue: http://blogs.zdnet.com/projectfailures/?p=1185

PhilipYandel
PhilipYandel

Steve, too often, I've seen IT departments that put together their methodology but never implement a continuous improvement program where they collect metrics along the way of each and every step in their process. Without measurements it will be that much harder to determine if the process is getting better, worse or even being followed correctly. We spend a lot of time defininig the process and then think we must have gotten it right because we are done. Without some type of feedback or governance, we are doomed to keep repeating our stupid mistakes over and over again, never learning from experience what works and what doesn't.

PhilipYandel
PhilipYandel

How insightful to suggest that we in IT have somehow forgotten that we are performing a service for business people who probably don't know much about technology except how to sign-in to MSN or AOL. Too often we expect our business partners to speak our jargon and appreciate all the little techie artifacts we produce that don't mean a darn thing to them. And then we call them 'dumb users'

RikDee
RikDee

...I've seen some of the same myself. Add to that: -Inadequate project sponsorhip. Projects that either consume people's time or will change the way people work need strong support from the top. Otherwise, people critical to its success will either ignore it, not contribute enough, or sabotage. -"Big bang approach". If you try to build a mansion all at once, instead of small rooms at a time, that people can use and appreciate, several things will likely happen. One is that interest, cooperation and support will fade when people don't see something tangible soone enough. Another is that the people bulding the system won't share a portion of the solution with the client, have them use it and give their feedback for enhancements. This is necessary, because, as you mentioned, most users don't know what they want until they see it.

minstrelmike
minstrelmike

The real problem failure occurs is because success is not defined properly. A developer thinks success is having the module compile. A project manager thinks success is meeting the deadlines. A user thinks success is having a new system to use. But to a business, success is solving a problem. If you aren't willing to take the time to clearly define the problem, then you cannot clearly define success and it gets redefined as whatever the scope of the employee's involvement is. It is a management problem. It is easy to spend money. It is easy to develop software. It is easy to meet deadlines. What is hard is solving a business problem, especially if the business managers cannot, or more accurately 'will not,' clearly define the problem.

PhilipYandel
PhilipYandel

Without siting where you are coming up with the facts to substantiate your bold assertion, I would have to slough it off as your own personal unsubstanteated biased unscientific observation. Most credible research shows you are incorrect and that the vast majority fail because they do no deliver what the customer actually wanted or requested, or was unusable by the business once implemented. Just Google "Project Failure" - www.standishgroup.com www.focusedperformance.com/toptenpm.html www.it-cortex.com/Examples_f.htm

JuanVelasquez
JuanVelasquez

@managedbymom 

I've been a consultant / developer for about ten years also, and I have to agree with you.  Sometimes it's an issue of corporate culture where people are resistance to change and management has not included the people for whom the application is being designed, in the process.  But all in all, your eight points are right on the money.  In fact, I've just declined a contract because, based on my previous experience, I saw the word disaster written over that project.  As the main protagonist in Monty Pyton's The Holy Grail, the project just screame "Run away, run away"

Tony Hopkinson
Tony Hopkinson

All too often the relationship is adversarial, not partners, but enemies. Look at any piece of IT, costs nice hard numbers. Two servers, some licenses, ten weeks development time. Benefits, generally much soggier numbers. So where is the easiest place to maximise, cost ! For both parties, you pay less, you get less. One vendor I used to deal with for an employer, used to employ really top people to get a job, and coders who hadn't graduated yet, to do the job. Anyone want to take a wild guess how that worked out? Come to me and ask for the cheapest CRM system ever, you can have it. Don't whine about it being crap though, that was one of your requirements.......

Tony Hopkinson
Tony Hopkinson

I agree BRUF doesn't work, nor does BPUF (big plan up front !) Why didn't we meet the the customer's requirement. Waht do they really want. They want a CRM style system so they can offer legal services from accredited partner when selling mortgages.... They want to leverage their customer contacts for other business's in return for a cut. So now we have a generic configurable CRM, versus, a very sepcific one. One is less work than the other, and therefore cheaper and quicker and meets the currently identified need. Guess which one get's chosen. Guess how many 'hard coded' design features get implemented. Guess who's not happy when they take delivery of the product just after the property market, takes a wee downturn Notice, not one mention of any implementaion detail, approach, process, method in there. Control of the meeting the requirement is achieved by setting the requirement in stone. You might not be saying that, but you are using the tried and trusted nomenclature of those who attempt it.

mkrigsman
mkrigsman

When an IT person displays such obvious contempt for users, it reinforces all the negative stereotypes. Just not a good idea, in my opinion.

Gabby22
Gabby22

Although incremental approaches are often an excellent way to go, at least for the latter stages of the project, I've often seen them used (and promoted) due to *inability* of the developers to analyse user needs at the start. In some of the biggest failures I've seen and read about, the basic architecture was flawed and this was only found out late in the piece. Incremental won't fix this - it's a matter of "if I wanted to get to Dublin, I wouldn't start from here!" I've also seen many enhancements later rejected on the basis of costs, where the cost would have been trivial if they'd been thought of in advance. The trick is knowing (a) how to find the user's needs, (b) how to analyse and expand them, (c) which are the major cost and performance drivers (now and later) and (d) knowing when to stop. To some extent this is fueled by experience and learned skills, but attitude and risk management are also critical.

PhilipYandel
PhilipYandel

The role of the Business Analyst is to work with the business to clearly understnd the business problem/issue/opportunity/goal that is at the heart of the project. The BA should have the skills and the experience of working with business people in order to discover the underlying requirements that must be met by the roject in order to declare the effort a success. If the business cannot define or agree on the criteria for success, in other words, they don't know what they want, then it would be utter foolishness for the IT group to move forward on the project because it is doomed to fail. A good BA sees themselves as the business representative on the project, like an advocate for the business requirements, making sure they are understood by the business as well as the tecnology teams. A bad or poorly skilled or inexperienced Business Analyst will not hep with leading the effort to meet the business expectations.

Tony Hopkinson
Tony Hopkinson

Don't deliver what the customer wants is a consequence of failure, not a reason for it! Why didn't the customer 'get what they wanted', because for many reasons, many involving management, if only of expectation, we failed..... It was you, no it was him or them or it, or Mr Nobody. While we don't understand our contribution to failures, all other failures are irrelevant! www.itwashim.com www.itwasnotme.com

asics447
asics447

In My experiance bigger organizations it comes down to politics, money and power. They really dont care just get it done with no training - set horrible timelines and really dont understand what is involved get-r-done Smaller companies I have greater success in projects Just my experiance

Tony Hopkinson
Tony Hopkinson

Depends on who you are measuring success for. Success for a Customer, a developer, a PM, a business. All different criteria. Essentially there are only two definitions of success. Was your customer happy and did you make any money off putting smile on their face. All else is meaningless bollocks specifically designed to describe failure as success. If I develop what I was told to develop on time, and I had no way of knowing (or I was ignored) that it was rubbish, then I as a developer have succeeded. Stoopid, but true. Look at every failed project, change was not handled it was either uncontrolled or denied.

PhilipYandel
PhilipYandel

Tony, I am very interested in how you suggest we measure whether our projects are successful or not. What criteria do we use in order to determine whether we did a good job or not? In many cases, the implementation detail, the approach IT follows, the IT process, their internal development, testing, and deployment methods don't mean a hill of beans to the business, nor should it. When I bring my car into a mechanic to be fixed, or enhanced, or whatever, I know what I want the end result to kind of look like. I want the noises to stop, I want the pulling to the left when I brake to be gone, I want the vibration in the front end at high speed to be eliminated, I want the little red warning light to go away. How the person approachs diagnosing the underlying causes or which tools they use or over what street they test drove it on is more than I care about. How much did it cost compared to their estimate, when was it ready, and are all the things I wanted fixed actually fixed? As a Business Analyst, I am responsible for the business requirements. making sure that the business customer knows what they are asking for as well as what they are not asking for (scope), and when they change their mind or think of something else to be included, it is my job to help them to make the business decision on whether the impact of their requested change justifies the expenditure. I never want the business to feel that I tell them they cannot make any changes, but I do expect them to understand that some times changes are expensive. But if the change is absolutely necessary for the business to meet their objectives, then the change should be made. Controllinig changes does not mean stopping change (unless you are a Project Manager), it just means intelligently making changes when justified and understood and accepted by the business. It also recognizes that not all aspects of every requirement or whole requirements are fully known and that change is inevitable. How change is handled, who decides which changes are permitted, are just mutually agreed to project terms when you take on the project. Again I'll ask: If not by "how much did it cost?", "how long did it take?", and "did they deliver what we agreed to deliver?", how do you define success?

PhilipYandel
PhilipYandel

I guess it all depends on the business model being followed. Many tmes, the people assigned to the role of BA by the business are not necessarily those individuals with in-depth knowledge of the business and it's strategic/tactical goals. Many times, these are lower level people without adequate training on how to do requirements elicitation, documentation, and management, and have no idea how to translate business requirements so that they are understood by the technology folks that need to implement them. But taking a good technical developer, even with years of design experience, will fail just as badly if they do not have the skills or mindset that the professional Business Analyst MUST possess. In our IT organization, we have people that are responsible for managing the overall relationship with each business area of the company so that they can understand where the business wants or needs to go, as well as to keep them informed regarding other IT initiatives or projects that may be of interest or impact to them. When the business makes the decision to move forward on an initiative, the RM (relationship manager) engages the business' Solution Architect as well as IT's Business Analyst. The BA and BSA work together to define the business problem or opportunity, and then we work together to discover and document the requirements. I guess your model is different than ours, and I would agree that the SWAT approach, where some strange IT professional drops in out ofthe blue (and probably not even invited) to impart their wisdom and tell the business how to do their job better, this just doesn't work very often.

pmaina2000
pmaina2000

A business analyst should not come from IT/IS. He/she should be one of the people in charge of day to day operations. Someone who has INSIGHT into the business. Currently IT sends a business analyst who, being an IT guy is more interested in technology than business concepts. Business is generally incompetent when it comes to managing projects (they use the same management techniques that are used in Operations). In view of this, I think its better for IT to bring in the Project Manager whereas the business brings in the Business Analyst. The two work together - with the Project manager as overall leader. Imagine someone coming to your house to learn what you do - and then tell you what you need to improve... would you believe that he/she knows better after staying with you for 1 month - yet you have been in the house for 20 years? Wouldnt you prefer to be the one who determines your needs? In the above case, no one has to "gather" and "understand" requirements. Over many years, I have isolated this "gather and understand" issue as the cause of friction between IT and Business. If anything goes wrong (whether real or imagined), the IT guy will be told he didnt understand the requirements. How does he/she respond? Even the signoffs dont take away the blame game. I have used this model several times with consistent success. On time, on budget and with required functionality.

eiwacat
eiwacat

Perhaps more agreement exists than you realize. I have worked with many poor analysts and a couple great ones for a couple different companies. Unfortunately, they were treated the same by management teams in place. The poorer ones were not given or required to take additional training to better their skills. The great ones moved on as did many developers who grew tired of not being heard or chastized for taking more time than expected to produce. Even today, my current management has hired a "business analyst" who they adore but who has never written a formal requirement document. I receive Word documents with handwritten notes driven by existing screen displays. The analyst does not even want to consider the best practices documents that I send back for her approval, claims that developers are being difficult when we keep asking questions and does not care to listen to why certain things are needed. We no longer complain as we are told to get along. So eventually we will all get along to the next position. When an employee's skills are not up to par, it is management's job to let them know and give them an opportunity to rectify the problem. Good management does not let bad requirements-gathering (or no requirements-gathering) occur.

Tony Hopkinson
Tony Hopkinson

Of course we need to understand the problem. Of course we need some approach to solving it. Of course who ever receives the end product, is going to judge failure or success. No one can know all the requirements, no one can predict external impacts, in implementation or perception. No one can predict, how the process of doing teh project will change the perceptions around what it was meant to achieve. That can only be done in perfectly understood static environment. The only one of them I've ever seen, was in a readonly MS project file, that had no contact with reality. Doing the wrong thing is rarely a total misunderstanding of the requirement, very often it's a denial that the requirement has changed. Even business issues cange , how many people in the property business were concentrating on software to reach more people to lend money to?. That was the business issue. Change is a given, all requirements are 'was' as soon as you write them down correctly or otherwise. The bigger the project, the more out of step with reality you become, the more opportunity for external factors to impact. Do a bit, reasssess, do it more reassess some more. For Cthulu's sake remember your are asessing against the current requirements not the old plan. We aren't managing projects we are attempting to control (basically stop) change. That can't be done so that's why we fail. Your orginal plan being found to be rubbish in the light of new information is not failure. Failure is pretending the plan is still god. Manager's, BAs, developers, PMs and panda masturbators makes no difference.

PhilipYandel
PhilipYandel

Tony, I respectively disagree with you. If the Business Analyst does not take the time to understand the business issue, problem, goal that is trying to be resolved or implemented, if the BA doesn't know how to manage the requirements through the life of the project, if the BA cannot represent those business requirements to the technical developers and testers, then we end up building a wonderful, sometimes eligant solution to the wrong problem. Is the project a success just because we THOUGHT we did what they wanted? Or do we measure success on how satisfied the business is with the solution that was delivered and how well their expectations were managed? So what are your ultimate measures for success?

Editor's Picks