Tag: Development

Business Analyst Development in the Insurance Industry

Written by Cynthia Low on October 1, 2008. Posted in Articles.

Transformation. If the topic was not in the last Board briefing, it was in the one before that. A Celent review of the websites of largest 20 property and casualty and life/health insurers found the theme of business/operational/company transformation featured prominently on 40% of them. Major investments are being made in new technologies across multiple areas-policy administration, rules engines, predictive modeling, workflow managers-to change the way business is currently performed.

Enterprise change happens on multiple levels and with the effort of many individuals. It cannot happen without modifications to business processes at the transaction level, as committed employees work with business owners to analyze changes to the way work is done. Once that analysis is complete, support areas such as IT, HR, and Operations must work to implement the new methods. In most insurance companies, the people responsible for identifying, facilitating, documenting, and communicating the new business requirements are the business analysts.

In the Celent report The 18 Month Rule: Avoiding The Endless Project, (November 2006), it was noted that “between 30% and 80% of all large projects fail, with most estimates coming in on the higher side of this range.” The definition of failure is a project that is not fully implemented on time and does not meet the original requirements.

With this in mind, what is the state of development of the critical business analyst function in the industry? Celent researched leading insurance firms and found that the professional development of business analysts lags that of other functions. In many cases, the job lacks clear definition and boundaries. Skills are often learned “as and when” through individual effort and initiative. BA development has been described as an “afterthought.” In contrast to the underwriting (CLU, CPCU, IIA), claims (AIC), and project management (PMP) designations, there is no industry-wide accepted certification of business analysts.

The good news is that disciplined, structured development programs in the insurance industry exist and have been recently implemented. These initiatives have been justified by a disciplined examination of the role and the contribution of BAs. This report examines these initiatives and also outlines the business case. Additionally, action steps to move business analyst development to the next performance level are detailed.

What is a Business Analyst?

The business analyst operates at the intersection of business users and information technology. (Note: Since so much business analyst work is IT-related, in this report IT is used as a placeholder for all of the support groups necessary to implement new/revised business requirements.)

Core business analyst (BA) tasks deal with requirements definition, acceptance test case development and execution, and client communication. Defining requirements can include business process design, use case development, and user interface specification. In companies without a dedicated Quality Assurance area, BAs play a prominent role in acceptance testing and may be involved in other test activities (system and or integration testing) as well. The BA is also recognized as a subject matter expert, having earned this designation through many years of experience with a specific business function or transaction system. Project management tasks can also fall to the BA, especially in smaller organizations or for implementations of limited scope. Emerging duties of the BA include the creation and maintenance of automated rules in rules engine applications, responsibility for business process management (BPM) tools, and the use of automated requirements generation tools.

Table 1: BA Duties
Always	Sometimes
Requirements collection, definition, and communication	Other testing (system, integration)
Acceptance testing	Subject matter expertise
Client liaison	Project management
	Creation and maintenance of automated business rules
	Business process management automation
	Use of automated requirements tool
Source: Celent

Organizational responsibility for business analysts varies. In some companies, the BA is part of the business. In others, the BA is firmly within IT. More than one insurer shared the fact that, in their company, reporting relationships for BAs periodically move from one side to the other.

The notion that wide-ranging tasks and changing reporting relationships create problems for BA development is a recurring theme in discussions with companies. One of the first tasks that leaders take is to build a fence around the duties of their business analysts. Bringing focus to the function is a key success factor in the leading development programs.

On the other hand, it does not seem to matter whether the BA resides in IT or in the business. What is critical is a corporate investment in the group and sustaining it over time.

When asked, BA managers describe the “ideal business analyst” using descriptors of both skills and personal characteristics. The skills required deal with a keen attention to detail, a “real world” knowledge of the business (especially company-specific operations, systems, and workflows) and effective verbal/written communication. However, because requirements gathering can be so relationship-focused, the best business analysts employ large amounts of empathy and influencing skills. Celent believes that the need to be able to “walk in a user’s shoes” and to exhibit an appreciation of their challenges at the coal face level tip the scales in favor of sourcing BAs from the business rather than from IT.

Table 2: Business vs. IT Sourcing of BAs-Skills Prevalence
Skills / Characteristics	Business	IT
Attention to detail		
Systematic thinking		
Structured analysis		
Deep understanding of the business	
Communication	
Empathy	
Influencing	
Source: Celent

Clearly, BA development is complex and sophisticated. This is not a “just add water and mix” HR exercise.

The Business Case

How do advocates champion the cause within their organizations? Most of the reported justifications are qualitative, but a quantitative case can also be made to justify investment.

Drivers of the change in companies already pursuing a more rigorous approach to development were varied:

Desire to support an outsourced IT model with more rigorous analysis by internal resources
Sponsorship at a senior leadership level
Need to backfill for an aging employee population
(demographic trends)
Recognition that the requirements development process needs improvement
Adoption of new tools such as business rules engines

In some cases, a more financially based approach may be necessary to motivate investment. One method is to approximate the dollar value that is dependent on quality BA execution to deliver the full benefits estimated for a project delivery.

For example, assume the net benefit from a system build and implementation is US $6.25million. Using a typical life cycle framework (SDLC), estimate the percentage of the total work effort attributable to each phase. Multiply this phase percentage by the total benefit to arrive at a benefits-by-phase accrual. Then estimate the BA contribution percentage for the each phase. Multiply the BA contribution percentage for each phase by the benefit contribution for that phase, and the result is the BA dollar contribution by phase.

The BA contribution is highest in the requirements phase (80%), and very important in acceptance testing (65%) and implementation (50%) efforts. Using these assumptions, the model calculates that 41% of the total benefit of the entire project depends on the performance of the BA resource on the project ($2,546,875 / $6,250,000). The costs of a BA development program compare very favorably to the income from only a single project.

Conclusion

Successful transformation efforts will invest in the skill development of business analysts. The bad news is that this function has historically not received the attention it warrants. The good news is that there are companies with formal, disciplined programs that are in their second or third year of operation and are beginning to deliver results.

If improved delivery of transformation initiatives is part of your company’s strategy, Celent recommends that you:

Identify a senior leader to champion the effort of business analyst development.
Establish a certification program for business analysts in the next three months; get the program up and running immediately and perfect it later.
Pay for any registration and exam fees for employees pursuing the certification.
Implement bonus award recognition for employees who successfully complete the certification.
Commit to a goal: If there are no certified BAs in your organization, commit to completing certification of 5% of the BA population in the next year; if there are employees certified, issue a challenge to the company to double the number in the next six months.
Create a professional career path for BAs; if feasible, establish a. AVP or VP level business analyst leadership position.

If your company is investing in BA development, redouble your efforts and maintain your lead. If it is not, it is time to begin.

Mike Fitzgerald is a senior analyst in Celent’s (

www.celent.com) insurance practice and is based in the firm’s Chicago office. He has particular expertise in property / casualty automation, operations management and insurance product development. His research focuses on underwriting and policy administration, business process and operations, billing, and project / program management. Prior to joining Celent, Mr. Fitzgerald was Vice President of Enterprise Underwriting Solutions of Zurich North America, where he led the evaluation of technology alternatives to support a new underwriting product development process. He was a business architect at HCL Technologies America, and held a number of positions at Royal & Sun Alliance, including a regional operations executive role. Mr. Fitzgerald began his career as a business analyst. Mr. Fitzgerald has a B.A. in economics from Davidson College in North Carolina and an MBA from the Fuqua School of Business at Duke University in North Carolina . He is a Chartered Property Casualty Underwriter and a certified Project Management Professional. He can be reached at [email protected]

The Business Case: Is It the Next Agile?

Written by Terry Longo on June 16, 2008. Posted in Articles.

In earlier blog entries I discussed the notion that not requirements but the business case should be the center of the BA’s existence, and that the business case must somehow account for the costs and risks of the components comprising the intended solution.

The notion of agility is one of the primary tenets for dealing with change. But how can there be so much discussion about Agile Development, Agile PM, and Agile BA without also discussing “Agile Business Case Management”? After all, software development, PM and requirements activities are driven by and exist within the context of the business case. Before continuing, I want to acknowledge absolutely that, from a level-of-effort point of view, the specific activities around requirements management are the most demanding aspect of BA. But as requirements exist within a context of constant change from within (project dynamics) and from the outside (business dynamics), when focusing on the requirements themselves, how do we know when the business case needs to be revised and reconsidered due to those changes?

Anecdotally, in bringing up this question with my audiences at the Seattle and Denver BA Symposiums, there was general acknowledgement that requirements management is currently the main focus of Bas, and that the business case frequently falls by the wayside, once solution development commences.

Is this the case for you? What are your best practices regarding business case management to ensure that it continues to be revisited in light of development, operational, and/or business changes? When your business cases are created, do you specify boundaries (cost, risk benefit, etc.) beyond which their relative value is lost?

Why I Love Being the Vendor

Written by Cynthia Low on March 31, 2008. Posted in Articles.

There are two sides to the business analysis community: The internal business analyst and the external consulting companies or contractors … “Vendors”. Being the internal BA just isn’t much fun sometimes and often, the internal policies and practices can work against your success. Sometimes it’s the company itself that has created a requirements analysis gap and the individuals – however strong they might be – just can’t be successful. Entrenched, hierarchical, corporate cultures will always work against the internal BA unless a company has made the leap to reset the value and position of BAs within this hierarchy. In spite of all these challenges, I’ve also seen internal organizations transform themselves from being order-takers, to being considered highly valued business drivers. So often the difference in mindset for those that succeed is they’ve started to think like vendors.

As a vendor, I get to dictate the process or our company does not do the engagement. This is a strong position – we’ll only do engagements we know will be successful, or we (subtly) take a pass on working together. Vendors work from a position of strength and build up our “referenceability.” If I can say “we’ve done over 1,000 of these” and give specific examples, people generally listen when you tell them “this is the way it gets done if you want success.” Sure, the vendor has to tune the process around the edges to improve the fit with existing internal processes and issues, but the essence of how the work will get done stays the same on every engagement. By negotiating the process of requirements discovery up-front, by identifying precisely where additional costs might exist, or how to tune their process to meet their specific business objectives, a vendor walks into an engagement with a higher level of commitment to the process than you would see on most internal projects. A good vendor pre-loads the deck for success by setting out process, roles, and the minimum involvement needed from stakeholders before they take the engagement. A vendor’s project intake process is far more structured – even where we’re outsourcing and doing 20 large projects for the same client in a quarter. A vendor can’t deviate from working this front-end because we know that eventually, if we don’t scrutinize it closely, we’re risking failure on an engagement.

Vendors have done their homework on the value they bring. We also dedicate about 25% of our corporate resources to ensuring that people understand our value in communications and direct sales cost. Since a decent vendor has done the research, they can prove to management what will happen in time and cost if their process is not followed. For example, I can show someone hard data from live projects on the reductions in requirements change we bring, the timetable improvements we achieve, and how our process brings value to larger, more strategic projects. Because a successful vendor has thought long and hard about what it does, they can be more concise and quantified about the value we intend to bring to a specific situation. We also separate organizational value management (sales role) from value delivery (consulting function) to more deliberately manage client expectations and satisfaction. For the vendor, high satisfaction is only achieved by a specific path, that starts with setting the right expectations on the value we bring, and ends with help people both see and showcase that they were successful in achieving their objectives. The thinking is different: Internal analysts tend to focus on task achievement; good vendors think about value management.

A successful vendor’s delivery team has conviction. Conviction is that deep-seated belief that a process is going to be successful IF an engagement is conducted a certain way. You can have business analyst training until you are blue in the face, but unless there is the absolute belief that the new techniques will be successful, these techniques will not used. Vendors make people document the success stories and show these to the new consultants. At our organization, we make sure that people know that the process has worked over 1,000 times successfully, and we take the cost hit to put our new people on airplanes to observe an engagement done by an experienced team, so that they can success for themselves. We also get them to co-pilot an engagement with a successful user of the methods before we ever let them go solo. All this effort is part of building both competence and conviction. At the end of the day, a vendor can only be successful if every person on the delivery team is able to do the methodology in EXACTLY the same way and get a consistent result. In our world, there really isn’t a second chance – we do exceptionally well, or we get fired. Analysts follow the process a vendor dictates not simply because they understand it, but because they absolutely believe that they will be more successful if they follow it. The path to developing skills is fairly straightforward. The path to getting consistent execution is much more complex and relies on first building conviction.

I like to relate success and momentum in general within organizations to a big, heavy, flywheel. A big success gets the flywheel turning a little. Get a bunch of successes… and the wheel turns a little faster. The flywheel is an analogy for a cycle of positive change where small, incremental steps lead to momentous change. If I go back 10 years, our company tended to do smaller engagements of one or two weeks and we really did not pursue large-scale engagements. Today, it’s the inverse – our teams tend to be engaged on extremely large and complex projects, and the smaller one- or two- week engagements are a smaller proportion of our revenue. Vendors must deliberately manage momentum. With positive momentum, the strategic focus of the organization shifts over time. An organization with no positive momentum offers basically the same value to the organization year-after-year. A vendor can’t simply say “our strategy this year is to do more BA stuff”. In the vendor world, clients can be a bit ruthless, so vendors must either show momentum and continuously strengthen the value proposition, or wane in importance as service providers.

A vendor as specialized as we are (we only do business requirements) lives or dies by how we scope and size an opportunity, and how we determine the optimal process, plan and strategy to recommend for a requirements engagement. We simply cannot miss when doing estimation – ever. In fact, in the last bunch of years, I can’t remember sliding over-budget on an assignment. We have to closely manage the number of client days used on an assignment and commit in a statement of work that we are going to produce “X” deliverable in “Y” days. Most analyst organizations really do not manage client expectations on the number of days required to do requirements. In fact, a mere 25% of organizations we recently surveyed accurately estimated the amount of time needed from the stakeholders. The rest underestimated by an average of 192% (get the results from http://www.iag.biz/). How do you expect to maintain stakeholder involvement over time if the team consistently overruns expectations by almost 200%?

Finally, vendors get access to all the neat toys. It is perhaps one of the bi-products of working with so many clients that you see what is working and what’s not, but more importantly, a vendor has a deliberate R&D focus to continuously look at new methods or technologies and see what makes them tick. It’s neat to get a freebie copy of the latest and greatest from a tools vendor like RavenFlow and fiddle with it on an engagement. Having a substantial R&D budget for BA best practices and technologies development means the vendor is able to get ahead of changes in client demands and talk to them about how, for example, agile methods can be made to work well on very large scale engagements. Having an R&D sandbox in which to play with new technologies and methods may be fun, but candidly, it’s the only way to determine the practical application of these technologies and methods, and help the organization develop the value it brings to clients. In fact, internal business analysts and vendor organizations both have access to the toys, the question is, is there a managed process to turn that access into value?

Are these lessons from the vendors well implemented in internal business analyst organizations? Take a little test:

Do your BAs take enough time negotiating the process of requirements discovery – especially on strategic projects – to ensure success?
How good is your organization at selling your process internally? Do you measure or manage the value delivered to the organization?
Do you have consistently high quality requirements from all BAs? Do your people have conviction that they’ll be successful if they follow your internal process?
Do you have strong momentum? Consistently enhancing value brought to the organization – and an expanding budget/mandate?
Can you accurately forecast (+/-10%) the number of days needed for conducting business analysis and in creating business requirements?
Do you have a practical, managed process for BA process and technology R&D?

If any of the answers are “No”, ask yourself, “why not.” Why not force your BAs to do better elicitation planning, or publish your success stories, or benchmark your team against best of breed performance to showcase their strength? Maybe you already have strong momentum. But, maybe, you’re looking for ways to build that momentum and acting more like an external vendor is the path to help get you there.

Keith Ellis is the Vice President, Marketing at IAG Consulting (http://www.iag.biz/) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the market strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

The Top Nine Requirements Misconceptions: Why Arent YOU Doing Requirements Right?

Written by Ellen Gottesdiener on April 24, 2007. Posted in Articles.

“We don’t need to explore requirements—we know what we need!” “Hey, we’re using agile methods—we don’t need to define requirements!” “Oh, we don’t have time for requirements!” And so it goes. You’ve probably heard—and perhaps yourself offered—any number of excuses or rationales for not doing requirements right. No matter who makes these excuses—technical staff, the business sponsor, the project manager, or even business analysts—failing to carefully define your project’s requirements will put your project in peril. In my twenty years of working with projects, I’ve heard them all. Here are my top nine requirements misconceptions—and how you can refute them.

“We know what we need”

In practice, project team members mostly don’t know what users or customers need. Requirements development takes exploration and learning. It’s unrealistic to expect your team to understand requirements up front.

For one thing, users, product managers, customers, and other stakeholders don’t really know all their needs at the beginning. Requirements naturally thrash and evolve. Indeed, it’s wise to be suspicious of claims to the contrary. Remember, almost half of the requirements you specify never get implemented (Standish Group International, 2003b).

In many projects, the perception that requirements are known is mistaken. Most errors in delivered software (30% to 50%, depending on the study) originate from flawed requirements (Schwaber, 2006; Nelson et al., 1999; Leffingwell and Widrig, 1999; Lauesen and Vinter, 2001).

The top three risks that threaten successful e-projects all relate to requirements— constantly changing requirements, poor requirements specification, and customer involvement issues such as delayed approval, requirements thrashing, and poor communication (Rodrigues, 2001).

Don’t rely solely on product and business managers for defining user needs. Unless they are former users themselves, they will not understand direct user needs without inquiry and exploration. And rarely do product and business managers have the subject matter expertise you need to represent the entire set of requirements.

Ask yourself: have you solicited the voices of all your stakeholders? Do you know who all your stakeholders are? Have you prioritized conflicting needs? Have you explored both technical constraints and possibilities? You may think you know what the needs are, but your list may be shortened by technical realities or lengthened by technology possibilities.

What you think you know can hurt your project more than what you don’t know.

“We’ve got this covered. We’re [pick one: outsourcing/
using agile development methods/ buying a software package]”

Outsourcing, agile development methods, COTS solutions—these are often great ideas, but they don’t eliminate the need to develop excellent requirements. You still need to articulate requirements, adapting your requirements development practices to these scenarios.

The critical need for proper requirements development increases when you outsource your project. You need to communicate requirements with even more rigor when the development staff is not physically co-located with customers and project managers. In addition, you will need top-notch business analysts (Schwaber, 2006).

If you’re adopting agile practices, it doesn’t mean you don’t need requirements. In agile projects, iterations are driven by requirements. They don’t go away—they’re successively elaborated.

And if your product is large and complex, agile projects need to start with a requirements-driven product and release roadmap. From there, the team develops chunks of requirements—based on those roadmaps. Success with agile development means balancing suitable-quality requirements with speedy definition of needs.

Many organizations hope to accelerate delivery by seeking and installing software package solutions (commercial off-the-shelf software, or COTS). In that case, you still need to understand your requirements and the impact your project will have on your business process. Requirements should drive your choice as well as your implementation strategy.

“My staff already knows what good practices are”

Too many projects rely on written requirements, often viewed as the most important good practice. But written requirements are rife with ambiguity (unclear meanings). To top it off, project and product needs are rarely known up front.

In fact, writing textual requirements (“the system shall…”) is not the best way to understand your users’ needs. Textual requirements have their place when you need formal specifications, but most successful projects also adopt other techniques to explore business and user requirements.

Effective requirements development makes use of requirements models that are verified and validated continually and iteratively. Using good practices—such as requirements modeling, facilitated workshops, prototypes, scenario verification, and more—takes practice, coaching, and reinforcement.

Following sound requirements processes, actively involving users, documenting requirements appropriately, validating and verifying requirements, and managing requirements changes—all these skills and techniques are essential to successfully reduce the many risks associated with requirements errors (Leishman and Cook, 2002).

“We can’t afford to get training or consulting”

Roughly one-third of your software project budget is consumed fixing requirements errors. That means you’re spending about $150,000 of your $500,000 project fixing defects or errors that originate from your requirements (Schwaber, 2006; Nelson et Al., 1999; Leffingwell and Widrig, 1999; Weinberg, 1997).

The earlier you discover these errors—missing, wrong, conflicting, and ambiguous requirements—the cheaper it is to fix them. Finding and fixing a requirements error during the requirements phase might cost you $25 to $100. If you don’t find it until the construction or testing phase, fixing that same error is going to cost you $500 to $1000 (20 to 40 times more). Left undetected, that requirements error will cost you as much as 300 to 1,000 times more. That $25 cost becomes $10,000! (Reifer, 2007)

For every dollar you invest in your staff learning good requirements practices that incorporate customer collaboration, you can get a 10:1 return on investment (Jones, 1996a).

You cannot afford not to correct your requirements deficiencies.

Pay now—or pay more, later!

“It will take too much time to do things differently, to take time out for training, or get project help from the outside”

Yes, there will be a learning curve. This is a normal part of change and learning. But there are things you can do to accelerate the process. Schedule formal training to coincide as closely as possible with the project work. Provide real-time coaching to the team. Set up sponsorship contracts so that new practices and behaviors are reinforced in the organization—both top-down and bottom-up. Find out from your staff what they need from you to be successful with requirements, and provide it.

And remember, some requirements work is better than none. On complex projects, one study showed that investing even 10% in the effort before freezing requirements reduces cost overruns significantly (NASA Comptroller Office, reported in Hooks and Farry, 2001).

Many organizations are turning to external service providers, outsourcing their development efforts. And they are learning that highly skilled business analysts who can develop and manage requirements are essential to successful outsourcing (Henschen et al., 2007; Light, 2005).

“Users don’t know what they want”

Users are not supposed to know what they want. Understanding user needs is both an art and a science—a combination of discovery, interrogation, exploration, and decision making.

Involving users in requirements development is widely recognized as one of the—if not THE—most important factor for project success. Yet business people, as well as IT people, continue to complain about their inability to work effectively together to define the right requirements.

Healthy collaboration with users is crucial—and it doesn’t just happen. Both sides of the relationship—business and IT—are accountable to co-develop the right requirements in the most efficient and effective manner possible.

That’s why great analysts employ an appropriate combination of requirements elicitation techniques. It’s one of their most valued skills. These elicitation skills, married with artful choices in requirements models, go a long way toward active and productive user involvement.

Sponsors who pay for the development (product managers, marketing managers, or internal business managers) also need to be engaged. This doesn’t take unlimited time and money. Not all requirements are created equal. User priorities need to be evaluated continually if the team is to make smart product development choices.

“Customers are too busy to participate in requirements work with us”

IT needs to employ techniques that make good use of business people’s time and actively engage them in requirements work. At the same time, business people need to fully participate in defining their requirements. If you do it right, good practices for effective user involvement sell themselves.

Here are some ways to do it right. Represent user needs in ways that “sing” to users and customers. Use a variety of elicitation techniques. Verify and validate requirements as you proceed. And, importantly, conduct continual requirements retrospectives to get feedback that will allow you to adapt your requirements practices.

“Our users are distributed. We can’t get everyone’s requirements”

User requirements are the focal point of your product. When users are scattered, you still need to identify the various types of users, understand their needs, and determine how you might need to alter requirements based on location.

When your users are geographically distributed or there are vast numbers of them, you may have to rely on surrogate users or subject matter experts who can research user needs. Find a small sample of representative users from various locations who are important to product success. Then adapt your elicitation practices to make efficient use of these users in requirements development and verification.

For some products, it’s best to combine surveys and other research methods with deeper representative user involvement.

Regardless of the approach you take, ignoring user needs is a recipe for disaster.

“We got the book We’ll just follow that”

Reading a book (e.g. The Software Requirements Memory Jogger) helps. It gives you awareness and knowledge. Reading does not, however, enable you to apply skills without practice and reinforcement.

Many business and requirements analysts are not trained and skilled in the toolkit of requirements development and management practices they need to be successful (Schwaber, 2006).

Analysts with extensive experience are more successful than novices in analyzing and uncovering user needs. Expert analysts demonstrate the ability to select among elicitation techniques based on the situation and integrate multiple models to represent requirements (Hickey and Davis, 2003).

Gaining expertise in requirements saves time and effort, reducing your total cost of application ownership (Light, 2005).

Training and coaching accelerate the learning curve and will earn you savings in time and money.

Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps you get the right requirements so your projects start smart and deliver the right product at the right time. Her book Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Ellen’s most recent book, The Software Requirements Memory Jogger describes essentials for requirements development and management. In addition to providing training and consulting services, Ellen speaks at and advises for industry conferences, writes articles, and serves on the Expert Review Board of the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge™ (BABOK™). You can subscribe to EBG Consulting’s free monthly eNewsletter Success with Requirements (http://www.ebgconsulting.com/newsletter.php) for practical guidance and requirements-related news. When you sign up, you’ll receive a free .pdf article by our Senior Associate, Mary Gorman, on an essential requirements modeling technique.

References
Henschen, Doug, David Stodder, Penny Crosman, Michael Mcclellan, Neal Mcwhorter, and David Patterson. 2007. “Seven Trends for 2007.” Intelligent Enterprise, January. See http://www.intelligententerprise.com/showArticle.jhtml?articleID=196603897

Hickey, Ann M., and Alan M. Davis. 2003. “Elicitation Technique Selection: How Do Experts Do It?” Proceedings 11th International IEEE Requirements Engineering Conference. September.

Hooks, Ivy F., and Kristin A. Farry. 2001. Customer-Centered Products: Creating Successful Products through Requirements Management. Amacom.

Jones, Capers. 1996a. Patterns of Software Systems Failure and Success. Thomson Computer Press.

Lauesen, Soren, and Otto Vinter. 2001. “Preventing Requirement Defects: An Experiment and Process Improvement.” Requirements Engineering, June 6:37-60.

Leffingwell, Dean. 2003. “Calculating the Return on Investment from More Effective Requirements Management.” IBM Developer Works, December.

Leishman, Theron R., and David Cook. 2002. “Requirements Risk Can Drown Software Projects.” Crosstalk: The Journal of Defense Software Engineering, April.

Light, Matt. 2005. “Agile Requirements Definition and Management Will Benefit Applications Development.” Gartner RAS Core Research Note G00126310, Gartner, April 18.

Nelson, Mike, James Clark, and Martha Ann Spurlock. 1999. “Curing the Software Requirements and Cost Estimating Blues.” The Defense Acquisition University Program Manager Magazine, November–December.

Reifer, Donald J. 2007. “Profiles of Level 5 CMMI Organizations.” Crosstalk: The Journal of Defense Software Engineering, January.

Rodrigues, Alexandre G. 2001. “Project Goals, Business Performance, and Risk.” Cutter Consortium e-Project Management Advisory Service Executive Update, 2(7).

Schwaber, Carey. 2006. “The Root of the Problem: Poor Requirements.” IT View Research Document, Forrester Research, September.

Standish Group International, Inc. 2003b. Standish Group Study. Reported by Jim Johnson, chairman, XP 2002 Conference.

Weinberg, Gerald M. 1997. Quality Software Management, Volume 4: Anticipating Change. Dorset House.

04/23/07