Entries for 'Transform VA'

What role should business rules play in procedural languages and enterprise architecture? How do they relate to platform independence and compliance? What about knowledge retention? This column, the last in a series of three, explains the deep insights offered by the Business Rules Manifesto on these questions. Already read it? You may be surprised by what you find here!

This year’s top 10 business analysis trends focus on leveraging the power of requirements at all levels through Agile and business architecture to deliver business value to the organization. We also expect to see business analysts being utilized in more robust ways, forcing them to take on new skills to meet a broader job scope.

Business Process Model and Notation (BPMN) is already acknowledged as a de facto standard for business process modeling. However, it still takes a long journey to increase the maturity of business process modeling practice. In practice most business analysts do a lot of mistakes that make their BPMN models over complex, difficult to understand and maintain.

This means that The Decision Model is at the center of a serious shift in the way we perceive and manage the business rule and logic dimension. So, this month’s column highlights the shift, starting with 2009 and ending with 2012. At its core are the seven observations indicating that a shift is happening. More important, each observation contains corresponding article links to related Modern Analyst articles.

In my view, the most powerful quality practice available to the software industry today is inspection of requirements documentation. A peer review is an activity in which someone other than the author of a work product examines that product to find defects and improvement opportunities.

If I had to choose—not that I want to make such a choice—but if I had to choose, I’d take a scribe over a facilitator. I can almost hear a chorus of “You gotta be kidding!” No, I’m quite serious. How many meetings and workshops have we all attended where there was a weak facilitator or none at all?

There are capabilities necessary to implement Smart Systems, where business people manage business logic in a business-like and agile fashion, with highest integrity, and deployable to any and many targets. These are the requirements satisfied by a BDMS, not by a BRMS 

Whether linear or agile development approaches are being used, the Business Analyst needs to have a specific required point in time where the solution being implemented is checked against the original problem before it gets too far downstream.

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.

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.

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.

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.

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.

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.  

In this article, I’ll show you how you can apply three specific business analysis elicitation or requirements gathering techniques as part of facilitating all or part of a meeting even if you aren’t in a business analysis role.