Article Sponsored By

by Derrick Brown and Jan Kusiak

When this paper was first published in 2003, business analysis was just starting to emerge as a distinct profession in its own right. Prior to this the role was often performed by the systems analyst who would carry out both the analysis and the design on a new system or enhancement. This often meant that a “problem” was made to fit the “solution”. The transition from telling the client what they would be getting - versus analysing their problems and recommending solutions – was still a new one for many organisations.

Article Sponsored By

by Barbara Davis

Software industry stats clearly show there is an urgent need for dramatic and immediate improvement to the way we develop our products.

Only 16.1% of software and technical projects are successful, and that of the successful 16.1%, only 20% of the implemented features are used all the time and 40% are never used at all! That means that only
1.24% of all proposed features are actually implemented and used! Further, 2.48% of all proposed features are implemented and never used!

The single-most common reason for these alarming statistics is requirements. A lack of practice formalization and holistic view of the causes and effects of failure, have led to the shotgun approach to

Article Sponsored By

by Ellen Gottesdiener

As an agile analyst, you know how easy it is to get lost in a blizzard of project details. The way to keep focused is to remind yourself of the chief reason for using agile processes: to deliver business value for your organization. With that in mind, we’ll look at specific ways you can combine two approaches: agile and lean.