Smooth stakeholder participation is integral to the success of any project. Sometimes stakeholders hold information that is essential to thorough requirements discovery, so it is important that they be forthcoming. Other stakeholders must sign off on requirements as being final in order for a project to move forward, so it is important that they be decisive and willing to let go the discovery stage of a project.

 This article considers the unique complexities of large, long-duration, high-cost projects that pose challenges to project success, and offers both old and new management strategies to handle the complexities... The complexities of large projects require that particular attention be directed to planning the project, developing and delivering the solution, selecting team members, and sustaining a high-performing team over the long haul.

Although you can do ‘standard’ requirements gathering for Service Oriented Architecture (SOA) projects, there is now an evolving a set of analysis techniques, methods and approaches that purport to be better suited to information gathering and design specification. I will call these generically Service Oriented Analysis.

Through development and beyond we hope not to have show stoppers, anticipate builds and releases on time, expect teams to portray efficiency, want our customers to be happy, and hope that boss coming to work and singing melody. Sounds like a perfect five-course scrum, isn’t it?

Today the term Business Analyst is synonymous with a career in the IT industry but the most successful and valuable analysts are those who understand the 'business' rather than those who understand IT. So what exactly is a Business Analyst? What is the Business Analyst’s role? What is the best background for this job? What skill set is required? What type of person is the best fit? What training is required and available?

If you ask Business Analysts what they think about ‘Agile’, you’re likely to get a mixed bag of answers... With so many different ideas on what Agile is and how Agile impacts the Business Analysis profession, we decided to talk with leading experts in the Agile field and get their opinions on the subject.

For business analysts, understanding decision logic from the perspective of business people is key. For that you need business rules. But when can a rule be considered a business rule, and when not? This article presents five pragmatic tests for knowing when you have identified a true business rule.

Business Analysts are required to contribute to a project in a number of ways: primarily by identifying the needs of the target community; building the Communications Plan; defining use case models; and Business Requirements document. In order to do their job effectively a large element of a BA’s time must be spent understanding and managing stakeholders in the project... From a CIO’s viewpoint the skills they look for in a good Business Analyst include an aspect of stakeholder management and an ability to find a path through the likely problem zones.

Last time, we proposed that, with business rules, we surely can. The traditional way we manage business rules is time-consuming. It focuses on details rather than the bigger picture. The details are the business rules themselves - expressed, analyzed, approved, and stored in a safe place. But, viewed as details, they lose momentum, postponed until design or implementation. Perhaps we deliver too much too early. But, we can do it differently by delivering less up front and evolving it into something more important.

Managers who supervise business analysts, particularly in large companies, frequently struggle with creating a competency model for BAs. What are the key elements to consider? How to structure the various BA levels and titles? How to make sure that the competency model truly reflects business needs? Even if it requires a certain level of effort to be developed, a competency model offers a number of benefit to organizations...