Tag Archives: requirements maturity

Five Change Management Best Practices for BA/RDM Maturity Improvement Programs

Change Management LessonsImplementing new or refined processes, practices and rules for requirements and analysis in the project and development lifecycles can have significant organization benefits but can also be challenging and risks failure if not done effectively. The importance of effective change management cannot be overstated. IAG Consulting has learned a number of lessons from the hundreds of transformation programs we have implemented over the years. Here we share are few best practices to ensure the desired results are achieved as expected.

1. Define a Clear Vision, Strategy, and Goals

Change initiatives tend to lose momentum when the end-goal is not clearly understood and shared by all participants in the transformation. If not sufficiently defined and accepted (which is usually the case) consider facilitating collaborative session(s) around the organization and program’s vision, strategy, and goals (or having them professionally facilitated). Goals are then defined in an actionable manner so it is clear when milestones are met. The vision must be known by all stakeholders and buy-in a requirement – not just a desired outcome.

2. Establish a Sense of Urgency

The significance and value of a change initiative requires that a sense of urgency be established upfront and continuously reinforced. The failure of past change initiatives often establishes a sense of complacency that affects new change initiatives. All those involved need to intellectually and emotionally understand why the change and improvements are needed, the urgent benefits of realizing them, and the costs and risks of inaction, delay, and ambivalence. John Kotter, in his book about leading change, adds, “Never underestimate the magnitude of the forces that reinforce complacency and that help maintain the status quo.”

3. Utilize a Collaborative Team Approach

Often initiatives fail because they are driven or championed by a single group. No one individual or area has all the answers and information needed to make decisions in the rollout of a transformation initiative. Pulling in stakeholders across the organization upfront brings in better decision making and reduces obstacles that could occur later if the approach as not collaborative. Our experience directing successful change initiatives has taught us the indisputable necessity of creating a coalition of change partners, and how to productively lead diverse teams to success.

4. Generate Quick and Frequent Wins

Transformation is a long term process. Complacency can settle into a program if visible and tangible success is not illustrated quickly and frequently. Identifying early quick hits, planning for small, iterative and incremental phased roll-outs, and demonstrating visible victories with short and early pilot projects are among the tactics to employ that demonstrate the benefits of the changes being introduced – and provide evidence that the sacrifices made to implement change are worth it.

5. Monitor and Adjust in Response to Problems

With an iterative and incremental phased transformation, refinements and course corrections can be made to respond to inevitable challenges and change. To be effective, a program must have defined and measured performance metrics to track progress relative to established goals. These KPIs also help to flag early identification of adoption challenges – that can be systematically analyzed so that practices and deliverables can be dynamically adjusted to better meet the anticipated, ongoing and ever-changing complex needs of the organization.

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.

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.

PMI Releases New Report on Requirements Management

This past week, The Project Management Institute released results of a study on one of our favorite topics – the importance of requirements.   PMI’s Pulse of the Profession® In-Depth Report on Requirements Management will hopefully serve as a wakeup call and provide some strong justification to the many organizations who are searching for solutions to project and performance improvement. This is a comprehensive report that touches on many facets of the business analysis profession and requirements management maturity. Aaron Smith, the author of the study, provides a thorough analysis and strong statistical evidence that Requirements Definition and Management (RDM) remains as critical and necessary for project success as it ever has. 
 requirements-management
While the report does not specifically mention or differentiate results across methodologies and project types, we know that today’s IT projects and programs vary extensively in their development and implementation approaches i.e. off-the shelf software, SaaS, complex integrated systems, mobile apps, agile, lean development, etc.  We are pleased to see actual results that back up the IAG Business Analysis Benchmark and our industry surveys that attention to good requirements leads to less failed projects of all shapes and sizes.
 
The report echoes many studies that place inaccurate requirements as a primary cause project failure (stated in 37% of organizations) and highlights that regardless of this key finding:

  • less than half of organizations report having adequate resources involved in requirements and business analysis,
  • one in three are not doing enough to develop skills and competency in RDM, and
  • almost 90% feel their requirements processes and practices are not good enough.

 
On the plus side, 50-60% of organizations are actively involved in making improvements. However this still falls short given 87% of organization believe they need to improve their requirements processes and practices.
 
The findings lead to an obvious contradiction – especially with high performing organizations recognizing tangible benefits of defining and managing requirements: While two thirds of organizations understand (what to us insiders is so blatantly clear) that good requirements are critical for project and business performance, approximately one third of executives and sponsors still don’t fully value defining requirements for their programs and projects.     
 
This report should be an open call to executive management to urgently and actively support the practice of requirements management (RDM) in their programs.
 
In whatever initiative you undertake, make sure you are defining and continuously managing your goals, objectives, needs, and requirements to drive your selection, modifications, and development decisions, and to manage your performance.
 
And as this report concludes, it is a focus on people, processes and culture that will ensure that requirements management is a core competency for project and program success.

To download this report for free, click here: http://www.pmi.org/~/media/PDF/Knowledge%20Center/PMI-Pulse-Requirements-Management-In-Depth-Report.ashx

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 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

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.

Requirements Maturity Checkup!

How mature is your organization’s requirements practices? Now you can find out!

IAG Consulting has just launched a new (free) online assessment tool that will evaluate your requirements maturity based on 40 questions. The assessment is based on IAG’s industry recognized Requirements Maturity Model and will give you a report with your overall maturity score and some recommended actions for improvement.

Take the assessment

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.