Tag Archives: IAG Consulting

Checklist for Developing a Requirements Transformation Program

A Requirements Transformation Program

A program to improve the organization’s capability to develop and manage requirements in support of application development and other business initiatives.

A program to move an organization up a maturity ladder of requirements capabilities in the following areas:

  • Process
  •  Practices and Techniques
  • Technology
  • Organization
  • Deliverables / Results
  • Staff Competency

Building the Business Case

Generic statements concerning the value of good requirements will not be sufficient to support spending time, budget, and resources on a program to transform requirements in your organization. Whenever resources such as money or effort are consumed, a clear explanation of rationale is needed in business terms indicating quantifiable benefits.

It is always necessary to clearly explain the timeline and return on investment (ROI) that requirements improvement provides. Ongoing executive support is crucial for the success of a requirements transformation program.

  1. Use the Maturity Model as a framework for improvement
  2. Be forward looking, not backward looking
  3. Positive in reasoning, not negative
  4. Simple arguments get funded while complexity just confuses
  5. Be sensible about what can realistically be accomplished
  6. Spend your time asking good questions
  7. Get the hard facts: Include industry studies such as the CHAOS and BA Benchmark Reports
  8. Talk implication, not problem or need

Baseline Your Level of Requirements Management Maturity

  • To understand the relative strengths and weaknesses of the organization across multiple capability areas
  • To set a quantifiable baseline measurement to measure subsequent improvement against
  • To serve as a reference for directing requirements improvement on a targeted basis to best suit your organization

Creating a Requirements Practice Improvement Plan

  • To serve as a communication vehicle to the change process
  • To provide a common understanding to the organization of the tasks and target objectives of the change process
  • To serve as a reference for tracking progress against objectives

Click here to get the checklist

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.

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

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

Understanding Your Role in a Requirements Session

1. Requirements Team (Facilitator, BusinessAnalyst)
Enable the requirements discovery process by:

  • Asking relevant questions
  • Recording answers provided by SubjectMatter Experts
  • Keeping the process moving
  • Utilizing effective facilitation anddocumentation skills
  • Keeping the discussion focused onobjectives and scope
  • Confirming understanding among/withparticipants
2. Business Leader / Project Sponsor
Provide the business vision by:
  • Explaining the problem/opportunity
  • Defining the vision
  • Defining the business objectives
  • Determining the measures of success
  • Defining high level process andrequirements

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

It Ain’t Easy Being Agile

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.



Continue reading

The Pendulum Swing of Organizations

I wonder if organizations give out awards for surviving the most reorganizations in a single decade to particular business functions.  I’m thinking that most analysts get to experience this frequently as the pendulum of organizational design swings from housing analysts in the technology organization, in the business organization, centralizing or decentralizing.  As business reorganizes, technology changes alignment, and the moon aligns with various constellations, reorganization is triggered.  I’ve been asked to weigh in on this a bunch of times.  Here are some thoughts for whoever is gunning to get the new design in place for September.

There are Lots of Designs that Work, but Very Few Organizational Designs Promote the Goal of Improvement

If you have a team of BAs, you can organize by application, by business, by seniority, by type of BA, by geography, then you can organize management centrally, or by business line, or by matrix of business and IT, or … and the list goes on.  All designs are for a reason, so they will all accommodate some aspect of the culture or gap or improvement, or machismo that needs to be addressed.  Only some designs will promote the goal of improvement in the capabilities of BAs and consistency of service brought by BAs to the organization.  The designs that best enable improvement bring together and optimize three basic areas:

  • The Framework: What are the processes, practices, tools, metrics, deliverables and standards etc, of doing requirements?
  • The Resources: How are the competencies defined and managed, how is performance managed, and how are resources allocated to work?
  • The Infrastructure: This is the governance, business alignment, organizational integration k, etc.

The more fractured these things are, the more difficult to manage and promote standards and change. By the way, improvement may not be the primary organizational design constraint and sometimes you need to work with a suboptimal organization structure to enact change.

A Few Pointers 

Even when you have a poorly designed analyst organization, there are a bunch of things that can be done to make it function better. 

Centralize Analyst Work Intake. Even if the organization is a complete mess, centralizing the small function of estimation and work package creation pays massive dividends, especially when the analyst organization is larger.  And, it’s not expensive.

Think Services.  Sometimes it is not possible to get centralization on the entire analyst organization, but it is possible to get an institutional focus for a small set of high-end services, especially when these services are directed at success for larger projects.

Revise the Hiring Practices. I’ve come to the conclusion that a lot of companies don’t really know how to hire BAs.  I think people don’t realize it’s a tactile job, yet a lot of companies hire without seeing how a BA does these hands-on things.  It’d be like hiring a nanny without ever checking out how they interact with the kids.  I’m not talking about charisma or being personable here, I’m taking about aptitude and the ability to ‘do through interacting’.

Right-size the Organization.  One of the biggest oddities is the vast differences in size of the analyst function at different organizations.  Sometimes one or two BAs are driving $100M in projects, sometimes it’s over 100.  When you get way too few, the organization get really ineffective because all the people can do is be traffic cops and oversee the outsourcing of work.  When you get too bloated, the work progress slooooowwwwssssss waaaaayyyyy dooooowwwwwwwnnnnnnnnn; it’s painful to watch.  We get people that are used to taking a week to deal with what we deal with in a day – it’s really hard to reset expectations.  It’s not difficult to do know the right number of people, but hiring headcount is often difficult to deal with.

Be Positive and Patient. There is a time and situation when changing the structure of an organization  becomes dramatically desirable.  There are also times when no amount of executive discussion will create openness to change.  As anyone paying attention to the recent financial fiasco knows, external influences can create a 180 degree change in focus extremely quickly.  Timing and planning are everything, as are planting seeds for change … sometimes for years.  Remember, eventually, most companies try to do the right thing.


Click here to see the full article

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.