It takes courage to scribe well. In many organizations we encounter pushback related to scribing. We hear lots of reasons why not to scribe. Remarks like those below can discourage us unless we have the courage to educate project and resource managers on why scribes are needed and influence them to assign this important role.

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.

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.

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.