Tag Archives: requirements

New Report Finds Global IT Waste Due to Poor Requirements similar to IAG BA Benchmark

Maveric Systems, a Chennai based software testing company recently released a report on requirements definition and management based on a study of tier-1 and tier-2 banks in the UK, Benelux, Nordics, Middle East & Africa, and Asia Pacific.

One of their major findings was that  35% of the IT budget is wasted due to rework caused by poor definition and management of business requirements from IT.  Interestingly, IAG, in its 2009 BA benchmark report found almost identical results in North America: that 33% of money spent on IT development is wasted.

In a press release for this study, Surya Vangara, Senior Vice President – Financial Services Business, Maveric Systems said, “Today, less than 10% of the total time is spent on gathering requirements. Instead, doubling this time to say 20% will save up to 35% of the budget that is wasted due to rework caused by poor definition and management of requirements.”

Some other key findings from this latest study:

  1. Only 50-60% of Business and IT Heads are satisfied with their organizations’ requirement management practices
  2. Due to poor requirements definition, development time goes up by 25% in transformation projects, and by 19-29% in BAU (Business-As-Usual) engagements
  3. 23% of the projects are either deferred or not implemented due to poor definition of requirements
  4. A 12% increase in the IT budget is needed to fix these defects originating in the requirements definition and add 10% to cost base
  5. These banks spend 5% of their overall IT budget on requirements assurance

We, will be publishing some new study results on the state of business analysis and RDM  in the North American marketplace in the upcoming months. It will be interesting to compare with this very thought-provoking study from Maveric and NelsonHall.

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

Four Trips to Midnight

Midnight is a dark time, like a looming deadline which you’re pretty sure you can’t meet. No one is ever sure exactly how they got into the position of running up against midnight, but it usually means long hours late at night – and lots of caffeine. Perhaps it also includes a dose of wistful thinking and wondering about the project plan that seems to be growing like David Banner in a snit. Sometimes it happens, the work load just got misjudged, or the magic of juggling priorities and fate landed a few choice lemons in your lap. Maybe it’s a different problem altogether.

I’ve noticed lots of analysts have trouble with estimating the amount of time it will take to complete business analysis and the elicitation and documentation of requirements for a project. I remember evaluating a team where the most forgiving management stakeholder I interviewed stated they were currently at 300% of the expected time needed to get requirements – and that was just her personal time… not elapsed time (which was months over schedule). Estimating analyst effort is tough because business analysis is inherently about taking a concept that is airy-fairy-fluffy, and turning it into something that is concrete-with-dimension. Here are some ideas to think about late at night – hopefully some of these will prevent you from burning the midnight oil on your next project.

Continue reading

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.


Continue reading

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.

Continue reading

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

Continue reading

Determine when you are “done”

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.

  Continue reading

What Is Requirements Discovery?

Requirements discovery is also often referred to as requirements elicitation, requirements gathering, requirements analysis, and requirements definition. We prefer to use the term because it’s a little less high-brow, more meaningful, and more appropriate to the activity it is intended to describe.

The Requirements Discovery Process

Requirements Process FlowThe typical process for requirements discovery involves the following six activities:

> Requirements Planning 
> Requirements Elicitation 
> Requirements Analysis & Documentation 
> Requirements Verification & Review 
> Requirements Validation & Acceptance 
> Requirements Change Management

Origin of the Term Requirements Discovery

Legal DiscoveryThe term was initial coined by Ross Little in the late 80’s. Ross, now a principal with IAG Consulting, adapted the term from the legal profession. As a practicing Business Analyst, Little was working to evolve methods, practices and standards from the worlds of structured systems analysis, software engineering, total quality management and business process reengineering. Little credits his father, a lawyer, introducing him to the legal discovery process – and the genesis of the idea to apply some of those concepts to how organizations should gather information to define requirements for business solutions and change.

In the legal community “discovery” is the approach used to determine the facts about a case. Legal discovery mechanisms may be traced back to procedures of the ecclesiastical courts in England as early as the 16th century in which litigants delivered pleadings and obtained answers by means of examination under oath. As legal discovery in American law is the pretrial phase of a lawsuit, requirements discovery is the pre-design phase of a business transformation, or application development project.

What Every Executive Needs to Know About Hiring Business Analysts

The ability to hire great people is one of those skills that differentiate hugely productive managers from the mediocre. When dealing with a specific project, it gets even tougher with the number of distractions, time sensitivities and need to fill head-count numbers on a project plan. It’s very easy to get sucked into short term thinking, and sometimes HR management practices get short-sighted as well. No, the probationary period of a new hire is not a generic safety net.

Here’s some fast thinking you can do in under 30 minutes to help you hire better:

Get away from hiring generalists

Rather than trying to hire people that are generally great at all things, focus on the areas of greatest value to the organization. Take a few minutes to jot down the services this person is going to offer the organization. Figure out where in the project cycle and which requirements definition and management processes will really impact your organization’s performance. Be brutal in your focus to get it down to one or two areas where this person needs to shine.

By getting ‘service focused’ (verb/noun pairs like ‘Facilitate Requirements Meetings’) you’re being blunt about the competency that is essential for success on the project.

List the Skills Needed

Most companies have defined templates used in their requirements definition and management approach. How many hiring managers look at that document and simply extract use cases, cross-functional swim lane diagram, etc from the template to get a list of techniques the analyst would need to know to be successful. How many people look at the services and say, what techniques would need to be known here to be successful? If you’re looking for requirements definition capability and “Facilitate Requirements Meetings” then you probably want someone who knows the techniques for facilitating a cross functional team.

Want a good technique for listing soft skills? Just list the things that annoy you as a manager.

Test Required Skills

I’m a huge believer in testing skills, before the interview and after the interview. It reduces your reliance on your first impression. It is way too easy to get caught up in thinking the first 30 seconds is the make/break part of hiring. I always end up reminding myself, I’m not hiring a politician. Put more weight on getting the person to do a pre-interview task, get them to do a post interview task and look at the judgment, work quality, and skills used in doing those tasks. Give a documentation focused person a requirements document and say, is it done? Have a facilitator run a simulated facilitation session. Nothing elaborate, just focused on the skills that are essential to success. You could even look to outside organizations that do skills testing (Inquestra, etc) if you’re not feeling particularly creative or need to hire dozens of people and don’t have time to administer the tests.

Get Away from Trying to Hire Industry Experts; Focus on Analyst Skill

Here’s a basic rule of thumb: your line of business managers are the subject experts that know the business. Analysts, need to know analysis. If the analysts are competent, they will function really well, regardless of the industry or position. Granted, if you want a systems analyst for SAP, you need to focus here a little more, but definitely not for business analysts. Let’s face it, the pool of candidates can get really small, really quickly. And chances are, if someone is emphasizing being an industry expert, I’ll bet they are not overly strong in pure analyst skills.

Be Happier

There is nothing worse than dealing with a bad hire. Well… I hate it! Not just the HR stuff, but also what it does to your good performers and the overall project. If your company doesn’t already have great role descriptions in place, try some of these techniques. Having a great team is just a happier place to be.

A Few Thoughts for Those of You Looking for a Job

Lots of folks are out looking for positions today. Here are a few thoughts on positioning yourself for something else:

  • Consider positioning yourself as a specialist. You do a few things really, really well.
  • Try putting more active tense “services” you provided to the organization in your resume. Hiring managers (and google) scan for keywords.
  • List proof of your skills as your accomplishments. (How about: ‘Lead analyst principally responsible for facilitating requirements meetings on over 50 projects’)
  • Make your expertise as an expert analyst come out

Trying these ideas means deliberately writing a resume that does not fit every opportunity for a contract BA. The idea is to position yourself for certain types of opportunities, and to be successful in landing a spot when one of those types appears. As an interesting side benefit, employers tend to pay more for someone they perceive to be a specialist than they would someone they see as a generalist.

I wish you all great success.


For more Business Analysis Resources, visit www.iag.biz

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

Analysis versus Needs Analysis

Most analysts can do analysis…but very few can really be proactive in helping customers figure out their needs.  Executives routinely complain about analysts being passive on projects, not proactive, or inconsistent in their execution. I think this is a real challenge that needs to be addressed. 

Done well, business analysis is a leadership role; one that actively impacts the speed and outcomes of IT development activity.  In this leadership role, analysts have the skills to proactively lead stakeholder discussion and create information in a format that communicates well to both business and technology about business needs.  Analysts are playing the role of bridging the gap between business and technology. 

Without the right processes, techniques, skills, organization, technology and deliverables, analysts default to small ‘a’ analysis.  This is a reactive role, taking in projects and generating activity without momentum.  The clarity of need and outcome is simply not emerging rapidly enough, or with sufficient consensus, or with the right usability of deliverables.  Projects are more difficult with small ‘a’ analysts on your team.  Work may be getting done, stuff is happening, but how much momentum is really being generated?  How much do you need to rework the deliverables of those people?  How many times are you getting the right blocks of content filled in on templates, but very little being said?  Know people like this?

Am I really being too harsh?  To me it comes back to the role and expectations, and I believe analysts provide LEADERSHIP.  Part of this leadership value is that analysts be a strong source of momentum.  This means you can’t have situations like the above.

OK, so you’re looking around your organization seeing lots of what I’ve coined small ‘a’ analysts. What do you do?

There are a few short term tactics you can employ to refocus the value delivered by analysts, and one long term tactic.  In both cases YOU, the manager, need to own the situation you’ve created for yourself.

The short term fix is to focus on ‘elicitation skills.  They’re the methods and practices (like facilitation) of engaging stakeholders and asking the right questions at the right time to extract the information needed to determine business need.  This has immediate benefits in the focus of analysts and their abilities to engage stakeholders.

You can also implement a short term fix about quality standards:  getting away from defining the completion of the template as the standard, and going toward setting clear guidelines on the fidelity of information in the template.

Finally the short term fix could be to look at the services that your analysts provide to the organization and change the intake process for new projects that want to use these services.  It can have a profound effect if the requirements management team knows how to quickly understand the status of a project, and create more clearly defined work packages for their analyst teams from this understanding.

In the longer term, the management group has to assess requirements definition and management maturity, and set out a plan for improving this maturity level.  It’s the only way to get stickiness on change.  An organization cannot hope to make substantive improvement by focusing only on one capability:  skills (continuously training), process (continuously redesigning or enforcing a process), techniques (being militant about the use of certain standards), deliverables (getting people yet another template), organization (going from a requirements center of excellence to a center of practice), and technology (roll out something else… again!). 

Business analyst management needs to look across all capability areas and systematically improve the consistency of the organization across these areas.  The value of making this improvement is also extreme, doubling most performance metrics on projects.

Why do I get passionate about this?    Seventy five percent of organizations last surveyed were poor at doing requirements… 

To really meet business need, analysts need to be leaders.

Read the Article & Comments


Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

6 Steps to Prioritizing Your Business Requirements

Guide to easy and effective requirements prioritization

Step 1: Understand the Purpose & Strategy for Prioritization

  • What will you do with the prioritized items?
  • Prioritize to eliminate items, ensure alignment to objectives, plan scheduling, manage scope creep, etc
  • Identify items to prioritize

Step 2: List the Customer Needs

  • Select what factors the stakeholders feel are important in prioritizing the requirements
  • List the factors that drive the characteristics, scope and functionality of the software product
  • List the business benefits or objectives (cost savings, revenue impact, ease of use, utility, etc)
  • Determine the customer importance of each

Step 3: List the Requirements

  • List the Requirements, either individually, or by cluster (Activity, Function, etc)
  • Place as the columns
  • Use labels and numbers if cross-reference is helpful
  • If more than 20-30, separate and iterate

Step 4: Facilitate the Rating of the Need / Requirements Interrelationships

  • Potentially laborious task must be well facilitated
  • There are two options: 1) Pre-session survey; 2) In-session voting
  • Use chosen numerically assigned scales
  • Key Success Factors for need rating 
  1. Set-up – Get the right needs & requirements chosen (purpose-based)
  2. Involvement – Get the right stakeholders involved
  3. Facilitation – Skill as a facilitator
  4. Tools – Use the right methods and tools for voting 
  • Once completed, calculate the weighted importance rating for each column

Step 5: Determine Technical / Development Factors

  • Usually this is a separate session: Project Team and Technical SMEs
  • Estimate the resource and cost requirements
  • Typical factors are level of effort (or resource requirements), technical difficulty, and cost

Step 6: Determine the Priority Rating

  • Facilitate the priority rating for each column (requirement) based on the Importance Rating, and Technical / Development factors
  • Record earlier decisions made on ratings and scores allow for easier consensus and agreement, and more accurate and effective decisions based on agreed criteria and factors
  • Remember to reference, walkthrough, and review the requirements and specifications
  • Techniques: blind voting, statistical calculations, mapping, group discussions, group decision-making, 4 quadrant graph, or executive decision
  • Update the requirements document with the rating scores
  • As necessary, continue to determine the decisions on the requirement, the schedule and the responsibility

Click here for more business analysis resources


Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.