IAG Consulting

The Requirements Maturity Model Explained

The Requirements Maturity Model (RMM) is a means to benchmark an organization’s effectiveness in requirements definition and management by looking at maturity in six underlying capabilities. Like similar standards-based models, it classifies companies based on observed, tangible competency in each capability to make an objective assessment of overall maturity.

How is the Requirements Maturity Model Structured?

IAG’s Requirements Maturity Model has two dimensions:

Maturity Level: IAG’s is a staged maturity model similar to those used by several industry standards bodies. An organization progresses up the ladder (to the right) as goals are achieved and thresholds surpassed. Each level of maturity shifts the emphasis to different requirement practice characteristics. Each level builds a foundation for succeeding levels.

Capability Area: Six capability areas are assessed and combined to determine the maturity level of a organization’s requirements management practice. These six are the fundamental building blocks for requirements definition and management and include:

• Process: Definition, usage, and management of requirement procedures.
• Practices & Techniques: Definition of how analysts will perform work, the efficiency and effectiveness of these activities.
• Technology: Provision, usage, and integration of software tools in the context of the requirements practice.
• Staff Competency: Level of knowledge, skills, and ability of the workforce.
• Deliverables: Definition, production, and usage of work products as output from the requirement process.
• Organization: Organizational model and services delivered to stakeholders, the provision of resources and resource management in the delivery of these services, and the framework of process and tool governance.

Read More

(Source: iag.biz)

BI Requirements: Success Enablers

A BI Project can only be successful if it actually gets built and if the Clients utilize it. Data Warehouse best practices indicate that there are some enablers toward making a BI implementation successful

Have Strong Executive Management Support

With executive sponsorship and involvement all challenges can be overcome; without it the project may be doomed from the start.

Ensure there is a justifiable business value to a the data requirements

Simply put, include data in the data warehouse that can result in measurable dollar benefits to the business itself. Data with no or little anticipated benefit should not be included “just because we can”. A Business Intelligence system can be an incredibly powerful management tool, or it can be a complicated, confusing and cumbersome monster that doesn’t get used or becomes unreliable.

Have strong client buy-in / participation throughout the Project’s Life Cycle

When business users actually provide the business requirements for the BI system they develop a stronger sense of ownership. Having an understanding of the design and content results in a significant improvement in overall adoption and utilization rates of systems developed with direct user involvement.

Hold formally facilitated Requirements Discovery Sessions

Requirements Discovery Sessions facilitated by appropriately skilled analysts create an environment of open discussion that facilitates consensus for critical information requirements from the selected group of business knowledge experts.

Derive the Data Requirements from Business Usage Scenarios    

The facts and measures (and related dimensions) to be included in the Business Intelligence System should be based on how the data is to be used (not merely by what data is available). This means driving out the type of management analysis needed to meet the area’s objectives and defining the measures required.

Adopt and Maintain an Evolutionary Philosophy toward the Data Warehouse    

Apply the 80/20 rule. Clients will perceive benefit from a timely implementation of 80% of their total requirements. “Get it in… and Grow On”. Get real-world usable Business Information into the hands of the Sponsoring Management as soon as possible so that they receive and perceive real benefits for their development dollars.

(Source: iag.biz)

SCRUM: Playing Planning Poker

In order for the Team to provide a Commitment they need some way of estimating the work effort of the Product Backlog Items. To help teams determine their commitment level Scrum employs a rather unique way of estimating through a technique known as ‘Planning Poker’. Basically it works like this:

1. Each Team member (except the Product Owner) is given a deck of Planning Poker cards (that carry a value of between 0 and 200).

2. The team reviews each product backlog item and decides which is the smallest / least complicated item and assigns it a value (e.g. 2-points). It really doesn’t matter what units you use (it could be popsicle sticks for all that matters) as the estimates are all relative to each other.

3. Then, starting from the top the Team selects the first item from the product backlog

4. Each team members selects a card that they feel represents the effort that will be sufficient (on average) to complete the item to the Team’s definition of done by comparing it relative to the 2-pointer.

5. Once everyone has estimated, they each turn their cards face up. The person who estimated the highest is asked to explain their reasoning. The same for the lowest. The Product Owner, while not participating in the estimation exercise is available to provide clarity, examples, explanations, and elaborations of the item being estimated.

6. This estimation process is repeated until a consensus is reached for each item as the team goes further down the list. The estimation process is time-boxed (usually 1-hour).7.

At the end the points (or popsicle sticks) are added up and allocated based on the length of sprint (e.g. 2-weeks) and by the average number of hours per day a person can devote to the sprint (e.g. 4-6 hours accounting for email, meetings, breaks). This becomes the sprint goal. The Product Owner is invited but only in the capacity of clarifying, explaining, and expanding the Product Backlog item (User Story) to assist in the estimation effort and not to provide comment on the estimates being made. The Planning Poker exercise is usually facilitated by the ScrumMaster

(Source: iag.biz)

Specifying Report Requirements

Good reports deliver business value. They give decision makers the information they need to take fast, effective action and save time, effort and money. There are three attributes to defining effective reports: Action, Stakeholder, Information:

Action:

A decision or task used to manage or operate the business. A Stakeholder takes Action using Information. Actions are measurable, no matter what they are called (“objectives”, “goals”, etc.). “Be informed” is not measurable. “Describe [situation] to executives” and “Satisfy regulators” are.

Stakeholder:

Someone, often a manager, who will take Action based on Information. Reports are created because the Stakeholder needs to make a decision or understand a problem. If you could automate the action it’s usually part of a process, not a report.

Information:

Data, aggregated and presented in a way that answers a question. Describe only the necessary data and formulae, the way the data should be structured into groups or summaries, and the best way to deliverthe data.

When Eliciting High Level Reporting Requirements Ask, in the following order:

1. “In the context of this project, what decision or task is important to running your business?” OR “What business questions do you need answered?”

2. “Which Stakeholder takes that Action?” OR “Who needs the answer to this question?”

3. “What Information does this Stakeholder need to know how to Act?” OR “What information do you need to know to answer that question?”

4. How is the information viewed?” (This is the dimension – by week, by branch, by department, etc.) Focus on the essential Information needed to guide the Action. It’s easy to start enumerating data elements andscreen layouts when you’re looking for “web-based” “email” or “loudspeaker” (based on the Action and the Stakeholder).

When Defining High Level Reporting Requirements:

Fill in the attributes, starting with the most important reports, for example, reports with Actions that are critical decisions, or that have many Stakeholders using the same Information to support different Actions.

When Documenting Detailed Reporting Requirements:

Describe the Information, Stakeholders and Actions in enough detail for a report designer to start building mock-ups. At this stage you’ll define delivery schedules and data sources and page layouts. Your last step is the traditional starting point for defining reports.

Read more at www.iag.biz