Across North America, businesses in all sectors are adopting standard development methodologies to turn out a higher quality of goods and services. The tried and true approaches that have yielded such great results for competitors are heralded as best practices. But here is the sad news: no one methodology fits all. In fact, different methodologies are appropriate in fitting diverse projects. Some projects are so unique, future-thinking Business Analysts (BAs) are finding that the adoption of new hybrid concepts is the only smart way to go in problem solving tomorrow’s projects.
The word ‘fresh’ describes that feeling of turning over a new leaf when January 1 rolls around each year – and the sentiment we as individuals strive to maintain all year long when we set New Year’s resolutions. Much in the same vein as these annual goals, BAs seeking an innovative means by which they can see their requirements come to fruition are increasingly interested in the study of the existing methods that are in place within the industry, as well as fresh methods established through modeling and fusion.
Defining Goals: What are RUP and Agile?
Before moving forward in adopting an emerging approach to requirements assessment, it’s essential to first review and comprehend the existing practices currently in place. The limitation of what each standard methodology can and cannot do is critical, much like the days within a month and months within a year. It is important for businesses defining application requirements to always recall the scope and consistency roles of each of the following standard methodologies:
1. The most fundamental discipline of IT project management is the Rational Unified Process® (RUP®), developed by IBM and described as “a flexible software development process platform. Through its configurable architecture, RUP enables you to select and deploy only the process components you need for each stage of each project” (www.ibm.com). In essence, RUP is an adaptable process framework tailored by software project teams that selects process elements appropriate for specific needs. Driven by its process elements, RUP is typically deployed in large-scale implementations and among project teams of 150+ players. Furthermore, it’s a very formal and well-documented process that demands an extremely high level of detail and documentation. In this structured scenario, stakeholders are often less frequently involved in the process of developing requirements.
2. In comparison is the Agile Unified Process, a subcategory of the larger Agile Methodology, which is basically a simplified version of RUP. As defined by Scott W. Ambler, one of several key experts in this area, the process describes a “simple, easy to understand approach to developing business application software using agile techniques and concepts, yet still remaining true to the RUP” (www.ambysoft.com). In basic terms, Agile is the IT project manager’s creative bone because its conceptual framework promotes development iterations throughout the project’s life cycle. Relatively young – just formalized in 2001 – Agile methods emphasize face-to-face communication over written documentation and are typically associated with low-risk projects. The process is usually deployed within medium- to large-sized projects where formality, structure and rigor are not required. Exercised by smaller project teams, stakeholders are more frequently involved at the heart of the dynamic process.
Type of Resolution…Type of Channel
Another way to measure choices in requirements gathering is by grouping approaches. Just as there are different types of New Year’s resolutions (long term, short term, etc.), there are different types of BA methodologies. Generally speaking, there are four major categories of methodologies on the landscape:
- Normative, when one works through a sequence of events that is often described as a start/stop technique. In the world of software development verification of a finite number of “states”, transitions and actions are closely examined using a state diagram.
- Participative, where stakeholders are directly involved in order to capture the essence of how a stakeholder might interact within a given environment.
- Heuristic, a method for helping in the solving of a problem, commonly informal. It is particularly used for a method that often rapidly leads to a solution that is usually reasonably close to the best-possible answer.
- Rational, a set of methods or techniques that are structured, as defined above, typically best suited for system analysis and engineering environments.
By understanding each of these choices, requirements gatherers can clearly set their stage organizationally.
Elements of a Pledge: The Critical Components of BA Methodologies
Then, the next step is to understand the critical components within each methodology. In analogy, before any thoughtful individual sets her New Year’s resolutions, she contemplates different areas of her life (perhaps professional, family and spiritual buckets, for example). Similarly, before selecting, adopting or building a business analysis methodology for any given project, organizations need to consider three key components: people, process and tools.
1. People – Business analysts should ask the following types of questions when regarding staff:
-
- What teams will be involved in the development of a solution?
- What will be the dichotomy and size of the given teams?
- What sort of skills are required?
As an example of the type of assessment that may be made within this checklist, someone who is able to focus on a task-at-hand would serve as an excellent facilitator in the Agile model, while a “Type A” personality would not perform as well in the same environment. Access to stakeholders and their involvement in the project is also a major consideration, especially if the stakeholders take a “hands-on” approach.
2. Process – In analysis of this component, questions might be:
-
- What necessary activities must I conduct in order to execute against my deliverables?
- What are the differences between formal and informal approaches?
- What rigors are needed to monitor the project?
- What, if any, quality standards are required?
- Are standards like Six Sigma or Sarbanes-Oxley Compliance a constraint?
For example, compare the processes of a Customer Relationship Management (CRM) project with the launch of the next space shuttle. The structure and rigor of the two are clearly different, and Agile might be better for CRM whereas RUP may be more appropriate for the shuttle launch. There may even exist the opportunity for a two- pronged approach, allowing for a creative or heuristic type of methodology. In the case of the space shuttle example, this approach might help space travelers reach a galaxy beyond Mars! However, quality matters when developing a process, and these stated process requirements are not necessarily a catch all.
3. Tools – These are the standards and techniques upon which the determined tactic will rely. Ask of yourself:
-
- What is my budget for tools?
- Are they already available within the environment?
- If so, what is the condition?
- Is training required?
Tools are important to developing decision making, but should be the third element in line. Once you understand the people and process, then the tools plug in very naturally. As well, for both the tool and process functions, regardless of the methodology, sophisticated BAs should be well versed in fundamental BA activities as cited by the International Institute of Business Analysis™ (IIBA™) Business Analysis Body of Knowledge (BABOK™). BAs’ skills should be “portable” regardless of the selected methodology.
When BAs decompose each of these individual components and understand these concepts, they paint a picture of which design is most important. Remember, don’t put the cart before the horse, just as you wouldn’t let January 1 pass without identifying how you will achieve your resolutions. It’s essential to identify what is going to be built and the people and tools involved, as well as the best course of action for process implementation, before selecting a BA methodology.
An Amalgamation of Ambition: Developing One’s Own Hybrid Approach
After a careful consideration of the definitions, components and benefits of BA process models, a requirements developer can then determine what course of action is most appropriate given the circumstances: one or the other of the standard schemes, a combination of RUP and Agile, or an entirely new methodology all together? Much like a standard New Year’s resolution like “lose weight”, one size doesn’t fit all. The customary approaches certainly are not cookie cutter, and it’s recommended they be watchfully weighed.
Say in such an analysis, the BA feels strongly compelled to build a hybrid methodology. Where might she begin? The following itemizes a checklist of requirements a BA should consider when building a hybrid methodology:
- Amount of detail required, i.e. the tolerance or criticality of the product to the organization. If this project fails, will the company go bankrupt?
- Size of the problem. Does it comprise the entire organization or simply one business unit? Going back to the previous analogy, aspiring to explore a universe beyond Mars is clearly much bigger in size than that of creating reports for a CRM system.
- Size of the project, in terms of number of people involved rather than measured by financial implications. Is this a situation where subject matter experts from across the organization must be involved? Can developers and stakeholders manage to independently produce a solution?
- Complexity and precision. Is a workflow modeling diagram or code documentation for standards requirements needed or not? What level of accuracy is present?
- Scale. Is the sum of the parts equal to the whole (e.g. are these large components across the entire organization or scores of smaller pieces)?
- Type of solution, as well as its stability. Will it change once developed or at some point during development?
After considering such a checklist, here’s a new and creative specific manner in which Business Analysis can concurrently interact with RUP and Agile methodologies. One might call such a hybrid “Ragile”. This emerging hybrid theory integrates the components of RUP’s discipline and Agile’s creativity. The combination of both is converted into a powerful opportunity.
Business analysts’ distinct function would play a role in Ragile, or any other selected methodology, as the key goal is to ensure a product or service with the desired level of quality within scope and budget. BAs would be able to select which methodology is more appropriate for a given solution in conjunction with the project manager because of the potential impact on the overall project life cycle. The BA executing against a budding Ragile methodology would need to possess quite a diverse skill set, as well as administer both standard facilitation techniques and the aptitude for adaptability between little or no involvement and extreme engagement. Ragile might be one new crossbreed, but upon a thorough review and comprehension of the components described, a sophisticated, educated and well-versed requirements gatherer can develop his own hybrid methodology. Doing so should not be undertaken lightly, as an extreme amount of care and consideration must be given to all the environmental variables listed above.
In closing, it cannot go unstated or overemphasized that although this article provides a checklist of options and opportunities, one standard does not fit all projects, and there is always an occasion to select and develop a new methodology. Requirements developers who intend to integrate standard business analysis methodologies and develop new hybrids for technology-focused projects need only dissect and consider some of the themes described here, and they are off to a fresh and innovative new manner of doing business.
Author: Glenn Brûlé, Director of Client Solutions for ESI International, has more than 18 years of experience in many facets of business, including project management, business analysis, software design and facilitation. He is former Chair of International Business Development for the IIBA, and is a frequent speaker at professional association meetings and conferences around the world, including ProjectWorld/World Congress for Business Analysts and IIBA events. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. Glenn's background as an educator, communicator and business consultant has served him well through his many client engagements across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.
Glenn has authored numerous articles on business analysis and was instrumental in the development of two ESI white papers: “Eight Things Your Business Analysts Need to Know – A Practical Approach to Building and Improving Competencies” and “Establishing and Maturing a Business Analysis Centre of Excellence – the Essential Guide.”