Entries for November 2012

8952 Views
5 Likes
0 Comments

Adaptability is a word that is not used enough in the context of business analysis and collecting requirements. Though it is used in the project world, “adaptability” is more synonymous with project methodology or project teams as a whole than it is with requirements elicitation or requirements management. Being adaptive to your surroundings is what can save you from the perils of uncertain environments, non-engaged subject matter experts or the dreaded “analysis paralysis” effect.

18261 Views
3 Likes
0 Comments

If a business analyst is to step up to the task of becoming a credible project team leader, she must have an understanding of how teams work and the dynamics of team development. Team leaders cultivate specialized skills that are used to build and maintain high-performing teams and spur creativity and innovation. Traditional managers and technical leads cannot necessarily become effective team leaders without the appropriate mindset, training, and coaching.

10631 Views
9 Likes
0 Comments

There is a direct link between business rules and business events – one not fully understood by many Business Analysts. What is that link and why is it so important? This discussion raises a very big question about how your current requirements approach addresses business rules. Can you answer that question confidently? Here is what every Business Analyst should know about business rules and business events.

16403 Views
9 Likes
6 Comments

A great approach under the right circumstances, agile is not a universal solution for successfully completing a software project. Some projects are simply not compatible with most agile practices. For such projects, NANW has been driving results in terms of project and rework costs, integration time, and improved quality as reported by customers.

9711 Views
5 Likes
1 Comments

The language of systems is no different; No, it is not C++, Java, COBOL, etc., but rather simple English (or whatever your native language happens to be). In the past I have gone into length about the differences between Systems and Software, the two are simply not synonymous. Whereas systems include business processes implemented by human beings, computers and other office equipment, software is simply instructions for the computer to follow. Systems are for people who must also take an active role in its execution. In fact, systems will fail more for the lack of people procedures than they will for well-written computer software.

10729 Views
4 Likes
0 Comments

As trusted advisors, business analysts must never forget the value of collaborating with stakeholders at all levels of an organization. The world of Agile has demonstrated this very point and is doing so with great positive impact and effect on the bottom line of many projects. When initiatives and projects are not collaborative, there is always a failing point within the stakeholder community.

47897 Views
63 Likes
3 Comments

Most of the projects inevitably struggle at some point or the other if the scope is not defined properly. The right note to start a project is to have a clear Project and Solution/Product scope at hand. It is very critical for a Business Analyst to clearly understand and define the Solution Scope in black and white before even going into the Requirement Elicitation phase. This article focuses primarily on key aspects of understanding and defining Solution Scope in traditional methodologies.  

 



 




Copyright 2006-2021 by Modern Analyst Media LLC