Tag Archives: IAG Consulting

Choosing Business & IT Participants for Your Requirements Sessions (Video)

Having the right mix of people is critical to the success of requirements elicitation sessions!

Click here for more on Choosing Participants for your Requirements sessions


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.

The Technology of Business Analysts

Here’s a personal opinion: Business analysts remain one of the last bastions of antiquated technology. Put up your hands all of you only using Word and Visio. Probably only 20% of you have requirements management software, and even fewer have requirements definition tools worthy of the name. Yet everyone is under pressure to improve performance and productivity – especially now that the economic recovery is underway and project pipelines are filling rapidly. Here’s a quick primer on the Dos and Don’ts of acquiring analyst productivity software.

OK, so analysts are the proverbial shoemaker’s children, always defining requirements for the solutions of others, and never for themselves. Unfortunately, this is the cardinal rule that many analyst organizations break – they don’t properly define requirements when they look for analyst requirements definition and management solutions. Seems a little crazy doesn’t it? A quick suggestion would be to step back from the glitz of the technology for a minute and perhaps run some facilitated sessions to identify the analyst processes, the information required to support these processes – maybe even identify a few interdependencies? Sound familiar? Once you do this, the wide variety of solutions out there start rapidly falling away – and very few likely remain.

Would it surprise you to learn that there are over 100 analyst tools that are well known enough for IAG to track them? Who knew the lowly analyst had so much choice? When you evaluate tools, it is easy to get caught up in the sizzle rather than the steak. The sizzle are the flashy functionality around the system that make it more flexible in execution. The steak is the no-holds-barred answer to the question, “what was this thing principally designed to do?”

Since the sizzle is infinitely more interesting, let’s start there and talk about the kinds of sizzle you can get in an analyst tool:

Tool Integration. All tools have a degree of model sharing; upstream (to portfolio management, or project management) and downstream integration (to quality systems or development). This model sharing is either fully bi-directional (YAY!), meaning changes in one system are reflected in the other, or it is accomplished by simple export (BOO!) which can lead to all kinds of synchronization problems between repositories.

Documentation Generators. All tools are either better or worse at generating standard document templates and some are fairly configurable so that you can replicate existing internal standards for information production. More critically, these tools either capture into the repository the changes made to output (YAY!) or they force you to edit the format every time you print the same report (BOO!).

Stakeholder Collaboration. Most tools have a degree of automated collaboration to capture stakeholder commentary which is free (YAY!) but some tools force you to license the viewers and collaboration engine (BOO!). Usually, there is an auditing capability for indicating who said what, giving traceability on stakeholder review, validation and acceptance content.

Model Sharing and Global Repositories.: Tools are typically designed to be massively multi-user (YAY!) or they are primarily a single user system that can share models between users (BOO!). The difference between these are the server database options, security/access controls, check in/out controls, model sharing options and controls, etc within the system. Many systems lack the concept of a’project which I think is a bizarre oversight. A project has unique attributes like a charter, stakeholders, objectives, etc. and would include one or more use cases from an enterprise requirements repository that could easily be sharing the identical use case out to another project being worked on by another analyst. Some systems enable these concepts, many do not.

Object Relationship and Impact Assessment. Most tools enable the user to define custom object types, however the big YAY is the ease with which relationships are established (one click versus, in some cases many, many, many clicks) and the degree to which you can compare object types or look at object relationships. This type of functionality is ABSOLUTELY critical for traceability management and impact assessment. Traceability and impact assessment needs you to first establish relationships between objects (which can be cumbersome in some tools), illustrate these relationships in standard models, and be able to show how relationships are impacted under changing circumstance.

Ability to Embed Analyst Best Practices into the System. In a bizarre twist of fate, the better a tool is, the more ways it has to represent information in the system and the less usable the system is ‘off the shelf’ without some amount of training. This is a good-news, bad-news story since better quality requirements definition and management systems are highly customizable, but it could potentially spell chaos for larger teams of analysts unless some standards are set. The best tools have package configurability and the ability to embed elements of your analysts processes into the tool – meaning you can preset what objects are called, the attributes of objects and even eliminate certain options that you don’t want available to analysts in your company’s implementation of a particular tool. The purpose is to force analysts to model specific things, using specific techniques, in specific ways.

I could keep talking, but remember, these functionalities are the sizzle, not the steak. Yes, they are important functionalities, BUT, you have to first and foremost decide what analyst business processes you are trying to support – just like you’d advise your stakeholders to do. When you only focus on the sizzle – every tool has some degree of sizzle and every tool has some degree of functionality in every area above. When you get down to the steak – tools were either designed to support certain analyst processes, or they were not.

Tools tend to fall into different categories based on what they were first and fundamentally designed to do. Often, if something excels at one domain, it is poorer in other domains. You need to step back and pick one:

  • End-to-End Suites. Take IBM’s Rational product line for instance, or a number of the Application Lifecycle Management (ALM) tools. Here the big difference is the scope of the software and component integration between the tools. These systems are principally designed to be end-to-end and you buy into the end-to-end concept rather than best-of-breed components. Inherently, this kind of design will have gaps. Some of these (like Rational) have requirements management (Reqpro/Doors) AND definition functionality (RRC), some are only requirements management tools. Some have the ability to manage conceptual and logical data models – others do not. Be careful.
  • Requirements Visualization Tools. These popular tools (like iRise or Microfocus’ TeamDefine) are mainly designed to allow stakeholders to interact with visual models of a system. I draw these into two broad categories: ‘Visualization’ tools allow stakeholders to visually experience the process flow of an application but they’d probably want an analyst walking them through the activity to talk about the specific rules and functionality. ‘Animation’ enables stakeholders to fully interact with the system interface, and by embedding data rules behind the system, the user can also experience error conditions and alternate scenarios by operating (or animating) the system. Both classes of visualization tools have numerous vendors selling quite capable tools. Other points of evaluation are the fidelity of the models you can create.
  • Requirements Modeling Tools.: There are tools like eDev’s InteGREAT (or Requirements Composer by IBM) that were principally designed for an analyst to model business requirements. Others, like RAVEN, are focused on a specific type of modeling (Use Cases) and are more ‘assistive‘ for analysts (where we’re using all meanings of ‘assist’ e.g., increase productivity, help the analyst learn, automate the production of something, and act to increase quality). The key differentiators between systems are the number of model types created, the model fidelity, number of domains of knowledge that can be created or managed – some only allow the modeling of process knowledge, others can model any number of dimensions of knowledge (Process, data, rules, issues, interdependencies/interfaces, training, etc) and the degree of knowledge transformation (given a text description will the system create graphical description and vice versa) or given a use case model and clear actors, can the system render a cross-functional swim lane diagram.
  • UML Modeling Tools. These deserve a special mention since the UML can be used to generate a rich model of a business process and identify/manage requirements. The upside to these tools is often the ability to forward and reverse engineer code or to model enterprise architecture. The downside is that you are locked to the UML and this modeling standard’s ability to resonate with business stakeholders that are not trained in the UML. The big differentiators here are very numerous since UML tools also get used across the entire application life cycle.

If you go beyond the above four areas there is also a whole series of tools from other domains like quality (HP’s Quality Center), Enterprise Architecture (Casewise), Business Process Management (IDS Scheer), process logic capture tools (StereoLOGIC), among others that are converging to better service the needs of business analysts.

The landscape is filled with productivity tools that are well designed to make analyst teams more productive. IAG has itself implemented or used most of the ones I’ve named here and we are resellers of more than six of them so I’ll not stand up and endorse one vision over another. The key is to recognize that there are choices – a huge number of them – and take the time to do the requirements analysis properly before selecting and implementing a system. As ironic as it sounds, it seems that lousy requirements definition is pervasive when looking at requirements definition and management tools. Use the purchase of a tool to figure out your analyst processes and to strengthen consistency. Don’t be the shoemaker’s child any longer.

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.

10 Ways to Use Requirements to Melt an Executive’s Brain

So you’ve been tasked to get requirements on a strategic project, and you’re thinking to yourself, “How can I make my business requirements documents as incomprehensible as possible?” Going this route may not be just a job security thing. Making yourself indispensable as the interpreter of requirements seems to be the traditional route of delivery and getting buy-in. Just keep running the requirements process until someone gets desperate and finally signs off on the spec in the vain hope of getting something useful for their effort before the end of Q4 2014.

So, some tips and traps for those of you looking to truly perplex and bafflegab your bosses:

  1. Just give a list of “the system shall …” statements. Having a few hundred of these statements with no accompanying business process descriptions as a common point of reference to help navigate the swamp will keep the average executive bogged down for days. Their paranoia that something critical got missed might just match your paranoia when they show up at your desk to have requirement 143 explained to them.
  2. Experiment with similes when describing data objects. No one wants to hear about ‘customers’ repeatedly. Why not make the document more dynamic and talk about prospects, or accounts, or valued relationships, or partners, or something more interesting. You just shouldn’t be overusing simple words repeatedly … it’s boring!
  3. The use of UML sequence diagrams and class diagrams will help prove to that doubtful executive that you truly understand systems development and have a deep understanding of industry standards. Just loading up their inbox with hefty documents packed with these pretty pictures will have them panting for more.
  4. Remove all evidence of traceability between one set of requirements and the next. The idea is to produce a set of business objectives and scoping documents in one format and using one set of techniques. Then get your business requirements using something completely different. Go for something truly unique in the system specs. The idea is to show your diverse understanding of ALL the different approaches available to the business analyst. Besides, they are signing off on each document separately anyway… there is no real need to look back at what came before.
  5. Be snappy with solutions. No matter what the request. Within three minutes of the executive’s starting to the grand vision, cut him or her off and begin explaining how the solution is easily delivered by looking at the existing legacy applications. Your attention to promoting existing corporate assets will be well received.
  6. Tell your CFO that you want to use Xtreme programming on the Basil II financial compliance project. The idea of a programmers eagerly jumping into the breach to resolve important issues for the business should be warming to her heart.
  7. Tell your outside sales force they need to be dedicated to a requirements discovery session for three weeks. Your attention to thorough detail will be appreciated by the SVP sales.
  8. Adopt PowerPoint as your primary documentation engine. A few simple screen mock-ups to show the user interface will immediately grab everyone’s attention as delightfully artistic. Besides, the workflow behind it should be entirely self-evident to any self-respecting programmer that’s been with the company for a few dozen years.
  9. Make sure the first dozen pages contradict the second dozen pages. Every executive should be presented with options. How could they not like alternatives for the business?
  10. Drop out key sections of the document and pop these into secondary or tertiary documents. Then refer generally to the existence of these other documents, but don’t put in the actual page, or a hyperlink. This is a great way to ensure they read the whole thing.

Hey guys – have fun and add your own. I wish you all great success.

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.

What is Requirements Maturity?

We’ve been in the business of helping companies improve their requirements definition and management (RDM) maturity for over 13 years.  One thing I’ve noticed is that companies that have made significant improvement in RDM tend to believe they are operating at a higher level of maturity than they actually are. There’s a tendency to beat the chest and sing the praises of organizational excellence in RDM, when the reality of project performance and efficiency speaks otherwise. There are really two issues:

  1. Every organization has blind spots – people focus on what they do very well and tend to stay focused on these issues to try to spur further improvement. As counter-intuitive as it sounds, this doesn’t work in RDM and you get a false sense of continuous improvement. In RDM, you have to find the blind spots, the stuff you don’t do well, and fix those to really make gains.
  2. People define RDM “maturity” in different ways, either narrowly describing it <<<shiver>>> as merely having a stable documentation template that is used across the corporation, or more properly, a unique process within the organization that is defined, resourced, and supported.

So, simply – what is RDM maturity?  Process Maturity is all about the degree to which an organization can be repeatable, consistent and efficient in execution on a process – same thing with RDM.  Organizations with no defined process, or a process that is defined but not enforced, would have low levels of maturity, just like organizations with well described, institutionalized and optimized process would have high levels of maturity.  The issue is that it is not just process you need to look at, there are six underlying capabilities:

  • Process – What people need to do.
  • Technique – How people will do various steps in the process under certain variations and conditions.
  • Staff Competency – The skills, roles, functions of your people and their alignment to this target currently and in hiring practices.
  • Tools/Technology – The support and automation used to complete tasks.
  • Organization – The framework of doing requirements, infrastructure backing it, the services offered to the organization, and approach to managing resources.
  • Deliverables – The actual artifacts, deliverables and work products needed to make the process work.

Here is where most people fail…  they don’t look at ALL the underlying capabilities.  An example organization might have well defined process and deliverables, but a terrible definition of the staff competencies needed and little training and support to build these capabilities.  How effective is this organization going to be if they are essentially defining what they want people to do, but not giving people the skills to perform those tasks?  If you believe yourself to be a high maturity organization, look across all six capabilities – which is your weakness?  That’s the one you need to focus on.

The other mistake people make is in thinking of requirements as only documentation, or only elicitation.  In fact the “process” of requirements is made up of a number of really important processes like:

  • Requirements Planning and Management
  • Requirements Elicitation (requirements gathering)
  • Requirements Analysis and Documentation
  • Requirements Communication
  • Requirements Implementation

In reality, and organization may think it is very good at one or two of these process areas, and therefore consider itself mature, but few organizations look across all the process areas and understand their strengths and weaknesses. Again, just because you are great at one thing, does not mean the entire process is particularly efficient or predictable, and that means that it cannot be considered mature.

Getting maturity in your requirements organization might sound complicated, but it’s really all about being honest with yourself in looking at the organization and accepting that there are always areas of improvement.  Most of the time, these improvements are in areas that the organization does not see – it’s blind spots – so often, it’s necessary to bring in outside people to assess the organization… just like you would with auditors.  So organizations often go around thinking they have a more mature organization than they actually do… and they miss out on the benefits thinking there is limited room for improvement.  On the upside, high maturity organizations have exception on-time, on-budget, and on-function performance – they also tend to deliver applications at about 40% of the cost of their low maturity competitors.  I’m wondering:  what other investment in IT yields so much just from being very frank with yourself?

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.

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.

Microcast: Great Requirements Are Free

Great requirements are free! 

Everybody understands that requirements are important, but most do not internalize that fact and take action.  In this fast-paced 8 minute video microcast you will find out that great requirements definition and management can dramatically reduce the cost of projects while greatly increasing the likelihood of success.

Poor requirements account for 70% of all project failures.  By investing in the requirements stage of a project, companies can:

  • earn significant savings in over the long term 
  • use less stakeholder time 
  • arrive at consensus faster
  • make more efficient use of development budget

In Great Requirements Are Free these points are demonstrated with examples and case studies that show the steep premium that companies pay for poor requirements. 

Click here to watch the microcast!

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.

Top Books for Business Analysts

7 Books for brushing up on your skills

1. Mastering the Requirements Process | by Suzanne Robertson | Excellent end-to-end coverage of the requirements process

2. Software Requirements | by Karl Eugene Wiegers | One of the best introductory books on business analysis

3. The Business Analyst’s Handbook | by Howard Podeswa | Terrific reference and resource material. Very strong alignment with IIBA material

click here for the complete article from IAG Consulting


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.