Skip to main content

Tag: Development

IT Methodology – Offering Small and Mid-sized Businesses (SMB’s) Operational Performance and Impressive Bottom Line

Written by Cameron Watson on . Posted in Articles.

As world market conditions continue to evolve, so too have the pressures and expectations being placed on organizations.  In many cases, the difference between red and black ink can often be attributed to the operational effectiveness derived from the “IT Efficiencies” of the organization.

Since information technology became a part of the business mainstream, business stakeholders, IT practitioners and academia have debated the various and most effective organizational “IT Efficiency” solutions. Though opinions have differed, most concur that an “IT Methodology” is one of cornerstones any organization can leverage to increase its operational performance and bottom line. Many agree that an organization that utilizes an “IT Methodology” has a competitive advantage in its ability to deliver and support its products, business applications and day to day operations.

For the sake of context, “IT Methodology” can mean different things to different organizations and audiences. As a noun, “IT Methodology” can be viewed as the roadmap project managers and business analysts rely on to consistently deliver products and applications on time and within budget – examples include IBM’s Rational Unified Process, PMI’s Project Management, QAIassist’s Integrated Methodology, Prince2.  As a verb, “IT Methodology” can be viewed as the various modes of travel (practices and techniques) a project manager applies while using the roadmap to get to their destination (completed project) – examples include waterfall, agile, spiral, rapid application development RAD.

The benefits of an “IT Methodology” are:

Repeatable Organizational IT Process – An “IT Methodology” (noun) can be applied as an organizational process.  As a process, organizations are able to define, utilize and repeat a common approach used to develop and support their products and business applications. By utilizing an “IT Methodology” as a process, organizations are able to introduce corporate quality assurance (quality products and applications are produced when the process is followed) and organizational improvement (analyzing the metrics and measurements of how the process is being used).

Consistently Deliver Applications on Time & Budget – In being repeatable, an “IT Methodology” (noun) affords organizations reliability in how products and business applications are developed and supported. Project team members (stakeholders, business users and IT) are able to understand their roles and responsibilities, project plans can be defined and approved, and the necessary deliverables and artifacts needed to complete the project can be identified. Applying an “IT Methodology” establishes a degree of structure that project teams leverage (and re-use) to deliver their projects on time and on budget – the more often it is used, the more proficient the project team becomes at applying it – the more proficient they become the greater the savings in time and budget.

Optimize Communications (Stakeholder, Business Users, IT Project Teams) – An “IT Methodology” (noun) acts as the glue that keeps a project team together and working from the same page. This includes project stakeholders, business users and IT project teams. Project Managers are able to dedicate project resources to specific responsibilities and the creation of specific deliverables and artifacts as part of the project plan. Project team members have a clear understanding of their roles and responsibilities and procedures used to administer the project. Project Stakeholders will have a mechanism to quantify the status of the project team with regard to progress, risks and issues. 

Incorporate Organizational Governance – An “IT Methodology” (noun) provides senior management a tool that can provide predictability (schedule, costs, quality) on how the IT staff develop and maintain products and applications. This predictability affords senior management flexibility to budget and prioritize what applications are to be completed, when they can be completed and what resources will be available to deliver these products and applications. It also provides senior management an ability to re-adjust the priorities of the IT resources to reflect the business priorities.

Establish Resource Diversity – An “IT Methodology” (noun) provides organizations a basis for developing cross-functional expertise in both the business and the IT sides of the house.  As a resource learns more on how an “IT Methodology” is applied they can leverage that expertise to become effective in other areas of the business (i.e. an apprentice carpenter that has learned to use a hammer to build a dog house can rely and re-use that same knowledge when building a deck or a house). This offers flexibility in how resources are to be applied and offers staff an avenue to gain additional expertise and knowledge in other areas of the business.

Though the concept of increasing operational performance and bottom line through an “IT Methodology” may be obvious, there remains a huge gap in how various organizations are able to implement these solutions.  Large sized organizations have traditionally relied on large sized IT tool vendors and consultancies to acquire and implement complex and all-encompassing “IT Methodology” solutions – in the majority of cases they have created internal Project Management Offices (PMO’s) specifically dedicated to implementing and supporting these “IT Methodologies”. SMB’s have not always had the same financial flexibility nor the same need to acquire and implement these elaborate and all-encompassing “IT Methodology” solutions offered by the large sized IT tool vendors and consultants.

In today’s world, SMB’s are being squeezed from many directions and must rely on their ingenuity and nimbleness to navigate through these challenging realities. All too often the difference between an SMB keeping its doors open and making a profit is a direct result of its operational performance and “IT Efficiency” – on whether or not it utilizes an “IT Methodology”. Although benefits can be derived from an “IT Methodology”, SMB’s must assess the other side of the ledger in the Return on Investment (ROI) equation – implementation requires addition considerations.  They include:

Access to “IT Methodology” (noun) – Traditionally SMB’s have had limited options in acquiring an “IT Methodology”. Their only alternatives were (a) acquiring the complex all encompassing solutions offered by the large tool vendors and consultancies or (b) not using any one at all because the costs of acquiring these all-encompassing products and services are often too great.

Acquiring an “IT Methodology” (noun) – As more and more SMB’s are recognizing the competitive advantages of implementing an “IT Methodology” several vendors and consultancies are now delivering scalable products and services that afford SMB’s the products and services they require to improve their operational performance and bottom line.  Scalable “IT Methodologies” (i.e. project management, software development, software testing) can now be acquired at a minimal cost – a standard licensing fee is applied. Licensing fee applies to the initial acquisition and a minimal monthly support fee.

“IT Methodology” Implementation – Upon acquiring an “IT Methodology” SMB’s must go through the exercise of having it customized (scaled) to ensure it is optimized to contribute to both operational performance and the bottom line.  Though implementing an “IT Methodology” is unique to every organization, most SMB’s will incur costs associated with customizing the “IT Methodology” to their specific circumstances, training the staff on the applying the “IT Methodology” and coaching the staff through several  initial projects.

Ongoing “IT Methodology” Expertise – As an SMB becomes more proficient at applying their “IT Methodology” there may come instances and temporary circumstances where they will require additional “IT Methodology” expertise in delivering or supporting additional products and applications. In these cases it will be advantageous for them to acquire consulting resources familiar with the “IT Methodology” – these resources will be able to make an immediate contribution to the project team and an impact on the delivery of the product or application.

As global competition continues to drive business and technology, organizations armed with an “IT Methodology” increase their operational performance and their ability to consistently deliver higher quality products and services to their clients. The result – more satisfied clients and an increase in bottom line.

 Don’t forget to leave your comments below.

Cameron Watson is the President of QAIassist. QAIassist helps small and mid-sized organizations (SMB’s) increase their operational performance and bottom line through IT efficiency. QAIassist’s Integrated Methodology incorporates the disciplines and deliverables SMB’s leverage to consistently deliver quality applications on time and within budget. Visit QAIassist’s website-www.qaiassist.com

Requirements Development 101

Written by Zenobia Godschalk on . Posted in Articles.

Many organizations that I work with understand that better requirements engineering practices would alleviate many pains in their current software development lifecycle (SDLC). But some of these organizations don’t know how to improve their practices because, I believe, they don’t fully appreciate the world of requirements engineering. So I am writing this article to describe, at a high level, the components that make up requirements engineering. Once the components are understood, then organizations can see what is missing or what needs to be modified in their current environment to arrive at a better practice.

First, let’s define the term requirements. There are millions of web sites that can give you this definition, so I went with Wikipedia (http://en.wikipedia.org/wiki/Requirement). It states that “a requirement is a singular documented need of what a particular product or service should be or perform”. This, to me, means there are many, many kinds of information that fit into this thing called “requirements”. To simplify the matter, let’s start breaking down these kinds of information into categories, or different “types” of requirements. At a minimum, an organization should collect these types:

  • Business Requirements -describes the values this project will provide the organization once it is finished. Some organizations have a vision and scope document, while others just roll it into the generic Business Requirements Document (BRD).
  • User and Functional Requirements, and Business Rules – these describe what the software needs to do and what the development teams need to build. Some organizations have a Use Case or Functional Requirements Specification (FRS) document, while others have it in the one BRD.
  • System and Data Requirements, Quality Attributes, External Interfaces, and Constraints – these types are just a handful of non-functional requirement types that you can collect. Some organizations have a Software Requirements Specification (SRS), while others have it in that BRD, which seems to be looking pretty big right now.

Now that we know what to collect, we need to understand how to collect them. Requirements engineering is broken down into two activities: requirements development (RD) and requirements management (RM). I find most organizations do requirements management well. This is to say, they can manage changes to a set of baselined requirements that have been identified to a specific release. What I find is most organizations have a hard time setting a standard practice around requirements development. I will spend the rest of the article describing this activity. RD is broken down into the following sub-activities:

  • Elicitation – this involves interviewing the stakeholders and determining their needs. This is not writing down everything they say. Stakeholders will not know everything they need the first time you interview them. What they do know, may not fit into the scope of the project or may not be in agreement with the next stakeholder you interview, or may even be wrong. Therefore, elicitation is an iterative and inventive activity. Think of yourself as a detective that asks the questions that gets the stakeholders to think of missing or new requirements that are within the scope of the project. A good way to get the stakeholders to open up is to ask all the “What if …” questions. Another very useful technique to use is to ask “Why?” These questions can reveal missing or unspoken requirements or offer additional details to enhance the understanding of a requirement. Creating these types of dialog is an effective way to increase the completeness and quality of the requirements versus just writing down everything that they say.
  • Analysis – this involves developing detailed requirements from elicitation. These detailed requirements don’t need to be just textual in nature. They can be of different forms, such as business process diagrams, data models, use cases, and prototypes. By gaining greater detail, you will also discover missing requirements. Analysis offers an effective way to recursively refine the understanding of the initial elicited requirements. This is also where you will settle priorities of requirements between stakeholders and arbitrate between conflicting requirements. Because the analyst is the communication hub with all the stakeholders, it is a good idea to identify key decision-makers that will have the final yea or nay power when conflicts arise. This will become even more important when you communicate the requirements downstream to the testers and developers, therefore quick and efficient conflict resolution process is important.
  • Specification – this involves documenting the various types of requirements, which can be textual or graphical. It is usually a good idea to have a few documentation standards for vision and scope document, FRS, SRS, BRD, etc. Many analyst web sites have examples of these types of document standards.
  • Validation – this involves making sure that the requirements are correct and will meet the stakeholders’ needs. One good way to validate requirements is to have the stakeholders develop user acceptance criteria. These criteria specify the primary tasks the software will allow the users to perform and the common errors that the software will handle. Comparing the requirements against the user acceptance criteria will establish if the requirements are correct. On a side note, they also provide starting points for testing scenarios for the quality assurance team.

I would like to point out that you don’t need to develop all the requirements for the entire project at once. Requirements development is an iterative process, so trying to develop detailed requirements all at once can lead to analysis paralysis. During elicitation, you will identify the high priority or first built features. Start with analysis and specification of these requirements and do validation with a quick informal review. Then move to the next set of elicited requirements for analysis and specification, all the while correcting the previous set of requirements of missing or misunderstood requirements that are discovered along the way. By infusing quick review cycles between analysis and specification, you will filter out errors and increase the completeness and quality of the requirements with each cycle. Having multiple cycles will refine the requirements to a level of detail that can be efficiently communicated to the stakeholders, testers, and developers. At the end of the day, a project will never have a set of perfect requirements, but it will have a good enough set of requirements to proceed to development and testing. Since we can never produce a perfect set, we want to adopt practices that result in fewer requirement defects, especially the ones that have high impact and severity. We can weed out these nasty defects before they are injected into the SDLC. This can decrease the amount of development rework, which results in reduced product cost and quicker time to market.

On a final note, to further increase efficiencies in your requirement development activities, you should input all of the requirements in a single repository. It lets you capture elicited requirements and you can you can easily access them for usage as the basis for initial development of detailed use cases, UI mockups, data models and business process diagrams during analysis. Also a requirements repository allows you to trace any requirement to any other requirement. Since it is a repository, you can trace across all these elements to see all the dependencies and evaluate the impact of changes.

Don’t forget to leave your comments below.

Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.

Business Analysts Need to Learn from Developers

Written by Kupe Kupersmith on . Posted in Articles.

Kupe_Nov_9There was an article in the November issue of InformationWeek that made me think of this title.  Developers just get it when it comes to keeping up with new technology and finding ways to stay current.  Yeah, some developers try to use their new toys on our projects even if it is not really needed, but they also do it on their own time.

Years before the BA community had online communities like this one, BA Times, developers have been sharing knowledge and experiences online. I remember being very impressed when a developer I worked with was struggling with a way to code a feature we needed.  He told me to come back the next day and he’d have an answer.  He asked a few simple questions on an online community and poof, potential solutions came rolling in.  I’m glad to see us engaging around the world on the various communities.  I realize our answers are never quite as exact as a solution for a developer, but at least we give each other options to consider.

When mentoring BAs either looking for a job or trying to excel in the one they’re in I often hear things like “I don’t have time for that”, or “I can’t do that at my company”. Lame excuses if I ever heard them.  This is where BAs are falling short and a place we can learn from our developers. The article I read was talking about developers working on open source software projects where only 9% of contributors are paid.  If you are not paid to do something you are volunteering.  Why do developers volunteer their time?  The article discussed the main reasons are they find it fun to solve problems and it is a sense of accomplishment.  The other reason that stood out to me was contributing was a way to master a new technology.   These developers don’t say they have no time or sit idle while they work on necessary projects at work. They make time so new technology does not pass them by. You need to do this too.  If you want to grow, if you want new opportunities, do not pass up volunteering…make the time. 

Success story time! A friend of mine is a director of a BA group.  She had an acquaintance that had zero BA experience, but wanted to move into the field.  With no experience she was getting nowhere fast.  My friend was working most weekends and offered up the option for this person to come in on the weekends and help her for free.  In return she gains valuable experience working with an expert in the field. For 3 or 4 months (I can’t remember exactly) every Saturday this no experience BA worked as a BA.  My friend was so impressed with her passion an aptitude for BA work that when an opening came up, she hired her.  She has since excelled in her role and has had the opportunity to get some formal training. 

 I try to find ways to use my BA skills in every opportunity. I recently signed up to lead a math team at my kids’ school to help a number of students prepare for a math tournament coming up in January.  Since I was new to this role, I was not sure how the system worked (like the various communication methods I needed to use to contact parents and their children, when to work out details with the teachers, how to work with the principal, the process for scheduling math team practices, etc).  So, I used a few BA techniques do document the process and the business rules. If you ever had to work with PTA (Parent Teacher Association) you know there are rules.  Many of you volunteer already in varying organizations.  Think how you can use a BA technique in your current volunteer work.  It is a great place to try out these techniques without being judged.  This is a great opportunity to try out a technique you want to add to you repertoire but have not had the opportunity at work. More than likely people will be impressed.  The downside to that is you’ll keep getting calls to volunteer!

We can learn a lot from developers about how they learn and stay current.  Stop reading this and go grab lunch or coffee with your favorite developer and see how they are staying current. 

If you have a story related to learning methods to stay fresh please share them in the comments.

Never stop improving,

Kupe

Dont Forget to Leave Your Comments Below….

The Business Analyst Facilitator Role in an Agile Software Development Team

Written by Mark A. Monteleone on . Posted in Articles. 1 Comment on The Business Analyst Facilitator Role in an Agile Software Development Team

The purpose of this article is to define the need for the business analyst facilitator role in an agile software development team. Traditionally the business analyst role has been defined in the context of a project, utilizing the waterfall solution development life cycle (SDLC). This approach has the business analyst collecting all the requirements and business rules upfront prior to development. However, today’s demand for accelerated solutions has changed the dynamics of system development to a more agile approach, where requirements and business rules are defined in conjunction with solution development in iterative cycles. Hence, the question – “Is there a need for a business analyst role in an agile software development team?”

Some readers of this article may believe that the business analyst role is not needed with the agile approach. To those of this position, I encourage you to read on. I suggest regardless of the SDLC chosen (waterfall or agile), the role of the business analyst is still needed. As a developer, you may say, “but we are doing fine on my agile project without a BA role.” To you I ask, “Have you examined your expanded role of directly interfacing with stakeholders?” For the past 40 years in the IT business, I have experienced several approaches to solution development. One rule that does not seem to change is that regardless of the SDLC used, functions that roles provide remain. In the agile case, BA functions are absorbed by members of the software development team at some risk.

Please note, I am assuming that the reader is familiar with waterfall and agile SDLC approaches, so I will not attempt to define them in detail in this article. For the purposes of this article, a Scrum like process for the agile approach is used.

As an instructor of business analysis techniques and practices, I often field questions on the role of the business analyst (BA) in an agile software development team as opposed to the traditional waterfall solution development life cycle (SDLC) approach. After much thought and input from many sources, I am convinced that the role of the business analyst facilitator is needed in an Agile Software Development Team.

The Role of the BA Facilitator

The role of the BA facilitator is to guide activities on developing both the vision and software solution. The key word here is guide. The BA facilitator role provides process to group settings and avoids participating in content. Typically, the BA facilitator role serves as the liaison between stakeholders, and the stakeholders and software development team respectively. As the liaison, the BA facilitator role uses various techniques and emotional intelligence skills to assist project sponsors and/or team leaders in accomplishing group meeting goals:

  • Facilitation Techniques for Identifying Solution Features
    • Creating a Solution Vision and Scope
      • Brainstorming – discussing of ideas
      • Brainwriting – submitting written ideas for discussion
    • Eliciting Features and Associated Business Rules
      • Focus Group Meetings – soliciting opinions
      • Joint Application Design – resolving conflicts
    • Analyzing Features – Assumptions, Constraints, Risks, and Issues
      • Root Cause – five whys, Ishikawa Diagrams
      • Force-Field – listing negative and positive influences
      • As-Is and To-Be Gap
    • Making Decisions on Features and Priorities
      • Multi-voting – subjective paring down a long feature list
      • Criteria-Based Grid – weighting feature value criteria
      • Impact/Effort Grid – comparing feature benefits versus effort
  • Emotional Intelligence Skills for interfacing with stakeholders
    • Active Listening and Paraphrasing
    • Generating Participation
    • Neutrality – focus on meeting process instead of solution content
    • Questioning – seeking answers rather than posing solutions
    • Maintaining Focus – use a parking lot and issue log for off agenda topics
    • Obtaining stakeholder feedback
    • Summarizing and synthesizing Ideas
    • Conflict intervention

Under the agile SDLC, the BA facilitator role contributes in two main activities: Continuous Vision and Scope Sessions, Iterative Software Development Meetings and Workshops.

Every project starts with a vision and scope of the solution to meet a business need. This vision may be definitive or fuzzy. However defined, the vision will reflect a prioritized set of high-level solution features that is essentially the scope of work to be done by the software development team. In the agile approach, defining the vision and scope is a continuous set of sessions. Each session represents a snap-shot of the vision and scope at that time determined by the stakeholders. These sessions manage the scope of solution features either as additions, changes and/or refinements until the stakeholders complete their vision.

These vision and scope sessions are chaired by the project sponsor. The challenge for the project sponsor is to ensure that the project vision and scope is a collaborative effort among all the stakeholders, hence the need for the BA facilitator role. The role of the BA facilitator is to assist the project sponsor by providing and executing session plans. Each vision and scope plan consists of:

  • ensuring the correct participants attend
  • accounting for meeting risks
  • arranging for an adequate facility conducive to collaboration
  • setting an appropriate agenda

This agenda contains facilitation techniques that will lead the stakeholders to a consensus on a prioritized set of high-level solution features to be pursued by the software development team. During the session, the BA facilitator role uses emotional intelligence skills to ensure that all stakeholders participate and that their ideas are respected. The BA facilitator role ensures through “questioning” that the features are justified and can be traced back to the business need. Note that all features are subject to the approval of the project sponsor – chair of the session.

Iterative Software Development Meetings and Workshops

After the initial vision and scope features are determined, the Software Development Meetings begin with a consensus on which of the prioritized set of high-level features will be developed on the first iteration. Once a finite set of features is selected and time-boxed by the software development team, then a series of follow-on status meetings are held addressing progress and the removal of impediments. Between these status meetings, the software development team holds workshops with stakeholders to develop the solution. These iterative workshops conclude with a validation meeting of the developed solution and a decision on implementation by the project sponsor. In summary,

  1. Select vision and scope features from prioritized list
  2. Develop a solution for this iteration within a time-box
    1. Conduct workshops producing prototypes
    2. Hold status meetings on progress
  3. Validate final prototype and implement with project sponsor approval
  4. Return to step one for further features and add rework as needed until feature list is exhausted

Note that with implementation, the iterative software development meetings are renewed by another selection of prioritized high-level features to address. These features may have been changed by the stakeholders in the meantime by further vision and scope sessions held in parallel with the software development meetings.

The feature selection and status meetings are chaired by a team leader similar to a project manager. In these meetings, the team leader faces the same challenge as the project sponsor – ensuring that solution development is a collaborative effort through consensus. Once again there is a need for a BA facilitator role. As in the vision and scope sessions, the role of the BA facilitator is to assist the team leader by providing a plan for each meeting and executing that plan.

The software development team is self-directed and/or self-organized. The team runs the workshops according to their skills and experience, rather than using a set plan by the team leader. The workshops are direct conversations between the software development team and the stakeholders. These workshops involve vital business and technical details in developing the solution:

  • User and system functional requirements
  • Associated business rules
  • Information needed to be managed
  • User Interface
  • Technical implementation methods

Both what needs to be developed and how it is to be implemented are discussed at the same time during the workshop. As a result of these discussions, the development team provides a solution through a series of prototypes each tested with direct stakeholder feedback. The final prototype (for this iteration) is then validated and approved by the project sponsor for implementation. A new cycle then starts with the selection of further features from the vision and scope including possible rework items….etc, etc, etc.

In the workshops, the role of the BA facilitator is different from the previous planning meetings. During the planning meetings, the BA facilitator role provided and executed an agenda. The role of the BA facilitator in the workshop is to assist the stakeholders and the software development team to determine system requirements from stated user requirements for the purpose of building prototypes. The software development team uses these prototypes to build an incremental solution.

The BA facilitator role accomplishes the above by using an expanding BA tool which includes:

  • Business Modeling Tools for identifying and analyzing user requirements, system requirements, and business rules
    • Activity Workflows with Swim Lanes – manual processes
    • Use Case – user / system dialogue – system functional requirements
    • Storyboard – user / system interface – screen flows
    • Entity-Relationship – organizing information used by the system
    • State Change – information changes as it proceeds through processes and systems
    • Class / Object – use for Object-Oriented implementations

The thoroughness with which Business Modeling is used by the BA facilitator role is tempered by the needs of the software development team. Rather than comprehensive documented requirements as in the waterfall SDLC, the BA facilitator role generates “just enough” documentation as needed by the software development team to code the prototypes.

Conclusion – Formal BA Facilitator Role “Just Ensures”

Whenever solution features are being defined, prioritized, analyzed and/or developed, the BA facilitator role is used naturally to ensure stakeholder buy-in and acceptance of the final solution. Whether it is the vision and scope sessions, the iterative software development meetings or the workshops, the BA facilitator role may be taken on by a member of the software development team. However, consider the risk involved in building a consensus with someone less trained and experienced in BA facilitation. The level of productivity and consensus is directly dependent on effective use of the BA facilitator tool set. In addition, there is a risk that the stakeholder and the developer will focus on the technical aspects of the prototype rather than requirements. It is prudent to avoid this risk. To “just ensure” the success of the team, a formal BA facilitator assisting the agile software development team needs to be that best practice.

Don’t forget to leave your comments below

Mark A. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF). Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

This article first ran in the IIBA newsletter February 2009.

Business Analysis Benchmark – The Path to Success

Written by Keith Ellis on . Posted in Articles.

The Business Analysis Benchmark is a large scale survey effort designed to assess the link between an organization’s maturity in requirements definition and management and project outcome. This year’s theme is The Path to Success; the study presents detailed findings on the impact of business requirements maturity and analyzes the strategies and tactics needed to implement enhanced requirements maturity.

“This survey is a testament to the need for investing in your requirements process to deliver value to your stakeholders.”
Scott Hebner, Vice President Marketing and Strategy, IBM Rational Software

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. Using this approach, the report found:

  • Requirements maturity improvement is highly correlated with improvement in development effectiveness.
  • Requirements maturity cannot be changed through continuous focus on only one underlying capability.
  • High requirements maturity companies can be found amongst the followers of many different approaches to development such as Agile, Iterative, Plan Driven (Waterfall),and Prototyping/Visualization centric methods.

The above findings validate the Requirements Maturity Model as a mechanism for identifying the impact of poor requirements practices on companies, quantifying the performance change expected for a particular organization’s situation, and, diagnosing the changes needed should a company choose to pursue a path of improvement. This report identifies both the strategy and tactics of enhancing requirements definition and management maturity. The statistics presented in the Business Analysis Benchmark not only debunk a number of commonly held beliefs about development effectiveness, they show that the average organization wastes a large proportion of its IT development budget due to poor requirements maturity. To be clear, 75% of organizations surveyed waste over one in three dollars spent in IT development and implementation annually as a result of to poor requirements maturity. These findings detail key issues and actions needed to recapture this wastage.

Key Findings of the Business Analysis Benchmark include:

  1. Requirements maturity has a strong positive correlation to EVERY major measure of development efficiency assessed. On-time performance, on-budget performance, on function performance,

    “This [report] was extremely helpful to me, not only to understand the findings relating to my current situation, but also what CEO and CIOs are interested in.”
    Carol Deutschlander,
    Home Hardware Stores Limited

    overrun magnitudes for each of the above, and project success rates all improve as requirements maturity increases. On average, performance virtually doubled on each of these metrics as organizations progressed from using an ad-hoc approach for requirements definition and management to having institutionalized and consistent competency in all capability areas.

    • Average on-time performance of technology projects increased by 161%.
    • Time overruns on projects reduced by 87%.
    • Average on-budget performance for technology projects improved by just over 95%.
    • Budget overruns reduced by just under 75%.
    • Percentage of projects that deliver the functionality needed by the business rose by just over 75%.
    • Average functionality missed dropped by approximately 78%.
  2. A total of 74.1 per cent of survey respondents were classified as immature Level 1 or Level 2 organizations (where the highest maturity Level is 5). These organizations waste 39% and 34% respectively of their development budget due to poor requirements definition and management maturity. This wastage, due to poor requirements maturity, will increase to over 50% of IT spending on development and a significant proportion of the maintenance budget in certain circumstances.
  3. Poor requirements definition and management maturity undermine organizational competitiveness. Organizations with poor requirements maturity expend far more time, budget, and management effort to achieve the same results as organizations with high maturity. For example, organizations with low requirements maturity achieve the business objectives of a project initiative a mere 54% of the time while taking 35% more time to achieve this poorer result. This impact may be so significant over time that it shifts fundamental financial performance metrics such as Return on Assets (ROA).It was found that Level 4 companies, on average, outperform the ROA of their peer group competitors by 10%.
  4. While this report discusses and busted a number of commonly held beliefs about requirements and development efficiency, two issues garnered significant attention and support from the report’s external review panel:

CIO’s cannot simply attempt to hire great analysts and expect the problem of poor requirements to go away. In fact, lower skilled people in a high requirements maturity company significantly outperform highly skilled people in a low requirements maturity company.

“I’ve worked carefully through the Benchmark Study. It’s terrific stuff — some of the conclusions are almost iconoclastic, and yet they make tremendous sense once you analyze them. And the RMM is an excellent tool — of course it does and should heavily parallel CMM / CMMI, but it also provides tremendous value added as you’ve applied/customized it to Business Analysis practice.”Senior Requirements Specialist Major Property & Casualty Insurance Company

Agile, Waterfall, Iterative, Prototyping/Visualization have immaterial performance differences for any given level of requirements definition and management maturity. There is a raging debate amongst development methodologists, each espousing one method over another. This study finds that changing development methods – in the absence of also improving requirements competence in the areas of process, techniques, staff, technology, organization and deliverables – only nominally improved or reduced overall success rates on projects. Excellent results have been achieved with all these approaches, and the findings of the Business Analysis Benchmark do not endorse any one method over another. The key issue for readers: the overall level of requirements maturity has a MUCH greater effect on project outcome than the development method selected.

The Business Analysis Benchmark describes the issues and impacts of each level of the organization, and the role each plays in moving a company forward along the path of maturity. This report has a preface that describes the survey, maturity model, and basic facts surrounding the impact of requirements maturity on project outcome. The remainder of the report is organized along the lines of a readership group, discussing the key findings as they relate to:

  1. The CEO: how does requirements maturity impact overall organizational competitiveness?
  2. The CIO: how does IT Leadership approach the major issues in making requirements definition and management change?
  3. The PM and BA Leadership: what is the effectiveness of various paths of change, and what are the required activities to bring improvement? In addition to this content, IAG has also asked a series of external reviewers to comment on survey findings. Some of these insights are captured in the call-out boxes in this article.

The Survey – How it was Conducted

Last year, over 22 million business and IT professionals in 80 countries, and using 10 languages, benefited from the statistics generated by the Business Analysis Benchmark.

This year’s survey theme – The Path to Success – identifies a roadmap for maturing requirements definition and management practices. This study is about getting repeatable success on strategic IT projects.

In Q2 of 2009, just under 550 companies chose to participate in the Business Analysis Benchmark – Path to Success survey, leading to 437 qualifying responses. This survey was designed with the intent of assessing the link between an organization’s maturity in requirements definition and management and project outcomes. The Business Analysis Benchmark statistics only include respondents that met the following three criteria:

  1. The company spends over $1 million annually in application development (net of hardware) or software implementation.
  2. The individual must have experience with business requirements and project management where net new functionality is added to the business.
  3. The company must have run at least four projects in excess of $250,000 in the last 12 months.

These criteria ensured that only experienced professionals with knowledge of requirements definition and management issues would be included in survey results. The results are weighted toward medium and large sized commercial companies, in North America. The sampling is summarized below:

Position

Executive: Head of IT, CIO, Head of Development, Line of Business Executive
Head of PMO or Project Manager
Head of Business Analysis Competency Center or BA
Other

Number of Employees in Company

1‐99
100 to 499
500 to 2,499
2,500 to 4,999
5,000 to 9,999
10,000+


Industry

Energy, Resources & Utilities
Financial Services
Insurance
Government & Social Services
Healthcare & Pharmaceutical
Manufacturing
Media & Industry Analysts
Military & Defense
Professional & IT Services
Retail, Transportation & Distribution
Software
Telecommunications
Education
Other


Region

United States
Canada
Western & Eastern Europe
India/Pakistan
Asia/Pacific
Africa (mainly South Africa)
Middle East
Central/South America
Total

% Respondents

12.2%
27.1%
52.5%
8.3%
100.0%

% Respondents

6.2%
14.3%
20.3%
11.5%
8.5%
39.2%
100.0%

% Respondents

3.9%
17.7%
9.9%
8.7%
8.0%
6.0%
1.1%
1.4%
14.4%
5.0%
9.2%
6.7%
2.1%
6.0%
100.0%

# Respondents

233
116
26
24
22
6
5
5
437

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) – and author of the Business Analysis Benchmark – where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector.

For access to and to download your free copy of the full Business Analysis Benchmark study, please click on www.iag.biz.