Entries for 'adrian'

Extreme Inspections are a low-cost, high-improvement way to assure specification quality, effectively teach good specification practice, and make informed decisions about the requirements specification process and its output, in any project. The method is not restricted to be used on requirements analysis related material; this article however is limited to requirements specification. It gives firsthand experience and hard data to support the above claim. Using an industry case study I conducted with one of my clients I will give information about the Extreme Inspection method - sufficient to understand what it is and why its use is almost mandatory, but not how to do it. I will also give evidence of its strengths and limitations, as well as recommendations for its use and other applications.

Does the business perceive business rules as a true organizational asset? Are they visible, valuable, and universally accepted as data is? Above all, does business rule management attract and sustain enterprise-wide high-level management attention?

Complex Project Management (CPM) is the “next new thing” in our quest to achieve stronger project performance. Successful projects not only deliver on time, on budget, and with the full scope of features and functions. In addition, they deliver the expected benefits in terms of contributions to the bottom line of businesses. And projects today are complex, very complex. Our conventional project management tools and techniques alone are not adequate to successfully manage highly complex projects.

If you've ever been a manager or above in a corporation, you've probably been exposed to the concept of Succession Planning. The basic idea is that all managers should have some idea of who is willing and able to step into your shoes once you are promoted into a new position or change your career focus... It is something that I think is often overlooked within our profession as BAs do not generally manage people, projects or teams. However, we do manage requirements, which like people, projects and teams, generally do not go away just because we move on in our careers. Succession planning is just as important for BAs as it is for managers.
 

Widely-accepted conventional requirements models continue to create creep—changes to settled requirements which are a major cause of project overruns. Business Analysts and others will continue to encounter such creep so long as they follow flawed models focusing on requirements of a product or system being created without adequately also discovering the REAL, business requirements the product must satisfy to provide value.

The goal of rulebook management is to give business workers and business analysts the ability to access and manage decision logic directly. The focus is on the kinds of challenges these business workers and analysts face on a day-in and day-out basis.

Some people use them. Some people don't use them. Some people create them using sophisticated tools. Some use basic drawing programs. As part of the Unified Modeling Language, Use Case diagrams are often the starting point for many software projects. However, questions about Use Case diagrams still linger in the minds of many Business Analysts...

Every project in which we have implemented the Decision Model has seemed to bring further proof that – in the world of business logic or business rules, it seems to create a frictionless environment. We see “Ah ha!” moments time and again when people realize the simplicity to which their complex logic or business rules may be reduced by applying the model.

We are often asked what you need to do to run a successful SOA Pilot. Based on our experience of dozens of pilots, I propose that the following characteristics are essential to success.

It is no secret that our record of complex project performance is rife with failed and significantly challenged projects. This is true for virtually all types of projects. Examples abound – we offer just a few.

With business analysis projects, as with all endeavors, you have to know where you are going before you can chart your course to get there. In other words, before you can decide whether to take a train, bus, or plane, what time of day you will travel, and what you will carry, you have to decide where you are going.

So it is with requirements. Before you can chart how you are going to implement a solution, everyone involved in the development effort must agree on why you need it to start with and that it is the very best solution available. Business requirements are fundamental to any development effort because they define where you are going by articulating the business problem and its solution—why it is needed and how to measure its success.

I'm hearing the word "value" a lot lately. This is partly because the economic downturn has us looking to get the most for our money. But that's not all. More and more managers, business analysts, programmers and testers are talking to me about value. They are concerned that their products provide value for their end users. Many of them express a kind of process or tool fatigue. They are tired of being told that using a particular process or toolset is the key to their success. To them, value is a more important concept.

In a previous column, we looked at how Decision Models improved an actual project. Below, we explore why the Decision Model is the next logical (and simple) advance in process modeling and business rules. We do so by addressing five questions. How does the Decision Model improve a business process model? Where did the business rules go? Why did the business process model become simpler? How does the Decision Model transform a business? Finally, why should business analysts upgrade from a traditional business rules approach to Decision Modeling?

The Business Analysis Body of Knowledge (BABOK® 2.0) is the definitive guide to the profession of business analysis. Every business analyst can profit from it, and few analysts can afford to be without it.

Business rules should be externalized from processes and established as a separate resource. Rule Independence permits direct management of the business rules, so they can evolve at their own natural pace rather than that of the software release cycle. Other benefits include better process models, and much closer tie-in to the business side (a.k.a. business alignment). Business rules put your company on the road to true agility.