Author: Cynthia Low

Harness the Power of the PM/BA Partnership

Written by Cynthia Low on February 17, 2009. Posted in Articles. 1 Comment on Harness the Power of the PM/BA Partnership

Projects play an essential role in the growth and survival of organizations today. It is through projects that we create value in the form of improved business processes and new products and services in response to changes in the business environment. Since data and information are the lifeblood of virtually all business practices, projects with significant IT components are often the key mechanism used to turn an organization’s vision and strategy into reality. Executives have their eye on the project portfolio to ensure that they: (1) invest in the right mix of projects, (2) optimize their resources, (3) develop expert capabilities to deliver flawlessly, and ultimately, (4) capture the expected added value to the business. In the 21^stcentury we are bombarded with constant change brought about by the Internet, the global economy and the prevalent use of technology. As a result, there appears to be a never-ending demand for new business solutions supported by IT products and services. Executives across the spectrum are adopting the practices of superior project management and business analysis to increase the value projects bring to their organizations.

The Project Performance Partnership

In the spirit of high-performing teams, project managers align themselves with professional business analysts, expert technologists, and business visionaries to understand business problems or new opportunities, and determine the most appropriate, cost-effective, fastest time to market, and innovative solutions. As this core team forms, a project performance partnership emerges that rivals the world’s great teams, (e.g., tiger teams, special operations teams, professional sports teams, parametric teams). At the center of the team is the dynamic twosome: the project manager and the business analyst. The project manager keeps an eye on the management of the project, ensuring the project delivers on time, on budget and with the full scope of the requirements met. While the business analyst focuses on management of the business need, business requirements, and expected business benefits. The wise project manager welcomes this teaming trend, understanding that inadequate information relating to business needs leads to poor estimates, and makes time and cost management virtually impossible.

Business analysis and project management have become central business management competencies of the 21^st century. These competencies are essential because requirements play a vital role in engineering business solutions, and projects are essential to organizational success. In addition, organizations are realizing that the reasons projects fail are almost always tied to poor requirements and ineffective project management. (The Standish Group International, 1994-2006). The table below depicts the resolution of 30,000 applications projects in large, medium, and small cross-industry U.S. companies tested by the Standish Group from 1994 to 2006.¹³

Year	Successful Projects	Failed Projects	Challenged Projects
2006	35%	19%	46%
2004	29%	18%	53%
2000	28%	23%	49%
1998	26%	28%	44%
1996	27%	40%	33%
1994	16%	31%	53%

Source: The Standish Group Project Resolution History, CHAOS Research Reports (1994–2006)

Clearly there has been a steady improvement in project performance since 1994. According to the Standish reports, the reasons for the overall improvement include: smaller projects (the average cost of a project had been downsized more than half by 2001); better skilled project managers; and better methods and tools to manage changes. The Standish Group continues to recommend minimizing project scope, reducing project resources, and downsizing timelines to improve project success. The Standish Group also predicts that the number of critical projects wills double each year; therefore, we must continue to work vigilantly to improve project performance, paying particular attention to the elements it calls the Recipe for Project Success: The CHAOS Ten, which are listed here grouped by category. Notice that many of these elements relate to business analysis and the remaining are about better project management.

Recipe for Project Success: The CHAOS Ten

Project Management	Business Analysis
Executive support Experienced project managers Standard infrastructure Formal methodology Reliable estimates Small milestones, proper planning, and competent staff	User involvement Clear business objectives Minimized scope Firm basic requirements

It is the project manager who owns the Business Solution Life Cycle, and the business analyst who owns the Systems Requirements Life Cycle, from understanding the business need to ensuring that the delivered solution meets the need and adds value to the bottom line. (See Figure 1, below) For complex 21^stcentury projects, the business analyst has a critical role throughout the Business Solution Development Life Cycle, not simply during the requirements phase. Business requirements analysis differs from traditional information systems analysis because of its focus, which is exclusively on adding value to the business. In particular, project managers rely on business analysts to assist in providing more detailed project objectives; business needs analysis; clear, structured, useable requirements; trade-off analysis; requirement feasibility and risk analysis; and cost-benefit analysis. Poor requirements definition emerges without this key liaison between business and IT departments, resulting in a disconnect between what IT builds and what the business needs.

Figure 1 – Business Solutions Life Cycle Mapped to the Systems Requirement Life Cycle

Combining Disciplines Leads To Success

For organizations to achieve strategies through projects, a strong partnership between the project manager and the business analyst is essential. Indeed, when this partnership exists, and they both embrace the contributions of expert technologists and business visionaries, collaboration, innovation and far superior project performance is realized. For an in-depth discussion of the project manager and business analyst partnership, it is helpful to frame the dialogue in the context of a generic project cycle. Refer to Figure 1 once again, the Business Solution Life Cycle Mapped to the Systems Requirements Life Cycle, to provide context as we examine the nature of the partnership. The diagram shows a sequential development approach, from strategic planning to the business requirements to the delivery of a complete business solution. This is a simplistic model that guides the development process through its typical phases.

Strategic Planning and Enterprise Analysis

Strategic Planning

Strategic planning is the first phase in the Business Solution Life Cycle. During this phase the current state of an enterprise is examined and the desired future state is determined and described by a set of broad goals. The goals are then converted to measurable objectives designed to achieve the strategy.

Project managers and business analysts may not contribute directly to strategic planning activities since it is the responsibility of the senior leadership team. However, senior business analysts and project managers may be asked to conduct market research, benchmark studies or competitive analysis surveys to inform the executive team as input to the strategic planning process. In some organizations, senior business analysts and project managers help plan and facilitate strategic planning sessions. Nevertheless, business analysts and project managers should have a full understanding of the strategic direction of the enterprise to determine how new initiatives fit into the long term strategy and/or mission of the organization, and to help build and manage the business case and other relevant information regarding business opportunities.

Enterprise Analysis

The enterprise analysis phase of the Business Solution Life Cycle consists of the collection of activities for depicting the current and future views of the business to determine the gap in organizational capabilities needed to achieve the business strategies. Enterprise analysis activities then determine new business opportunities to close the gaps.

Enterprise analysis activities begin after the executive team of the organization develops strategic plans and goals. The core activities center on: (1) identifying new business opportunities or solutions to business problems, (2) conducting studies, gathering information and determining the solution approach, (3) developing a business case or project proposal document to recommend a new project to the leadership team for their decision whether to select, prioritize and fund a new project. If the new change initiative is selected, a new project is formed and requirements elicitation and project planning commence.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the enterprise analysis activities.

Deliverables	Description
Business Architecture	The business architecture is the set of artifacts that comprise the documentation about the business.
Feasibility, Benchmark, Competitive Studies	Conducting formal or informal studies prior to proposing a new project helps to discover very important information about the business opportunity.
New Business Opportunities	As an outgrowth of strategic planning, the business analyst and project manager review the results of feasibility, benchmark and competitive analysis studies, and the target business architecture to identify potential solution alternatives to achieve strategic goals.
Business Case	A business case should be developed for all significant change initiatives and capital projects.
Initial Risk Assessment	Once the business case is developed, the project manager and business analyst facilitate a risk management session using the same set of experts.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration to complete the enterprise analysis activities, including:

Conducting feasibility, benchmark and competitive studies
Creating the business case, scope statements, preliminary time and cost estimates
Conducting risk assessment and risk response planning
Establishing project priorities
Managing stakeholders
Getting the right people involved and excited about the potential project
Partnering with senior IT architecture team to create the solution’s “vision”

Requirements and Design

During the requirements and early design phases the business need is discovered, analyzed, documented and validated and the solution concept begins to come into view.

Requirements Elicitation

Requirements are always unclear at the beginning of a project. It is through the process of progressive elaboration that requirements evolve into maturity. Requirements elicitation involves conducting initial requirements gathering sessions with customers, users, and stakeholders to begin the specification process. Requirements gathering techniques include: discovery sessions and workshops, interviews, surveys, prototyping, review of existing system and business documents, and note taking and feedback loops to customers, users, and stakeholders.

Requirements Analysis

Requirements are first stated in simple terms, and are then analyzed and decomposed for clarity. Requirements analysis is the process of structuring requirements information into various categories, evaluating requirements for selected qualities, representing requirements in different forms, deriving detailed requirements from high-level requirements, and negotiating priorities. Requirements analysis also includes the activities to determine required function and performance characteristics, the context of implementation, stakeholder constraints, measures of effectiveness, and validation criteria. Through the analysis process, requirements are decomposed and captured in a combination of textual and graphical formats. Analysis activities include:

Studying requirements feasibility to determine if the requirement is viable technically, operationally, and economically
Trading off requirements to determine the most feasible requirement alternatives
Assessing requirements feasibility by analyzingrequirement risks and constraints and modifying requirements to mitigate identified risks. The goal is to reduce requirement risks through early validation prototyping techniques
Modeling requirements to restate and clarify them. Modeling is accomplished at the appropriate usage, process, or detailed structural level
Deriving additional requirements as more is learned about the business need
Prioritizing requirements to reflect the fact that not all requirements are of equal value to the business. Prioritization may be delineated in terms of critical, high, average, and low priority. Prioritization is essential to determine the level of effort, budget, and time required to provide the highest priority functionality first. Then, perhaps, lower priority needs can be addressed in a later release of the system.

Requirements Specification

Requirement specifications are elaborated from and linked to the structured requirements, providing a repository of requirements with a completed attribute set. Through this process of progressive elaboration, the requirements team often detects areas that are not defined in sufficient detail, which, unless addressed, can lead to uncontrolled changes to requirements. Specification activities involve identifying all the precise attributes of each requirement. The system specification document or database is an output of the requirements analysis process.

Requirements Documentation

Requirements documentation must be clear and concise since it is used by virtually everyone in the project. Transforming graphical requirements into textual form can make them more understandable to non-technical members of the team. Documentation activities involve translating the collective requirements into written requirements specifications and models in terms that are understood by all stakeholders.

Requirements Validation

Requirements validation is the process of evaluating requirement documents, models, and attributes to determine whether they satisfy the business needs and are complete enough that the project team can commence work on solution design and construction. The set of requirements is compared to the original initiating documents (business case, project charter, statement of work) to ensure completeness. Beyond establishing completeness, validation activities include evaluating requirements to ensure that design risks associated with the requirements are minimized before further investment is made in solution development.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the requirement deliverables:

Deliverables	Description
Stakeholder analysis and communication needs	Interviews are conducted with individuals and small groups to find out what business functions must be supported by the new solution.
Elicitation Workshops	Requirements workshops are an efficient way to gather information about the business need from a diverse group of stakeholders.
Surveys	Surveys can provide a valuable tool to collect a large amount of information from an array of stakeholders efficiently and quickly.
Document Reviews	The business analyst and project manager review all existing documentation about the business system, including policies, rules, procedures, regulations, process descriptions.
Test Plan	Typically a document that describes the scope, approach, resources and timing of test activities.
Business Requirements Documentation and Validation	Structured, validated, archived and accessible requirements are the functional and performance needs for the new solution, captured in: documents, tables and matrices, models, graphics, prototypes
Requirements Management Plan	A document that describes how changes to requirements will be allocated, traced and managed.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during requirements activities, including:

Conducting requirements elicitation workshops
Determining the number of iterations of requirements elicitation, specification, and validation
Determining the appropriate life cycle choice (e.g., waterfall, Agile, Spiral)
Developing the project management plan
Conducting trade off analysis for the requirements and solution trade-offs
Balancing the competing demands
Validating requirements
Prototyping
Updating the business case
Planning and facilitating the control gate review, signoff on requirements, and go/no decisions

Solution Construction and Test

During the solution construction and testing, the business analyst and project manager collaborate to ensure changes to requirements are identified, specified, analyzed for impacts to the project (cost, schedule, business value add), and dispositioned appropriately. The goal for both the business analyst and the project manager is to reduce the cost of changes, and welcome changes that add business value. Requirements management activities include: allocating requirements to solution components, tracing requirements throughout system design and development, and managing changes to requirements.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the solution construction and test activities.

Deliverables	Description
Solution Verification and Validation	Validating requirements to provide evidence that the designed solution satisfies the requirements through user involvement in testing, demonstration, and inspection techniques. The final validation step is the user acceptance testing. Verifying requirements to provide evidence that the designed solution satisfies the requirements specification through test, inspection, demonstration, and/or analysis.
Business Policies, Procedures, Rules, Education	For new business solutions, there are almost always changes to business rules, policies, and procedures.
Testing	Including integration, system, and user acceptance testing.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during solution construction and testing phases including:

Developing the test plan and test approach
Validating activities to ensure the solution meets the business requirements (customer reviews, product demonstrations)
Reviewing test results and dispositioning identified defects
Conducting defect root cause analysis and determining the appropriate corrective action
Managing issues
Managing stakeholders
Facilitating the go/no go decision to deliver

Solution Delivery

Planning for the organizational change management that is brought about by the delivery of a new business solution is often partially or even completely overlooked by project teams that are focused mainly on the IT application system. While the technical members of the project team plan and support the implementation of the new application system into the IT environment, the business analyst and project manager are working with the business unit management to bring about the benefits expected from the new business solution by:

Assessing the organizational readiness for change, and planning and supporting a cultural change program;
Assessing the current state of the knowledge and skills resident within the business, determining the knowledge and skills needed to optimize the new business solution, and planning for and supporting the training, retooling and staff acquisition for skill gaps;
Assessing the current state of the organizational structure within the business domain, determining the organizational structure needed to optimize the new business solution, and planning for and supporting the organizational restructuring;
Developing and implement a robust communication campaign to support the organizational change initiative; and
Determining, enlisting and supporting managements’ role in the championing the change.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the solution deployment activities.

Deliverables	Description
Deployment plans	Developing and communicating the plans to implement the new business solution.
Business policies, rules, procedures	Implementation of business policies, procedures, rules, etc.
Education and training	Training of business customers, stakeholders and users to accept and operate the new business solution efficiently.
Post-implementation support	The business analyst and project manager provide support to the business customers, stakeholders and users to help them learn how to operate the new business solution efficiently, and to resolve any issues that arise.
Lessons learned	The business analyst and project manager conduct lessons learned sessions with the project team, the business customers, stakeholders and users, and the technical team to determine what went well, and what needs improvement for future projects.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during solution deployment activities including:

Developing, communicating, and getting approval for the deployment plan
Approach (deploy to all business units or use a phased in)
- Which business units are affected?
- When will the business units be implemented?
- When will training be delivered?
- When will post-implementation support by the core project team end?
Making the decision to move to O&M
Conducting lessons learned sessions

Operations and Maintenance

The business analyst and project manager contribution to the success of the project does not end when the business solution is delivered and operational. There are key responsibilities during Operations and Maintenance (O&M) that must be filled. O&M is the phase in which the system is operated and maintained for the benefit of the business. Maintenance services are provided to prevent and correct defects in the business solution.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the O&M phase.

Deliverables	Description
Solution benefits measurement	The actual business benefits that are realized are captured, analyzed and communicated.
Identification, prioritization, and planning for solution enhancements	Maintenance and enhancements projects are: identified, prioritized by business value, planned, executed
Decision to deactivate	At some point, the solution will need to be replaced. The decision to do so often involves the enterprise analysis activities described above.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during O&M including:

Prioritization of enhancements
Root cause analysis of performance and value attainment issues

Final Words

Gaps in technology, techniques, and tools are not the fundamental reasons why projects fail. Rather, project failure most often stems from a lack of leadership and poor choices made by people. Undeniably, the business analyst and project manager are evolving into strategic project leaders of the future. The key issues are no longer centered on control and management, but rather collaboration, consensus, and leadership. Team leaders develop specialized skills that are used to build high-performing teams. When building software-intensive systems, well managed teams undoubtedly accomplish more work in less time than do poorly managed teams (Bechtold, 1999).

References

Bechtold, R. (1999). Essentials of software project management. Vienna, VA: Management Concepts.
Hadden, R. (2003). Leading culture change in your software organization. Vienna, VA: Management Concepts.
Mooz, H., Forsberg, K., & Cotterman, H. (2003). Communicating project management: The integrated vocabulary of project management and systems engineering. Hoboken, NJ: John Wiley and Sons.
The Standish Group International, Inc., “2007 First Quarter Research Report,” The Standish Group International, Inc. (2006–2007).
The Standish Group International, Inc., “Extreme CHOAS,” The Standish Group International, Inc. (2001), Online at http://www.smallfootprint.com/Portals/0/Standish%20Group%20-%20Extreme%20Chaos%202001.pdf (accessed January 2008).
Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems engineering: Coping with complexity. Indianapolis, IN: Pearson Education, Prentice Hall PTR.

Kathleen B. Hass, PMP

is Senior Practice Consultant for Project Management and Business Analysis, and Director at Large and Chapter Governance Committee chair for the International Institute of Business Analysis (http://www.theiiba.org/). She is the author of Managing Complex Projects: A New Model (Management Concepts, October 2008). Since 1973, Management Concepts, headquartered in Vienna, VA, has been a global provider of training, consulting and publications in leadership and management development. Management Concepts is a Gold International Sponsor and an IIBA Endorsed Education Provider For more information, visit http://www.managementconcepts.com/ or call 703 790-9595.

Seven Tips for Managing Your Online Reputation

Written by Cynthia Low on February 10, 2009. Posted in Articles.

In a competitive job market, a polished professional reputation can make or break someone’s chances of landing a coveted position. And since the word google became a verb, that reputation includes information that can be found online. This is particularly true for IT professionals who are evaluated on their technical savvy.

As a growing number of employers search the Internet for information about job seekers, it’s become more important for applicants to actively monitor and maintain their professional reputations online. The current economic environment has made hiring managers increasingly cautious, and any information that raises a red flag can quickly take candidates out of consideration for a job.

Following are seven practical tips to help you manage your digital imprint

Take stock. Discover what information about you — if any — already is online by performing a search using popular search engines. If you discover an item that you wouldn’t want hiring managers to see, ask the person who posted the information or website administrator to remove it. Similarly, untag any inappropriate photos of yourself.
Activate privacy settings. If you belong to social networking sites or have a personal blog, adjust your privacy settings so you control who has access.
Exercise discretion. When interacting online, be selective about which venues you participate in and who you allow into your personal and professional networks. If you regularly contribute to blogs or forums, give thought as to how your statements may be interpreted by those outside your community. Consider using a pseudonym if you wouldn’t want a potential employer to see your posts. You can use BlogPulse or Technorati to track online conversations about you or your sites.
Network wisely. When using professional networking sites such as LinkedIn to look for job opportunities, behave graciously with everyone you encounter and follow posted protocols. Thank anyone who assists you, and be sure to return the favor when possible.
Stack the deck. Business information websites such as ZoomInfo allow users to post information about themselves, so consider including details about your professional involvement and qualifications on these types of forums.
Share your insights. Posting useful advice and commentary on industry forums and authoring online articles in your area of expertise can add to your credibility.
Monitor the conversation. Set alerts using Google or other tracking services under your name so you receive an e-mail notification every time something new is said about you online.

Professionals should always post prudently — not just when they’re looking for work. The business world is more transparent than ever, which means people need to be aware that what they say and do online can have both positive and negative consequences.

Dave Wilmer is Executive Director of Robert Half Technology, a leading provider of information technology professionals. Robert Half Technology offers online job search services at www.rht.com. For additional tips on conducting an online job search, download a free copy of Search Smarts: Best Practices for Conducting an Online Job Search at http://www.rhi.com/onlinejobsearch.

Why Agile?

Written by Cynthia Low on February 3, 2009. Posted in Articles.

What’s so Great about Agility?

The Agile approach to managing software projects has been getting a lot of play recently. Why are people talking about it so much? Is this just the latest “new thing”? Or is there some real value to it?

“Agile,” as a set of software development methods, was defined seven years ago, so the “flash in the pan” would have burned itself out long ago. The fact is that more and more organizations (from small shops to large corporations) are finding real value in Agility.

After defining what Agility is and is not, we will look at the value it can bring.

What is Agility?

The Agile approach has a number or key attributes that can be referred to as the “Essence of Agility.” They are:

Learning and adaptation – Traditional approaches expect that we can foresee how the project will unfold with reasonable precision. The Agile approach accepts that there are many things we cannot anticipate, so it is structured to allow us to first learn about those unknowns and then adapt to what we learn.
Collaboration – The Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customers.
Customer focus – The customer is the central focus of an Agile project and is actively involved throughout.
Small self-directed teams – Agility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.
Lean principles – The principles that have been proven by Lean Manufacturing are embodied in Agility, especially concepts like “Just Enough” and “Just in Time.”
Progressive requirements elaboration – We expect to learn about the system requirements as the project progresses, so trying to nail them down in a full-blown specification at the beginning of the project doesn’t make sense. Agile projects establish a roadmap and elaborate the details as they are needed.
Incremental delivery – The best way to ensure we are building the right system is to regularly get feedback from our customer. Agility always includes incremental delivery of the product to the customer – at least for acceptance testing.
Iterative planning and adaptation – Agile projects place a high value on planning. They engage in planning at various levels of detail and engage in it regularly. Again, this is driven by the fact that we cannot foresee everything that is important, so we must adapt our plans as we learn.

What is Agility Not?

Many people have abused the term “Agility” by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:

No documentation – The documentation that an Agile project produces is significantly different from what traditional projects produce, and an Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.
No planning – Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day’s work.
No requirements – The Agile team’s Product Owner (customer) defines a Product Vision, and they work together to document the product’s high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.
No schedule or budget control – Agile projects always operate within a “Time-Box.” That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people’s time is the largest part of a software project’s budget, the time-box limits the project budget as well. The Agile mantra is, “We will deliver the greatest possible customer value within the project constraints!”
Programmers doing whatever they like – The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team’s only role is to estimate what can be done in limited timeframes. The team’s customer determines how that effort will be directed.

The Value of Agility

There are many reasons why companies find the Agile approach (when it is implemented as intended) to provide value. The value that is cited usually includes:

The right product – The customer is continuously involved in the project, ensuring that valuable software is being built and prioritizing the work. In addition, the customer accepts or provides critical feedback on each increment of the product that is produced. With this level of involvement by the customer, there is no way that the wrong product can be built.
Quality – Agility always includes a strong focus on the quality of what is built. This includes not only the customer’s acceptance testing, but also many technical quality practices. Properly functioning Agile teams produce high-quality software.
Schedule and budget – Time-boxing of an Agile project means that its schedule and budget are rarely “over-run” If things don’t work out as planned, the low-priority features can be skipped or cut short. If an Agile project does need to extend its time-box it would be with their customer’s and management’s full concurrence.
Early warning – Because an Agile project is essentially a series of short mini-projects, problems become apparent very early, when they can be corrected.
Adapting to change – Change is a fact of business. An Agile project can adapt to changes in the business environment, within the organization, or with the customer much more effectively than a traditional project.

Every business values agility (lower-case “a”). What many are finding is that Agility (upper-case “A”) provides what it promises.

Alan Koch, PMP, is president of Ask Process. Inc., (http://www.askprocess.com/) and an instructor with Global Knowledge Training LLC. A longtime member of the business analysis community, Mr. Koch has 28 years experience in software development. He can be reached at http://ca.mc883.mail.yahoo.com/mc/[email protected].

More Business Analysis Trends to Look for in 2009

Written by Cynthia Low on January 20, 2009. Posted in Articles.

The last Business Analyst Times of 2008, reviewed some of the important trends to look for in business analysis, or requirements management and development (RMD) in 2009. A global panel of experts from ESI International has its predictions about trends that will impact business analysis this year. These trends, listed below, acknowledge the growing importance of business analysis as a strategic, cross‑enterprise discipline, essential to the success of systems development, process improvement and change, especially in today’s volatile economic environment.

Better Sight for Strategic Enterprise Analysis

As businesses work to ensure short-term viability as well as long-term security, the critical thinking, elicitation and assessments skills of BA professionals will play an increasingly important role in helping senior management see across the enterprise to deliver more accurate strategic analysis.

The Rise of the Center of Excellence

The need to demonstrate the value of business analysis while increasing efficiencies will result in more organizations establishing centers of excellence. Centers will increasingly be valued for setting methodologies and standards that enable consistent sight across the full breadth of the enterprise.

Increasing Role in Successful Change Management

As businesses retrench and react to the unpredictable economic environment, well-executed change management will help ensure that decisions made are delivered as planned. Essential to that success will be BA expertise in helping organizations thoroughly understand and document the change criteria and their cultural and economic impact.

Proving the Value of RMD

Smart businesses will be looking to contain costs across all areas in 2009. It will be incumbent on BA professionals to effectively measure the value of business analysis and demonstrate its ROI to justify continued support.

The Role of the RMD will Elevate Above the Project

The combination of greater organizational reliance on RMD to ensure enterprise-level success and the increasing value of RMD experience and expertise will result in RMD stepping up to greater roles at the program and portfolio levels.

BA Experts will be Prized Members of Service-Oriented Architecture Project Teams

As enterprise-wide solutions become imperative for cost containment and other efficiencies, BA professionals will be prized on project teams for their ability to see across the enterprise as well as for their change management skills.

Strengthened Collaboration of Business Analysis and Project Management for Best Practices

Projects will continue to become more complex and more expensive. Collaboration between business analysts and project managers will play an increasingly important role in ensuring that projects meet organizational needs and deliver promised ROI.

Growth of the Business Analyst Leadership Gap

As businesses increase their reliance on business analysis to drive change, help contain costs, ensure project success and gain accurate enterprise-wide insight, senior management will recognize the need to grow more BA leaders. Organizations will place greater emphasis on business analysis-specific career tracks, professional development and certification to close the gap.

Higher Value of High-Impact Communications

Driven by a need to make faster, more cost-effective business decisions, the often background skill of effectively facilitating diverse groups to achieve consensus through high-impact communications will be moved to the fore as a key business analysis role.

BA will Facilitate Greater Use of the Agile Software Development Methodology

As organizations look to continuously become more streamlined and cost-effective, Agile development will be increasingly viewed as a key solution. Business analysis will be valued for its ability to increase understanding of pre-planning activities and the ability to validate information early, supporting successful use of Agile for streamlining and cost-containment.

Glenn R. Brûlé, director of client solutions for ESI International, has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. http://www.esi-intl.com/.

The Importance of Requirements Traceability

Written by Cynthia Low on January 20, 2009. Posted in Articles. 1 Comment on The Importance of Requirements Traceability

Discovering a list of requirements and then not linking them to design, construction and testing often results in the delivery of a system that may not fully support the business process which it was intended to automate. Only through traceability can the project team ensure that all requirements are implemented. Traceability assures the business stakeholders that the developed system supports their original requirements.

Client Story: A Large Financial Institution

A large financial institution recognized that their IT projects were consistently not meeting the expectations of the project stakeholders. Delivery of systems with missing or incorrect business requirements resulted in modification of business process or expensive workarounds so that the system could be used. Consequently, many costly change requests were generated, often to implement requirements which were identified during the requirements phase of the project lifecycle.

Lessons Learned

Each element of the design must come from the business requirements.
In order for the system to deliver value it must support the process. The system is based on the design. Therefore, the design must be based on the process the system is to support.
To ensure expectations are met, test cases should be based on business requirements, not technical design.

The client did an analysis of several projects which delivered systems that did not fully meet requirements and determined that the root of the problem was an inconsistent methodology to elicit and document business requirements. After a search process, IAG was selected to assess the organizational maturity in the area of requirements. IAG was also tasked with developing a customized optimal requirements process based on industry and organizational best practices as well as IAG practical experience gained on hundreds of requirements projects.

Recipe for Success

In order to determine the root cause of the requirements deficiencies, IAG conducted a Requirements Management Maturity Assessment (RMMATM). The RMMA is used for the identification and improvement of an organization’s business analysis, requirements definition and requirements management capabilities. The assessment evaluates not only organizational capabilities with respect to process, but also staff competency, practices and techniques, tools employed, organizational infrastructure and support, deliverables, and results which are currently being achieved.

IAG conducted a series of structured interviews with stakeholder groups including Business Analysts, Project Managers and key members from Lines of Business and IT. Additionally, IAG administered an assessment survey and a Business Analyst competency test to measure perceived and actual skill levels of the staff responsible for requirements management. Several common themes arose while conducting interviews with stakeholder groups, one of which was the lack of traceability after the requirements had been discovered. A number of key stakeholders went so far as to voice their skepticism about the success of any new requirements methodology since past projects had been implemented without incorporating all requirements discovered under previously-used practices. It was determined that the root cause of these past failures was that once business requirements were documented and handed over to the design and construction teams, they were not referenced going forward. In fact, test cases usually tested the design rather than the business requirements; if requirements did not make it into the design, testing would not catch the problem.

“For the first time, this approach provides us with a flexible and adaptable approach that takes us from our clients’ true business requirements seamlessly through software design. We also generate our test cases right at the start and ensure traceability through our SDLC.”

J.S., AVP Individual Systems

Upon completion of the RMMA, IAG produced a Requirements Practices Guide which included both an elicitation framework androbust tracking of requirements from discovery through testing and implementation. IAG then demonstrated the value of traceability through the success of several projects, in which the Financial Institution engaged IAG as a partner during the Requirements Phase. The Financial Institution now writes functional requirements which are derived directly from the business requirements discovered when describing the business process. These requirements are managed using a Requirements Traceability Matrix connecting them to design and testing elements and even linking change requests created during the course of the project. This has resulted in a dramatic decrease in missed requirements as demonstrated by a 75%reduction in change requests on similarly-sized projects.

Advice for Project Managers

When managing your project’s requirements consider what was needed in this client’s case: a better process to create functional requirements for each business component to be automated, as well as, the ability to trace those requirements through design, construction and testing to ensure each business requirement is satisfied as intended.

The client’s expectations are that the system performs functions to support their business process, as documented in their business requirements. Therefore, you have to reflect your client’s business process in the functional requirements. Ultimately, you must deliver a system which allows the business to function in its desired state. You can achieve this by creating a functional requirement for each business component to be automated – but – don’t forget to trace each requirement through the development lifecycle. Both are needed to ensure the system meets stakeholder expectations.

Duncan McDonald is a Senior Consultant at IAG Consulting (http://www.iag.biz/) with over 20 years of experience in bringing practical advice to clients across many industries. Duncan has completed dozens of large-scale requirements projects with IAG’s clients as a lead requirements facilitator and requirements architect. As a requirements trainer and best practices advisor, Duncan has also supported a variety of large clients in becoming more efficient in requirements discovery and management practices. Duncan is a sought-after consultant, who brings pragmatic solutions to clients that want dramatic performance gains.