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 deliver the data.

Read the rest of this post »

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.

Read the rest of this post »

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

Read the rest of this post »

Read the rest of this post »

Read the rest of this post »

The Challenge

User stories that should be simple are frequently quite complex, written ambiguously, or have underlying needs that are hidden below the surface.  Some should be broken up in to multiple stories.  You may not know how best to write a user story and communicate needs.  Many developers are not trained in the techniques needed to break through in this challenging environment and quickly get a clearer understanding of user needs.

Break Through Thinking

Make this break through:  it’s not the designs you bring, or the solutions you suggest, that will clarify needs - it’s the questions you ask that determine how quickly a solution can be implemented.  Good questions showcase your understanding and build trust between you and the user.  Here are a few situations where a few great questions will help you deal with difficult user stories and difficult times:

Determining the success criteria

Here is a simple approach to clarifying use cases: attach your clarifications as test conditions.  The user story could be all about the user interface. The success condition in the mind of the user could be very different “A user can buy our product.”  By focusing on the outcome not only is the capability needed clearer, but you also now have a clear understanding of what to focus on with users during sessions.

Read the rest of this post »

Four simple tests to assess if requirements are not done

These are Business Requirements level tests that work and will improve your requirements quality irrespective of delivery methodology:

If the requirements lack context: Requirements always exist to support "what" the business wants to do, not "how" it wants to do it. The "what" part of this is the context of business process. Lack of understanding of what business processes are impacted by requirements means someone has no idea of how requirements impact each other, the impact of removing requirements, or the ability to assure that the requirements collectively are complete or will meet a specific business objective. The way a company applies context in its documentation also creates the structure of the documentation.

If the interdependency is not evident: How do you look for proof that interdependency is documented? Look for a section in the material called "dependencies", check the "issues list", and look for an analysis technique called a context diagram (every line on a context diagram is an interdependency). Why is interdependency so important? There are two aspects to scope: internal to the system (e.g., its functionality, the workflow and information flow, etc), and external to the system (e.g., how this system needs to interact with other systems, how the workflow being automated hands off across other departmental units). In the absence of knowing the interdependencies, you only ever know part of the story on scope, so it becomes probable that you will encounter significant scope shift on any system of any degree of complexity.

Unclear business objectives: Objectives must be Specific, Measurable, Achievable, Results-oriented, and Time-bounded (easy to remember as 'SMART'). The absence of objectives eliminates the ability to assess solution tradeoffs, makes difficult the prioritization of functionality, and other problems. You can test if a particular function meets needs with user acceptance tests. You cannot test if the collective system meets needs unless you have clear objectives.

 

Read the rest of this post »

The concept of capability maturity has been around since Deming first started the quality movement in the 1950s. So what's a "mature" business analyst? Are we really looking for grey hair and wrinkles to determine that individuals or collective organizations are consistently going to perform at a high level of quality? Is there some measure of "prune-i-ness" that you can use to pick out top performers?

I think not.

Overall, if an organization wants to change the performance level of its business analysis function, it has to focus on six underlying capabilities: processes, practices, people, technology, organization and deliverables. Sure, you can get a short term bump in productivity by being draconian, but it is simply not possible to make material, sustained change without systematically addressing these six capability areas. The question in each of the six areas is not whether you have, for example, processes or not. The question is the degree to which an organization accepts and adopts that process as the best possible way of doing things. This means that some organizations think they have a process for requirements definition and management ... but admit it's actually quite ad hoc. At the other end of the spectrum, organizations have institutionalized the process, and can describe their efforts to continuously optimize this process so that it's alignment to delivering stakeholder value is maximized. These two examples are the extremes of requirements definition and management maturity.

Read the rest of this post »

 

There are four situations where companies should strongly consider and investigate outsourcing the Requirements Center of Excellence (RCoE):

 

1.       Growing very rapidly:  Where a company is growing very quickly, increases in productivity translate into direct cost savings.  Any improvement made in application time-to-market is critical to the organization.  High growth companies can leverage the outsourcer to bring mature processes that simply could not be contemplated given the stress on the internal organization for growth.

Read the rest of this post »

You have to admit - agile folks are conflicted. On one hand there's the folks screaming requirements are dead***. On the other hand, people teaching agile practices have to explain the asterisks; mention these things called user stories and the practices of getting good user stories (like making each user story testable and how to deal with non-functional requirements). Then there are the folks rolling out these practices and using them in real life on complex engagements. We're facing the issues of sequencing and redundancy of stories, figuring out which ones accidentally change the architecture of the system (oops!), which ones were really a whole book rather than just a story, etc. and how to actually get to the promised land of higher productivity. No wonder you get questions from developers like, "can I write down this non-functional requirement?" Agile is still a storm of mixed messages - and like the Internet bubble of the late 90s hype might do more harm than good to the movement over time.

 

Read the rest of this post »